I categorized the academic approach as more like Cyclone or Typed Assembly Language ... which do, as far as I can tell, have working implementations. I don't think anyone's expecting an after-the-fact code analysis to be able to verify such things generally -- that seems like it's obviously not possible (since you could construct, you know, a program that only uses pointers incorrectly if it finds a counterexample to [insert famous theorem here]). Code analysis techniques like Model Checking are more additional debugging aids than full solutions ...

Yes but I think I misunderstood you. When you said "It still seems like a real advantage to get rid of them completely." I thought you were talking about getting rid of any possibility to cause segfaults by eliminating all things that can cause user-errors (pointers, overflowing arrays and other stuff)

In about 95% of the cases, yes. For them CPU speed is fast enough. Problem is that the other 5% still needs at least some tuning and part of that needs extreme tuning. Difference between non-optimized code and optimized code can be several orders of magnitude, even when the general algorithm is the same.

C# is a pretty nice language and i've done work in it. THe main problem i've had with c# is the lack of good strong libraries. Windows Forms is terribly incomplete (though consisten) and it uses GDI+ instead of GDI which means no hardware acceleration for things like blitting images (which means its makes a terribly slow picture viewer unless you bother to p/invoke gdi and winapi).

Mono is pretty nice and i use several mono applications including beagle and tomboy. A lot of beagle core is actually still in c++ for various reasons. Mono apps seem to run just as fast as the rest (because they all use c libraries in the end).

gtk# and glade# are pretty nice and there's gecko# gimp# and everything else in the gnome world. qt# was sadly canned after the people lost interest. QT is an awesome toolkit.

Last summer i wrote some numerical code in c# for some basic image processing. I took some time, read a lot of docs, followed good practices, turned off all the safety stuff, and it still ran 2-4 times slower than naive c++ (compiled with mingw). Obviously though c# is not designed for that stuff. Actually if you think about it matlab is horrendously slower (but syntactic gold).

I love c# for writting everyday applications but for me c++ is awesome for everything else. I do a lot of image processing, numerical analysis (often i call fortran code which can optomize a lot better because of constraints like lack of pointers etc.)

Which is why you try and use nice helper objects which throw exceptions where speed doesn't matter. They are speaking of making the next version of the STL entirely "safe" and having an unsafe one available for those who count cycles. But ya, pointer abuse is one of those things that make C++ a real drag. Smart pointers go a long way to fixing that but are not perfect themselves.

I was also pleasently surprised last summer when i discovered that i could write void* in c# and have it compile. I believe though that i needed to mark the function using the "unsafe" keyword. That seems like a perfectly reasonable thing to do. It's basically the equivalent of casting to/from type object.

Hell no! Although i must admit that my "research code" for my biomedical engineering thesis uses a lot of checking and such so it takes overnight to run instead. There are a few performance critical areas where i could fix it but since i'm constantly modifying the code it would be suicide. That aside it would be marvelous if once it stabilizes i could run it in even 70% of the time. Don't forget that there are a LOT of cases where even an algorithm of nlog(n) is far too large and every cycle counts (especially every branch! especially with blocking and multi-threads/processes)

edit: In particular i'm using smart pointers, very "safe" collections, built checking in them, etc. The best thing any compiler could do in my opninion is throw compile time errors and warnings. The more the better. I always make my code work to output no warnings even and gcc 4 makes things a lot "stricter".

Eclipse can edit C++, but I haven't tried the refactoring capabilities yet. But it is certainly doable in C++ as it is in Java, because the preprocessor is not used heavily in C++ to provide code; that's unlike C, where certain tricks are only possible through the preprocessor.

It is a totalitarian design. It puts unneeded constraints. It is certainly not worthless, but security could be done without it.

www.parasoft.com

vector.at is your friend.

ptr<T> is your friend.

Not really possible with GC and guarded pointers.

Not really. The vast amount of problems in C++ come from manual memory management. If you do not believe me, check out com.std.c++.

You don't have to eliminate pointer calculations. In C++, you don't pay for what you don't use. Let them do pointer calculations if they want to screw their program...if you don't, provide a special pointer class which can easily do guarded pointer arithmetic. That's a task that can hapilly exist in a library, unlike gc.

There are everyday tasks that require speed. Try Sql Server Express, a .net managed app...slow as hell. Then try VS...not as slow, but slow nevertheless. Also try to edit a 265-page word document with technical schematics...each time you add something, word will repaginate the document, taking lots of time to do that. And what about compiling?

Let's not kid ourselves. The day performance does not matter is not here yet.

That odb thing looks pretty neat. D: But hasn't been updated in over a year? It'd be nice if it integrated into Eclipse...

Marcello

I'll take Greek Mythology for $500, Alex!

I'll byte and say that C++ is faster... OTOH he wouldn't have stated the quote otherwise since it wouldn't have been "newsworthy"

THe MS VC++ compiler sucks donkey balls. It chokes on templates and simple stuff all the time. But that has absolutely nothing to do with "which language is the best".

Even if the C# compiler was written in a native language such as C++, I doubt it would be any (or much) faster, because compilers spend a lot of time in disc access.

I remember using Turbo C and Turbo Pascal on the same machine (just running DOS). Pascal compiled way faster than plain old C. This guy should also be working on the C++ compiler team.

Templates take a lot of time to process. If C++ had a proper generic system then it wouldn't need templates to thrash the compiler and bloat the binary.

Even verson 6 was used widely in the industry, so I guess it was 'respected' too, but that was full of ISO/ANSI non-conformance.

Good God, this thread still hasn't been shut down? You are all aware that the question was asked and answered in the first two posts, and everything since then has been off-topic, right?

Welcome to allegro.cc.

[edit]D'oh!

When will it support C99? Why is it replacing/deprecating the majority of libc in the name of "safety" and "security", when several of the functions could only be a safety concern if an absolute idiot got a hold of them? Most of the rest are also fine as long as you use it properly.

Source? Is that true for AMD chips as well?

The reason the C# compiler is so much faster than the C++ compiler is similar to the reason the Java compiler is so much faster than the C++ compiler. You're not building/linking the entire program, you're making dynamically linked modules. Plus on top of that, the languages are a bit more strict and don't have to worry about things like preprocessors (eg #include).

Marcello