[rant]

I am completely exhausted trying to put libraries together...almost nothing works.

I had big problems with Allegro 4.9.8, which does not compile under VS2005 with libjpeg support (and other issues, I have posted them in the "installation, setup & configuration" area). I was fighting with this for almost 6 hours, and I gave up (nothing against Allegro, it was the required libs that gave me the trouble).

Then I saw that Nokia released Qt 4.5, which is open source. I downloaded their SDK, but unfortunately it plays only with Mingw. No problem, I said, I will use Mingw from now on.

I tried to compile the examples...they don't compile. Oh, the horror! the problem is the paths: since I have VS2005, the compiler does not look at the mingw STL library, but at the Microsoft's library. I searched the options in the Qt Creator, but there are none for the compiler paths. So, I gave up with this as well.

Then I went to another little thing I wanted to try: boost intrusive lists with smart pointers. Then I discovered that the specific type of lists does not work with boost's smart pointers!!!!!

At this point, I am extremely exhausted and thinking of quitting any programming for my own leisure.

I am also extremely frustrated by the state of C++ software. Nothing works out of the box, and I have to jump hoops in order to make things work...

[/rant]

I had that issue with MSVC, MinGW and QT before. I just use a batch file that unset some environment variables that seem to confuse something with QT's build process.

C++ is by elitists, for elitists. It's what can be expected. No concept of usability.

I've been using Qt 4.5 beta1 and RC1 for some time now with visual studio. They don't provide a binary package, you have to compile it yourself, but it't quite easy:

Download the source distribution.

Open the MSVC2005 command prompt (it should be in programs->microsoft visual studio 2005->Tools).

Go to the qt dir where you unziped everything

and run:

configure -debug-and-release
nmake

And done. It takes some time to compile, so better go do something else. In case you have mingw installed pass -platform win32-msvc2005 to configure to make sure it generates the vc libraries and not the mingw ones.

What about QtCreator? have you tried that?

Yes, but I didn't like it :/ I tested it only with mingw, though. I preffer Visual Studio IDE + QtDesigner as a sepparate program. With QtCreator you end up with too many things that don't really fit on a single window (on my poor 1024x768 resolution ).

[edit]
Mmmm, I just found this

C++ is write only.

c++ is a convoluted mess because it has to find common criteria for everything from 8-bit micros to 64-bit super computers.

From the first post, it seems that even the common criteria have divergent implementations...

Libraries for both providers and users are hell. I was searching for an easy way of doing all this. Different languages compilers and build systems. But nearly all powerfull libraries are C/C++ and often don't provide a good platform-independent build support.
You could try a linux distro. They have nearly all the important libs as binaries and they are installed easily. No problems with dependencies. And mostly no need for compilation by hand.

You only have to look as far as Java to see that statement is false. C++ is a mess because the standard focuses too much on the syntax and ignores important issues such as interoperability.

I tend to avoid C++ unless I absolutely have to deal with it. Managed languages (Java, C#, etc.) have been around long enough for programmers to recognise their superiority in most situations.

Great, comparing a programming language with one that appeared 15 years later Interoperability back in the 70's wasn't such a big issue as it is today, saying C++ isn't focusing on it is just as true as saying old 1920 films don't scale correctly in todays' HDTV sets.

C++ is a mess because it is an old language. The same will happen to Java once it is overcame with newer, simpler and more powerful languages.

QBASIC always works when i need it to

My point is that if you live in the past, don't complain when it doesn't work out for you.

Sometimes you don't get to choose languages. I don't program in Visual Basic 6 because I like it, it is because the application is written in it. And I don't program in VB.NET because I like it, I do it because our company licenses Microsoft stuff. And I don't use Java because I like it, I use it because we are running Tomcat in a Linux with Apache.

A programmer chooses a language to work with. An experienced programmer uses whatever language is available.

Writing high-speed computational models is a thing of the past now? Just because you don't do real work with a programming language, doesn't mean the problem isn't there.

Some people have to work with C++, and answering their complaints with "oh, stop living in the past, duh" is not very helpful. Sometimes, as ReyBrujo said, you need to support legacy applications. Other times, something just can't be done efficiently in those languages: right tool for the right job etc, and the job that C++ does basically has no other tool that can do it aside from C++ (or C, I guess). And, as it has been noted, the tool is often clumsy to use, so yeah...

I disagree - the language itself ifs fine (for me). Actually, it makes a lot more sense than plain C. OOP is a lot more human-friendly.

That says nothing about the software, however.

Emphasis mine.

That too, I personally never had the issues OP is talking about, perhaps because I haven't ever used MinGW and MSVC at the same time. If C++ works for you, it's the others' burden to prove that you should switch away from it. And if they don't feel like proving it, they might as well stop trolling about it.

Thanks for the support

Did you read the original post entirely?

I write computationally intensive simulations for my leisure

Oh yes. Likewise, I would not have chosen FORTRAN as the language I do most of my stuff with these days...

Hehehe, our database programmer wants to write the new database manager in Eiffel. I guess everyone has a preferred language.

IMO, C++ is such a giant mess because of its strict adherence to the "to everyone their own" rule (which basically states that the language should not contain anything that resembles user code), and because it refuses to add features that could somehow have an impact on run-time performance, however negligible.

It appears even messier because other, newer, languages have been made in the meantime, and some of them learned a lesson or two from C++.

Libraries are a mess because C++ (other than C) lends itself to multiple programming paradigms, and the same problem can be tackled using different programming techniques (e.g., use exceptions or return values? OOP or procedural? Templates or polymorphism?); but other than Java or C#, it doesn't come equipped with a monolithic library providing "95% of what you'll ever need" that you can rely on and that you can assume every other programmer uses as well. With C++, every library defines its own way of doing things, and often they don't go together well; with Java, for example, the compiler, the "library" (runtime), and the "machine" (the virtual one anyway) it runs on are standardized, and thus very predictable. With C++, there are a dozen compilers and a million different machines you can possibly face, and you need to accomodate them all somehow.

Actually, OOP is a lot more fun using a language that has built-in constructs for getters/setters, interfaces, events, a mother-of-all-classes ("class Object"), a built-in string type that goes all the way, and all those other nice things that make your life easier.

I'm sure you can find code that contains similar features and alter it slightly to your purpose. If you want a mother class, write one and use it in every program.

class Object {
};

class Whatever : public Object {
     // Put your stuff here. 
};

Obviously that is useless if Object doesn't actually contain anything useful.

How do other C++-like languages prevent using multiple paradigms? In Python I can write perfectly procedural code or OOP code, I can use exceptions or I can use return values. I can do things in many-many ways (e.g list comprehension or manual loops).

Wouldn't it be perfectly possible to write purely procedural code even if you are forced to only use classes and methods?

The problem is that c++ allows for multiple incompatible "worlds" to exist:

1) the MFC world.
2) the Qt world.
3) the wxWidgets world.
4) the boost world.
5) the Microsoft Visual C++ world.
6) the Mingw/GCC world.
7) etc.

All these are incompatible with each other. Different ABIs, different built systems, different implementation details, different memory management techniques, different threading, etc. You can only choose one of them and be happy.

Except for memory management, that's not a very strong argument against C++. Java has different build systems (although many times better than make) such Ant and Maven. There's also an explosion of mutually incompatible web frameworks around Java. The real advantages of Java over C++ to developers are garbage collection, the huge standard library and the builtin standards that allow easy linking of classes at runtime.

I disagree. You can't use one of these "worlds" with any other "world". In many cases, simply including files from two or more "worlds" does not even allow the program to compile (let alone function properly).

And then designing something that mixes features from these worlds requires extreme hacking techniques.

For example, Boost signals are incompatible with Qt signals. MFC and wxWidgets don't even have signals.

Or each library contains its own string class.

C++ is a great language, that's why it's in such a predicament. It happened to be a reigning champ during the computer boom, so tons of companies put all their weight behind it, pushing it far beyond what it was meant to be. It's only natural that, with such a popular language, mutually exclusive dialects spring up.

But now, almost two decades later, it's bursting at the seams because we've refused to move on. We insist on patching up the holes with C++0x, allowing everyone to invest even more in something that's increasingly less important.

{"name":"jobgraph.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/f\/9f660dd16bf392139835691f2a06925e.png","w":540,"h":300,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/9\/f\/9f660dd16bf392139835691f2a06925e"}

(Note that it's percentage growth, so C++ is continually losing job positions.)

I hardly think C++ is going to "die out" any time soon, but I do think that it's outlived its purpose. It's also entirely possible that I'm talking out of my ass.

So doing computational simulations is no longer needed? You might think that's not important, but that is the cornerstone of my future research career. I want a language that works well with that, and the patches coming in C++0x are very much welcome to people like me. Perhaps business world does not need C++ anymore, but business world != entire world.

See, that's what they call a false dichotomy. I did say it wasn't going to die out any time soon. My point was just that...

And, like it or not, the business world fuels the evolution and adoption of programming languages, the same way with Java and C# as with C++.

Is it strange to think that people 10 years from now may talk about C# the same way we're talking about C++?

The difference being C# is still changing a lot, and can continue to change. C# is controlled mainly by Microsoft, so they don't have to deal with standards committees and a bunch of whiny nerds when they want to change or add something.

As far as I know, C++ has a lot more libraries/support/etc. than C#. But I don't really know anything about C#.

C++ has not outlived it's purpose. You said that, I corrected you. No false dichotomies introduced.

I'd like to see some proof of that. Academia has been creating quite a few innovative languages these days, irrespective of their business applicability. FORTRAN is still going strong in the academia too, being revised and updated constantly. I doubt it even registers in your little percentage growth chart.

I think that the business world fuels the evolution and adoption of programming languages in the business world only. Business world != entire world.

Support doesn't matter much to me, I can find all the resources I need in dealing with C#. As far as libraries go, I haven't had much problem finding whatever I need with C# either. In fact, most of the stuff you'd have to do yourself or find a third party library for with C++ is built in to C#'s standard library (.NET).

When it comes to business applications, C++ is not relative any more. But there is a lot more than business applications out there.

For example, one of our next projects at work (if we are offered the contract) includes the modernization and enhancement of software that operates the torpedo systems on a certain class of French Frigates (details can not be disclosed of course).

The software is huge. We are talking about 5 million lines of C++ code and 3 million lines of Java code.

Java is used for the GUI. Java apps are stored in a cluster of servers, accessible from any console on the ship. All the consoles are programmable.

C++ is used for the torpedo systems. The torpedo launcher kernel is written in Ada (a few hundred thousand lines of code), but the rest of the system is written in C++.

One thing that C++ has, and it is a tremendous advantage when compared to other languages, is performance. All the power of C++ comes from two things:

1) templates. A list of integers works in C++ many times faster than a list of integers in Java, simply because Java has generics, not templates. In Java, a list of integers is actually a list of Integer objects.

2) static allocation. Much of the data in a C++ program live on the stack. Especially small classes used as keys to maps, iterators, etc. Big win for C++ in this domain.

These things matter very much, especially when there are run-time constraints.

So, overall, C++ is still relevant. It may not be obvious, because C++ is not used in business applications, but it is here and it is not going to go away anytime soon.

C++ is, IMO, slowly moving from being the #1 mainstream language into a niche: applications where detailed control over memory allocation is needed, runtime performance is crucial, or the target platform is severely limited hardware-wise.

C++ is also used in all the major applications:

http://www.lextrait.com/vincent/implementations.html

So I don't think C++ is moving into a niche any time soon.

Not c++ but c. Maybe interesting non the less.

link

Open Source, yes. I can see why: An open source project needs as many contributors as it can get, and C is somewhat the lowest common denominator for most programmers.
Also, the number of new open source projects doesn't really say much: Many of those end up as abandonware, or they never find a significant audience. Also, most open source projects are *nix-ish things: small tools tailored for one specific sub-task; this is something C lends itself for.
However, if you count the total number of users, and include web applications, then I bet the figures look a lot different.

I still think that C++ is slowly moving from its pole position as the most popular general-purpose programming language towards a more specialistic role - when runtime performance is more important than developer efficiency; when legacy C++ code needs to be supported; when coding at a very low level is necessary; when JIT compilation cannot be afforded; things like that. The process is obviously slowed down a lot because:
- Everybody knows C++
- Everybody has been using C++ in the past, and migrating can be costly
- C++ is available for virtually every platform

And another reason:

- C++ is faster than the other languages.

Speed doesn't matter in most cases. Only in special cases would the slight speed hit to a different language matter.

I disagree. All the big packages mentioned in the page I posted above would be slower from Java and C# (databases, office, browsers etc). There is still no big app in these languages.

GC'd languages require 2.5 times the memory of languages where memory is managed manually.

Speed doesn't matter in most cases. You are mentioning huge applications. How many good office programs, databases, and browsers are there? Not many.

The vast majority of business applications do not require the marginal speed benefits of C++. And even of the three you mentioned, only databases would truly benefit from that. C# is more than sufficient for a word processor or web browser.

Ease of development trumps using fewer CPU cycles.

I agree with all your points, except one: that only databases would truly benefit from that.

At work we have some freakin' huge documents (800+ pages), which are handled very slowly by Word 2007. If Word was implemented in Java, it would be truly painful.

Perhaps the situation would be better with C#.

The language itself doesn't make the handling of such huge pagecounts slow, but rather their algorithm.

Assuming that the algorithm is optimal, it's the fault of the language. Practically, Java would choke on such large files, setting fire to the hard disk due to extreme swapping.

You're making a pretty damn big assumption here.

For one, when dealing with such huge amounts of data, especially if randomly accessed, you will want to load it in chunks on demand, rather than load it all to RAM at first.

Java doesn't choke on filesize unless you try to read it all at once. A file handle doesn't care if the file is 1B or 7TB.

As far as I know, word processors do need to read the entire file...
And is that 7 Terabytes??!!

It was just an example.

Why does a word processor need to read all 800+ pages at once? You can't read that much at a time...

Furthermore, I fail to see how C++ could provide a noticeable speed boost when using the same algorithm. If you're reading what is presumably a few hundred MB of data, it's going to bottleneck at the hard drive no matter what language you're in.

I'm going to buy a crapton of monitors and display an entire 800+ page document at one time, just to prove you wrong!

I agree (my above statement was an obvious lie). Well, if you use something really ancient, or really inefficient, then the language could make a difference.

I'm just trying to cover all the bases so someone doesn't bring up Uber_Obscure_Language_That_Sucks_At_Making_Text_Editors--

It sounds like you haven't used Word. Do you know what re-pagination is? type a character in page 10, and the whole document has to be re-paginated, up to page 800.

You are right. Strictly speaking, C++ and Java can not use the same algorithm. Because in C++, objects take much less memory than in Java. So, C++ has the advantage, because the algorithm used in C++ can't be used in Java.

Practical example:

C++:

class Bar {
public:    
    int i;
};

class Foo {
public:  
    Bar bar;  
};

Size of Foo + Bar = 4 bytes.

Java:

class Bar {
    public int i;
};

class Foo {
    public Bar bar = new Bar;  
};

Size of Foo + Bar = 28 bytes (12 bytes for each object, plus 4 bytes for the bar's member).

The Java objects are 24 bytes bigger than the C++ objects.

So, it's not really possible to use the same algorithm, strictly speaking, because Java objects are much more heavyweight than C++.

If you multiply the above by, let's say, 1 million objects, then the Java overhead is 24 MB.

In practice, the difference is bigger. In C++, I can do this:

std::list<int> data;
data.push_back(10);

The memory allocated for this operation is:

1) 12 bytes for the linked list node: 8 bytes for the previous-next pointers, 4 bytes for the integer.

Total: 12 bytes.

In Java:

List<int> list = new LinkedList<int>();
list.add(10);

The memory allocated for this operation is:

1) 16 bytes for the Integer instance (due to auto-boxing, remember Java does not have templates): 12 bytes for the Object bookkeeping data, 4 bytes for the integer field.
2) 24 bytes for the linked list node: 12 bytes for the Object bookkeeping data, 8 bytes for the previous-next pointers, 4 bytes for the pointer to object.

Total: 40 bytes.

So, for the linked list, the difference is 28 bytes.

It is even worse for maps. In C++, a key-value pair takes exactly the amount of memory required for the key and value types, plus the pointers to other nodes; in Java, both the key and the value are objects.

There is also the overhead of interface invocation in Java.

All this, and if we also consider that in C++ most objects live in the stack, makes C++ preferable over Java.

In practice, that is the exact reason no major desktop application is written in Java.

Java has other advantages, which make it suitable for other types of projects.

You're right. The business world represents only the real world.

Yes, C++ is a good example of "irrespective of their business applicability".

Whoa, that's a bold claim. Certainly not one you could back up. I know of many successful desktop apps built on Java. The best PHP IDE currently in existence is a Java desktop application. There are very many more Java desktop apps developed and used internally by large corporations. Then there is the huge amount of Java web apps used in commercial sectors, such as Internet banking systems. Perhaps your claim is based on the Microsoft Office not being written in Java?

Axilmar, you're right and wrong. You're right about it sucking that Java has generics, but templates aren't the answer. C# has the best parameterized class system. It generates classes at runtime as needed and (as far as I know) allows primitives as type parameters. You're wrong about stack allocation being superior to heap allocation and garbage collection. First of all, Java uses a generational garbage collector by default. It has been found that most objects typically survive only one generation, so object creation patterns in Java closely resemble stack-based patterns in C++ anyway. Secondly, heap allocation and garbage collection liberates the programmer from managing responsibility for object deletion. This allows objects to be passed around freely without fear of memory leaks. Of course, you can get the same effect in C++ with boost::shared_ptr, but then you're addding memory overhead and cluttering code with boost::shared_ptr.

One thing that irks me about C++ is that it could retain all its perceived benefits without being so damn cumbersome to use. It could use a package system (like Java's) instead of header includes and library linking. It could ditch the requirement for forward declarations. It could have a much simpler template system. Its syntax in general could be much more readable. All this without losing one little bit of runtime performance, while significantly improving developer performance. The people behind C++0x had their opportunity to improve developer productivity and they blew it. This is one reason why C++ is becoming a niche language.

PHPEdit is actually written in Delphi...

Pagination requires knowing the text and the dimensions of the objects. That does not take up much memory.

Given a high of 500 words per page, that is only 400,000 words. If they average six characters, that is 2.4MB. The dimensions of embedded objects would only be a few KB.

Thus memory is of no concern here.

If anything, it's a CPU intensive task. But really, all you have to do is re-page the currently visible pages. The rest can be done in the background. The user won't notice, as most of the time you're not inserting a character and then jumping 500 pages ahead.

As an off-topic, a word processor shouldn't care about the layout of the paging, it should edit text and do grammar and spell checking. Allowing the user to meddle with layout and the like, leads to horribly formated documents. The few non web documents I have had to write have been in LaTeX, and they came out looking fantastic, and I wasn't required to guess at what would be the best way to format something.

I said major applications. Please check out the following link: http://www.lextrait.com/vincent/implementations.html

Generation of classes at runtime is good for two reasons:

1) it does not slow down compilation.
2) it does not bloat the result executable.

But this is irrelevant to performance.

"Closely resembles" does not make it equal. In practice, the difference for big data sets is not negligible.

I agree with that. I am talking about code performance. I am a supporter of garbage collection in C++, I have registered an online petition, written numerous times to Bjarne Stroustrup and posted countless threads here about smart pointers.

I couldn't agree more. In fact, I fully support a movement for a new programming language that has the qualities of C++ but none of its problems.

You have forgotten that a Word document is composed of COM objects. Which means that each little item in a page is a fully COM object, and has visual attributes like Color, font, style; also parents, siblings, pointers to interfaces, etc.

And then you have also forgotten that a document can contain images, tables, OLE objects etc.

And Word does the re-pagination in the background, but if your document is 800 pages, it causes heavy swapping, and stops all the other tasks. Which means it is memory intensive.

I couldn't agree more.

I haven't forgotten any of those things. None of them affect what I've said.

They do affect what you said. The document is technical, i.e. it contains lots of diagrams, bitmaps, tables etc.

The fact is that there is no office, database, web browser, and other major software written in anything else than C++.

I don't care what it contains. My Commodore 64's word processor could hold hundreds of pages with 64K of RAM.

So? First, there are seasoned programmers like who you would never consider using anything except C++ (for these "major" projects). Those people have to retire first, as learning a new language is impossible. (Cannot teach an old dog new tricks.)

Second, I don't expect anybody to recode their existing C/C++ codebase to another language. "Major" software isn't rewritten. It's extended and upgraded until it breaks under its own weight. Then something else replaces it. Switching to a new language isn't reason enough to start up a new project to compete with existing "major" software.

Third, there aren't many choices yet if you want to do cross platform, native programming. C# is great for Windows, but doesn't have much support for other platforms. Java is a good language, but suffers a lot from abstraction. I think D is a more practical language, but it doesn't get much attention.

Fourth, your definition of "Major" software is meaningless. I, for example, would consider Paint.NET major software. But you wouldn't because it's not written in C++. Any example I give, you can just say it's not major.

Fifth, your "fact" is wrong. There are HTML/CSS2 web browsers written in Java.

Do you define major as in user base, or in scope? If its in scope, Singularity OS is way up there.

http://en.wikipedia.org/wiki/HSQLDB

Does anyone see firms like Oracle and IBM really getting behind C++? No, they put their eggs in the Java basket. Especially Oracle. They are certainly major corporations.

NetBeans 6.5 is a better PHP IDE than PHPEdit. It's also free and open source.

You should, because different and much more complicated data structures are required to hold drawings, tables etc than simple text.

You are wrong. I am also a Java programmer :-). And I have learned C#, and a little bit of LISP, Smalltalk, Haskell, Erlang, ADA and Eiffel in my spare time.

Which only shows that new languages don't have any substantial benefits over the old ones.

Agreed. The only options are C++ and ...C++.

Paint .NET is not called to handle lots of data in very short time.

Read the docs of uTorrent. The author says that it chose C++ because the other languages were slower.

You could have written a browser in QBasic, or any Turing-Complete language. The issue here is performance.

As a 'personal' database, Hypersonic is good. I don't know how well would it perform when big performance is required though.

Not for the database engine. Java for the client, the tools, the server back end...

And let's not forget Google's Map-Reduce...in C++.

What is your definition of "big" applications?

Is it something that moves a lot of data? You mentioned uTorrent. So that must be big. But what about the Java bittorrent clients? They don't count as big, but uTorrent does?

eBay moves a lot of data. It's written in Java, as are a lot of other huge websites. I know they aren't desktop applications, but if we are talking about handling a lot of data in a short amount of time (your words), surely they all qualify.

I don't expect reasonable answers, as you make false black-and-white claims (there are no databases, no web browsers, etc in Java) and then when shown that you are wrong, you just raise the bar even higher, just as I predicted.

And as I've already said, the lack of "big" software written in C# is not any indication that it is incapable of being used for that. It has only been around for eight years. Most of the programs you would mention as "big" have been in existence for longer than that.

It seems that you are shrinking your definition of C++'s niche into data crunching programs. In that case, I believe you've come over to our side in that C++ is a dieing language that will only be used for components of programs that deal with large amounts of mission critical, time-sensitive calculations.

The uTorrent author said that he chose C++ over the alternatives because C++ produced faster and lighter programs.

eBay moves a lot of data, but it does not process huge data sets which have a high degree or coupling.

I never said there are no databases, there are no web browsers. I said there are no major databases and web browsers.

Moving huge data sets around can easily be done in Java, as the code effectively is the same as in C++: the underlying O/S code is invoked to handle the reception or transmission of data.

If you wanted to create objects from those data and process them (let's say 10,000,000 objects), then C++ is much more preferable than Java.

To put it in perspective:

in C++:

MyObject *hugeDataSet = new MyObject[10000000];

In Java:

MyObject[] hugeDataSet = new MyObject[10000000];
for(int i = 0; i < 10000000; ++i) {
    hugeDataSet<i> = new MyObject;
}

Big difference in performance...

Did I say anything about C#? I did not. But the fact is Microsoft Office is written in C++, not C#. Visual Studio as well.

C#, coming after Java, has many constructs that allow better performance than Java.

But I've said it from the start: C++ is for big heavy stuff. I clearly said so from the beginning.

My difference with you is that it is not a dying language though, because the big heavy stuff is not going away any time soon.

I wonder if my English is so bad that confused you so much Matthew.

Your exact quote is:

You did not say:

You implied that all database, office apps, and web browsers were major.

I'm asking for your definition of a major/big application. What is it? I don't care about what his definition was. Other people have used Java to make fast bittorrent applications.

And of course the C++ one is smaller. The Java runtime is huge! That has nothing to do with the conversation at hand. Raising the bar to avoid Java again?

And of course C++ (compiled code) will not be slower than managed code. Neither will Assembler be slower than C++. But we are talking about being sufficiently fast for the task at hand.

So now it has to "process huge data sets with high degree or coupling" to be big. Bar raises again.

What is your exact definition of big/major software?

Nope. Read again. Talking about all major things does not exclude the existence of minor things.

Any application that processes big data sets with heavy coupling amongst the data.

...and lighter, but you conveniently left that out.

As I said above, and for the Nth time (oumf!!!): C++ is here to stay when the processing load is very big. Huge. Enormous. Gigantic.

For the Nth time (I guess some people can only learn by repetition):

http://www.lextrait.com/vincent/implementations.html

So the GIMP and Photoshop are big/major software according to the link. Then surely Paint.NET is as well, which is written in C#. So you've disproved your point. That's all.

Ultimately, I think we come to the same conclusion: In the future, C++ will only serve the niche of "processing large datasets."

Is that link even... correct? They claim Linux has no asm in it (idk if its true or not). They claim the GUI for OS X is in C++ (it's.... not, everything is obj-c.). They claim the Win32 GUI is in C++ (they wrote a C API in C++? What?).

It also appears to state games used to be written in ASM and C, and are only in C++ now. Uhm, what?

It does, but I doubt theres all that much in the x86[_64] port[s].

It seems like a very biased chart, to say the least.

What would you expect from crusty old nerds living in the past? The difference between them and the rest of us is that in 20 years time we won't be arguing why Java/C# is superior to the next big language/platform/paradigm.

It's superior because Change Is Bad(tm), and the familiar is comfortable.

GIMP and Photoshop are entirely different programs from Paint.NET. Paint.NET is a simple pixel art program, GIMP and Photoshop are professional applications for photo editing.

Photo editing != pixel painting.

And any application where performance matters.

Well, all arguments against C/C++ are moot, since Allegro is in C.

The day Allegro is in Java, we can talk.

I wish I could troll half as good as you! Don't worry, I'm taking notes.

Paint.NET is a "simple pixel art program". And Allegro is an old DOS blitting library. Ignorance is bliss, they say.

I am not trolling.

Does it match Photoshop and the GIMP? Is it used professionally? Has it replaced Photoshop yet? are its tools equal to Photoshop? can Paint.NET handle the same amount of data that Photoshop does with the same performance?

Did you check my code examples? do you have any objection on how Java handles generics and arrays? don't you recognize that these language constructs can potentially harm performance? Don't you see that C++ has the advantage over Java?

You have to check the details before simply declaring someone trolling.

Paint.NET handles the same amount and types of data just fine. It's photo editing software. Have you ever used it? It has unlimited undos, layers, filters, plugins, etc. No, it doesn't have all the features that Photoshop has, but the language is not preventing anybody from writing those features.

It doesn't have those features because it hasn't been around as long and doesn't have as many people working on it as Photoshop—nor is it trying to be an exact replacement for The Gimp (which is already free). It has nothing to do with limitations of C#.

When I use Paint.NET to edit my photos, I don't ever sit there and think "boy, I wish this were faster." It's sufficiently fast for the task at hand, and that's all that matters. If maximum speed were the goal of every project, then we'd all be writing in hand optimized machine code.

Gimp isn't fulfilling most of your fators as well.
It didn't replace photoshop. It's tools aren't equal to photoshops. It isn't used professionally.

Why is the Gimp a major app an paint.net not?

Yes, many times. I like it, for simple graphics editing is very good.

Does it have the same performance with Photoshop in the features used by Publishing Studios?

But the point of this discussion is not if a program or a programming language is sufficient for small tasks.

I have said, right from the start, that C++ is used in big heavy software.

C# and Java are fine for smaller tasks.

C# may also be capable of matching C++ in heavy tasks like databases, for example.

Java certainly is not, due to the way it handles collections and arrays.

Because it's written in C/C++ and on The List.

Just like Allegro is somehow major! (Quote: "Well, all arguments against C/C++ are moot, since Allegro is in C.")

All right, so what is "big, heavy software"? Give us a concrete definition. Is there a minimum of CPU usage? A certain number of hard drive accesses? A required number of lines of code? What are the criteria for something to be "big, heavy software"?

http://www.allegro.cc/forums/thread/599467/799488#target

It has to be on the list. And written in C/C++.

What I observed in this discussion was:
the claim was made that all major apps are written in c.
Everytime a major c#/java app was mentioned the definition of a major app was changed excluding all non c++ apps.

I also think that c++ has a speed advantage.
But that doesn't mean it's the only option.

And the other advantages other languages have will lead to the fact that they will get used despite their speed problem. With better hardware speed becomes more unimportant from day to day.
Ease of development, bug tracking, changeability will become more valuable. C++ can't keep up in this categories.

I use C# for any private gui development.
And the only reason I use C++ for developing games is that there are no native librarys I like yet (maybe this will change in the future).
There is XNA as well. But I don't like it that much.

At work I develop software with Java.

Precisely. But it doesn't matter. If he wants to think that all major apps are written in C++, that's fine. It's his definition, he can make it whatever he wants. His major apps list is so small, it's essentially the same thing I'm saying.

Not in the scientific field, they won't. It is a mistake to think that ease of development, bug tracking and changeability necessarily come with speed penalties. E.g. ever heard of 'Vala' language? The idea is silly even to me, but basically it is C# that is translated to C and then compiled. So, they get all of the benefits of C#'s syntaxical sugar, with all of the benefits of C. I don't think Vala overall is that great, but it's an example of what axilmar wants (and what I want too): an easy to use language that does not sacrifice any execution speed.

I don't really know the history behind C# or Java, but I am 100% sure that if C# or Java were somehow compiled to machine code, all you fans of those languages would still like them, because you as coders only care about RAD and related buzzwords. You have come to accept the speed penalties as a necessary evil, because by chance the heavily marketed C# and Java had those speed penalties.

Well, I don't see that it is a necessary evil in general (it is if you use those languages). Vala is an example of that. D is an example of that. Neither of those two are perfect, but they are steps in the right direction.

C# is a compiled language; the only difference against a traditional one-pass compiled language like C++ is that the first pass (C# to IL) happens at build time, and the second pass (IL to machine code) at run time.
One JIT compiled, there is no reason equivalent chunks of code in C# and C++ can't perform equally well. The speed difference often observed doesn't necessarily come from the language itself, but rather because C# makes using safe, comfy (and thus slower) memory management easier than C++ does. When speed matters, a C# programmer can still allocate behind the GC's back and take care of pointers manually.

In my experience it is exactly the other way around: out-of-the-box C# (and probably Java too, don't use it enough to know for sure) is way superior in terms of organizing large projects, especially when using Visual Studio. The larger a project, the less comfortable I feel doing it in C++.

He has already defined that all heavy software uses C++. So obviously, any C++ application is a heavy application.

Actually, the latest version of Mono lets you go all the way to machine code at compilation time. It then outputs machine language code for the app and all dependencies.

Noone ever disagreed with that.
axilmar said that no major app will ever be written in a diffrent language then c++. That was the point I couldn't agree with.

We want that too. We would be stupid if we wouldn't.
But as long as there isn't such a language, developers (doing non scientific apps) will start to use easy to use languages despite the (mostly unnoticable) speed penalty.
And the discussion wasn't about whether we want such a new language but about how only c++ is able to write major apps.

I did not change the definition of a major app from the beginning of my post. I am sorry if I was not clear enough. Let me try again.

I consider the following apps big and major:

1) databases that are able to support a big number of transactions per second. Db2, Oracle, etc.

2) office software that can handle very complex documents with minimum delay. Microsoft Office, Open Office etc.

3) Web browsers that allow for many tabs (20, 30 tabs etc) to be open without much memory overhead. Internet Explorer, Firefox, Safari, Chrome.

4) Torrent applications that can manage thousands of peers per second. uTorrent, for example.

5) Desktop environments like KDE or Gnome.

6) Complex algorithms like Map-Reduce.

7) photoediting software like Photoshop that can handle big pictures (10,20,30 megapixels) with ease, with multiple effects and layers.

I have nothing against Java or C#. But the truth is that any application with object complex relationships and complex algorithms and big data sets will have lower performance than if programmed with C/C++.

I did not see anyone argue on the coding examples I gave. Why?

As for Allegro, I wonder why it is written in C. Why not in C#, for example? Or Java? since these languages are very fast?

And why there are no 'big' games in these languages?

Why isn't it written in C++? Mainly Because the Allegro developers write in C. Every C library is written in C. Every ASM library is written in ASM. Every QBASIC library is written in QBASIC. Weird.

Regarding Allegro, C is the common denominator. It's cross platform and can be used within other languages. There are bindings to all sorts of languages, including C#!

If you want a native C# gaming library, get out the XNA.

Why should we? You gave a detailed list of major software.

#4 -> Vuze, a bittorrent client. Written in Java.
#7 -> Paint.NET, a photo editing client. Written in C#.

I say both of those have no substantial performance decrease. That's the end result of these languages that you say cannot perform well. Yet, there are two examples of complete applications that do.

So why should I break down the little details when I already know I won't agree with the end result? The proof of the pudding is in the eating...

Ugh, why do you go on? (:-X Why do I read?)
You can all agree the languages you mention do different stuff. I had a revelation a year ago or so. I was talking to somebody and the discussion somehow came to doing your own programming. He mentioned he used Javascript. WTF ?! Javascript ?!Yes. And he told me about all the projects he had in javascript and it was really interesting. He even did profiling and optimized functions (the proper mathematical kind founded optimization). And I thought: "Yeah, if it works for him, why not?" Up until that point I blamed myself for not learning assembly. I'm happy with C++. (Everyone seems to be harsh on C++. Give it some slack: it works terrifhack.) I overly enjoy optimizing at the level of C++. Some people like to do it on assembly level. Whilst others like to get as much functionality as possible, without considering the load they put on a system.
You can't argue over what people will like doing in the future. But what is needed for future business: being (overly) efficient or getting things fast? Both of-course. What tool will be used? Who knows?::)
Mr. Leverton if you really want to get the last word, abuse your power. Something like:

Only then without the quote tags...

BTW in the LHC they use custom built circuitry to do the first pass of data analysis. How's that for lightweight efficiency?

keep it up, I've come so far and I don't want to go to bed yet. This isn't over.

I remember heated discussions like this over 10 years ago, except it was ASM vs C, C vs C++ or even reinvent the wheel vs using libraries (yes, there were people that believed real programmers don't use libraries!). Now it's C++ vs Java/C#. The arguments are always the same. Why doesn't axilmar go all the way and favour asm over C++? After all, if he's processing massive datasets, even one CPU cycle in an inner loop will make all the difference.

Well, if C# and Java are so fast, it could have been written in those languages. I don't see how extremely experienced programmers that can write C in their sleep have a problem with fancier and easier languages like Java and C#.

Or is it because they fear that their library won't be as fast as, let's say, in C?

Java is also cross platform.

Because I am arguing about performance, which obviously you avoid.

Another take is this: why should you break down the little details when you know the real numbers will not support your arguments?

I never said anything like that.

I did not choose to heat the discussion up. I try to respond with facts and numbers, while Matthew acts like a politician: he tries to win not by arguments and facts, but with impressions.

It is not. I never said C++ is better than Java or C#.

It's very strange. Everyone here thinks I said that C++ is better than Java or C#. I never said that. I said that C++ is better than Java or C# in performance.

I have a friend that programs embedded devices and micro-controllers. He uses asm. If he says 'asm is better than C in this domain', should I tell him that he is wrong? he is obviously right.

I don't see what the fuss is all about, and I really don't understand the reaction of the Allegro.cc crowd. You all support Matthew, perhaps because he is an American and I am not, or because he is the site owner. But your reaction is not logical. If you check the facts, the numbers, the performance, you will see that I am right.

You are right. It's not worth the fuss.

But I want to explain why we are arguing.

We never denied your numbers. And we never denied the c++ performance is better.
We just denied that not only C++ is able to write major apps.
That was because you definition of major app was/is different from our definition.

When we said you definition of major apps changed over time you said that was not the case.
That means: You meant the same all the time but because you said it differently we understood it differently in every post.
At first you definition of a major app seemed be to be the same as ours.
And with that definition your statement that only c++ can be used was wrong in our opinion.

And all we said that c++ will be used less in the future because for most projects this difference in performance will be unimportant.
Then you started to say that c++ will not be used less because it is the only tool to write major apps in.
But apps that are major apps after your definition are needed less then other shabby gui/server apps which c#/java be more then sufficient for.

So I don't see the point that you are arguing against the fact that c++ will be used less.

As said above we never wanted to argue about performance because we know this fact.
It isn't arguable.
The only thing we argued about was the fact that c++ will be used less and isn't the only language todays apps can be written in.

You missed the important part: can be used within other languages

Written in C means it can be used from: C, C++, Java, C#, Ruby... other ones.

So if you want a library that can be used in much languages you choose c.
Which doesn't mean that it is the ONLY language you can write a library in.

We probably tatalkedbout different things all the time whwhichas why we couldn't get to an agreement.
I hope you can see that now too. Let's all be friends again

What I can't ignore though:

I don't know where you come from and I don't care. This is the internetz!
Saying something like that is a defamation. I would appreciate if you won't say something like this again.

Because Allegro is old. It's origins are what, in 1990 or so? Java and C# didn't exist.

If he says that ASM allows him to write faster and smaller code, then he is right. If he says that all major micro controllers must be programmed in ASM because of that, then he is wrong.

I don't know how else to say this. This will be my last attempt to get your understanding. Christopher has also summed it up great.

Statement 1: Generally speaking, C++ (and any similar language) will have better performance and less memory requirements than the equivalent code written in Java and C# (and other similar languages).

Statement 2: Most people find that Java and C# are much easier to use and write error free code than with C++.

Statement 3: For most applications, the ease-of-development (Statement 2) trumps the performance loss (Statement 1).

Do we not all agree on those three things? The only reason why I'm still in this discussion is because I find it funny that you are clinging on to your "major application must be written C++" idea.

Your thinking is something like:

• C++ has better performance than C#

• Better performance is good

• Therefore C++ is the only choice for applications that max the CPU.

You should take it a step farther and replace C++ with hand written machine code and C# with C++.

Let's say the C# applications runs 5% slower. You say that is unacceptable performance. Guess what? The C# application running on today's PC is faster than the C++ application running on last year's PC. So I guess all of those people need to upgrade their hardware because the performance is no longer acceptable—because a different environment is faster.

Your fascination with maximum performance must lead you to believe that every "major software" must always be installed only on the very fastest machines available because anything less would be uncivilized—you wouldn't be getting the best performance possible.

But no, what really happens is people run software on hardware that can run the software at speeds that are acceptable to them. It's quite possible (and likely) that C# runs at the same acceptable level as C++ does to the user, even on major applications.

Since Photoshop is a major application to you, I'll use it as my example. The user has non-functional requirements like "a ten megapixal image must be able to be resized into a thumbnail in less than one second." Even if C++ takes 0.01 seconds and C# takes 0.5 seconds, it doesn't matter. Both satisfy the requirement.

Your definition of a "major application" is basically: anything that requires more speed than C# or Java can provide. And in that case, I agree 100%! C# or Java will never be used in that definition of a major application.

The only problem was that C# didn't exist back then and Java didn't either, or was in its infancy.

Yes, but in that area it IS better, mainly because you're limited to how much code you can store, very limited with ram and CPU power, etc. There's no shortage of any of that on any of today's computers, so there is no reason to use ASM in most cases.

But you are only supplying heavily biased data that isn't really meaningful at all. I didn't see you present any cold hard benchmarks or anything like that.

Either way, like Christopher and Matthew said, we're not denying that C++ is faster. At least I'm not. I'm just saying that the speed difference doesn't matter much at all.

But you can't easily bind EVERY OTHER language to it.

With C, you can bind Java, Python, Perl, Scheme, C#, ObjC and pretty much every other language to it with relative ease.

Major = performance.

I never said it differently each time. I explained it differently. It's not my problem if you are stuck to a certain definition.

Yes, C++ is the only tool to write major apps in. And it will continue to be so. And the major apps are not going to go away any time soon, so you are wrong that shabby gui/server apps will dominate.

Ok then.

I don't understand how can you argue on something I never said.

I never said c++ is the only language that apps can be written in. I said c++ is the only language that apps that require performance can be written in. There is a difference.

Writing it in Java pretty much diminishes the need to use other languages.

Ok, I admit that was a little bit over the top.

But at least it got your attention :-).

I would like to note here that it is not an unusual phenomenon for people to support others based on ethnicity or other attributes. For a moment, the collective a.cc reaction seemed like something similar happened.

Allegro 5 is not old. It could have been written in other languages.

I never said anything else.

I agree with this as well. I've already said this.

But I never said that!

It's very funny, but everyone understood something else from what I said.

Let me say it again:

Applications that need performance should be written in C++.

Again, I agree, with two exceptions:

1) some apps require performance that even tomorrow's PCs can not deliver.
2) PC performance can not grow indefinitely. People are already say that and seeking concurrent solutions.

I don't have any fascination with anything, including performance. It is people that like to get their job done as fast as possible and then go on and do other things.

But the difference is not always that small. Perhaps in the 10 megapixel range, garbage collected languages choke and invoke the collector a lot of times, whereas because C++ has manual memory management, no such thing happens. And then, in your example, resizing a 10 megapixel picture to a thumbnail becomes a 2 second job, and thus it becomes frustrating.

Who said anything about using ASM? I just offered an example of where more performance justifies the use of a more primitive tool.

My data are not biased at all.

Take, for example, databases like DB2, used in enterprises.

If the database was written in Java, for example, wouldn't it have a big performance hit?

In that domain, every bit of performance counts.

I did not present any benchmarks, but I presented code, which makes it obvious why c++ offers better performance.

It may not matter to you. Or me. But it matters to those that make applications using, for example, the databases mentioned above.

It's not that easy, but the use of Java pretty much diminishes the need to use any other language. The major advantage of these languages, i.e. garbage collection, is also an advantage of Java.

Are there any major games written in anything else than c++? I am asking, I don't know.

Agreed. Nothing more to discuss from my side!

Runescape is written in Java. I used to know some more games when I still was interested in Java
There are some indie XBox games written in C# and xna. Don't know how much it is used by the "big" developers.

You know, except for USER BASE.

Its a bitch to bind to C++, so we choose C. And every other language including C++ bind to C nicely.

Your argument is morphing again! You went from must be in C++ to should be in C++ in one post!

Bear in mind that you're speaking to a non-native speaker, for whom nuances of language may not be interpreted in the same way as for you.
I think you're overinterpreting a difference in wording where no difference in meaning was intended.

I'm not so sure. Non native speakers tend to be more anal about the rules than native English speakers. I couldn't care less about them to be honest, but theres several here on the forums for whom its their second or even third language which seem to be highly anal about the rules and various nuances.

The only people I've ever seen that cared so much about it, were all English majors, or professors.

A quick scan with a code counter shows Allegro 4.2.2 having some 75,000 lines of code. Are YOU volunteering to rewrite all of them?

This seems to be axilmar's main point. Garbage collection (mark and sweep) in every major high level language with an associated vm tends to take up more time than manual memory management. Additional time hogs are error checking and reflection. Without these things any error is likely to completely crash a C/C++ program, but assuming errors don't occur then C/C++ will probably be a winner in terms of performance.

Of course any sufficiently sophisticated program is likely to have a host of errors and it seems more useful to reduce the number of errors by 5% than increase the performance by 5% but it depends on the application domain.

Anyway axilmar, why do you keep claiming that things should be written in C++? C++ is an incredibly thin veil over C and the only other thing going for it (the template system) isn't that impressive compared to other things. Besides the fact that the template system has nothing to do with performance.

If you took out closures I'm sure you could compile Scheme or ML down to C/C++ using explicit memory management. Of course without closures those languages are basically worthless.

Isn't allegro 5 a rewrite?

Kill C++. There are a lot of better languages out there.

I would prefer Pascal. But most people won't. So I vote for C#. With the introduction of Mono, it's multi-platform. And Mono is able to compile C#. So speed shouldn't be a big problem.

Your metric for 'better' is flawed. There are no better languages out there by my metric.

EDIT: Incidentally, has this been posted yet? I like that metric, faulty as it is, more than the platitudes expressed in this thread.

What a shame, it says D is faster than C++.

I guess all performance critical programs must now be written in D.

Yay for D. Now if only they could release D 2.0 sometime soon...

When has that ever been an argument to use one piece of software over another?

Interesting how poor FORTRAN is doing in that comparison. One to give to people who keep insisting that FORTRAN code is faster than C/C++ code (and therefore one should not use C/C++).
Of course, the (valid) counter argument will be that G95 isn't the best FORTRAN compiler around...

EDIT: yes, people do still make that argument...

When you fart in an elevator, it is best to get out at the next floor rather than try to justify it until you (and everyone else) is blue in the face.

I agree with Matt and it has absolutely nothing to do with his nationality. In fact its ingrained into Australian society to hate everything and everyone remotely American like, even Canadians. But I am intelligent enough to think beyond that and measure an argument for what it states and what it doesn't.

SiegeLord wrote 03/15/2009 5:26 PM

> Your metric for 'better' is flawed. There are no better languages out there by my
> metric.

> EDIT: Incidentally, has this [shootout.alioth.debian.org] been posted yet? I like
> that metric, faulty as it is, more than the platitudes expressed in this thread.

The link you provided was to measurements that haven't been updated in at least a year.

Here are up-to-date benchmarks game measurements -

http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=all&box=1

I had a quick look at the C++ and FORTRAN N-body codes they used for comparison, and they're not even doing the exact same thing (in terms of what quantities they calculate) and they don't use the same features (the C++ code doesn't use standard library functions to calculate the square root, for instance).
So take with a bucket of salt.

Maybe throwing in my opinion without any reason wasn't professional and C++ isn't that bad. But "C++ is the holy grail" discussions suck. Many people like C++ because everyone is using it. But that isn't an indicator for its quality. If most people would use fortran they would say exactly the same thing.

That would be cool, but it would be a separate project from Allegro. Allegro is a C library -- that's just what it is. The only way it could spontaneously blossom into a C# library would be if there was a strong feeling by the community that it was necessary.

But if you're seriously interested in doing that, I'd be on board. (We'd obviously be dispatching into a lot of C DLLs, and I've gotten a lot of experience with that working on Allegro#. )

I've tried to do a wrapper for gnu pascal. But gave up, because It was to much work for me at that time. Surely I'm interested. The problem is, that I'm new to C# and mono. So this would take some time.

Evert wrote on 03/16/2009 7:43 AM
Quote:
Here are up-to-date benchmarks game measurements -
I had a quick look at the C++ and FORTRAN N-body codes they used for comparison, and they're not even doing the exact same thing (in terms of what quantities they calculate) and they don't use the same features (the C++ code doesn't use standard library functions to calculate the square root, for instance).
So take with a bucket of salt.

double distance = sqrt(dx * dx + dy * dy + dz * dz);

http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=gpp&id=1

Aww... the newest ones don't have D in them... how sad.

I wish the whole point was in that sentence: I'd put in my signature.

Screw benchmarks! What does teh internetz say?

Here's the one I get if I just follow C++ / nbody from the first link.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=gpp&id=4
Definitely different.

Evert on 03/16/2009 2:17 PM
Quote:
double distance = sqrt(dx * dx + dy * dy + dz * dz);
Here's the one I get if I just follow C++ / nbody from the first link.http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=gpp&id=4
Definitely different.

There are currently 3 C++ nbody programs.

http://shootout.alioth.debian.org/u32q/benchmark.php?test=nbody&lang=all

Point is, you're not comparing languages or compilers fairly if you're not running essentially the same code in each case.

To clarify that: the code should use the same algorithm to solve the exact same problem, using only standard language features. It should also probably be optimised to the same level in both cases.

Why? Not all algorithms translate well to the languages. You wouldn't use the same algorithm in Haskell that you would in C for example. Not all optimizations would have the same effect too.

I don't think that's a problem. They seem do disallow the graver cheating (no implementing a function in C, and then calling it from a language X and calling that a program in language X). The bigger problem (plaguing most benchmarks) is that their programs are unrealistic and artificial, being small and unflexible. And this point is why it's called a language benchmarks game.

Isaac Gouy, please use the

<quote>
</quote>

tags .

That's not quite what I meant. Comparing random code that uses different algorithms is not a good way to compare programming languages.
If Haskell allows you to write a better algorithm, that's fine - it's the better tool for the job. In this particular case, the comparison is C and FORTRAN, and you can easily write the same algorithm in both if you want to compare - and in fact you should.
That doesn't mean you shouldn't use language features; one of FORTRAN's strengths are its intrinsic array operations. You'd be a fool not to use those if you can.

What you should not do is take C++ code that uses compiler-specific optimised functions and solves an N-body problem in effectively two dimensions (the example I linked to effectively does this), compare it to a FORTRAN program that solves the same problem in three dimensions using standard library functions and then claim that the C++ code is faster, because you're not doing a fair comparison.

Well yes, there is that too. Point one way or the other being, those bench marks don't mean too much.

IMO, the main reason why performance-critical applications are still written in C++ is that most of them stem from a codebase from way back when C++ was simply the most advanced language available. Parsing SQL commands, optimizing queries, managing data streams and all that are a major pain to implement, and if you have an existing codebase that solve those problems well enough, you better stick to it rather than re-code the entire thing in a newer language.
About the GC: C# at least allows for manual memory management when needed (using unsafe code), so the argument that GC is what breaks performance isn't entirely valid. In the hands of a skilled programmer, I'm pretty certain that C# can and will produce code that is at least comparable in terms of efficiency. There may even be cases where JIT compilation yields an advantage: the JIT compiler may choose to use optimizations specifically for the system it currently runs on, taking advantages for which a C++ version would have to jump through quite some hoops for(e.g. producing 64 bit code when it runs on a 64 bit CPU, taking advantage of vendor-specific CPU instructions, optimizing for memory usage or cpu clocks based on the system specs, ...).
No matter what application you write, as soon as a certain critical mass in terms of program size is reached, it becomes very likely that memory management needs to be organized in some way; in C++, people usually end up implement either a smart pointer or a garbage collector anyway (or use an existing library), while C# and Java have it built in. (And as stated above, C# at least gives you enough control to bypass it where the extra performance is worth the effort).

Then there's the JIT compilation overhead; but since JIT compilation happens only at load-time, it doesn't affect runtime performance once the application is fully loaded; especially with databases, the startup time is relatively uninteresting (when the server goes down, you're screwed anyway unless you have a failover).

Yet another possibility I expect future applications to use is to split up the codebase into a performance-critical lower layer (written in C++) and a higher level 'user code' layer (written in a more comfortable language). Microsoft makes this fairly easy, although managed C++ (which can be used to glue plain C++ together with other managed code) has very ugly syntax.

I also think that your definition of 'major' (performance critical) doesn't match what the rest of us can agree on (large code base, large user base, large number of features).

It's not that important for Allegro. There are not many users who use Allegro through less popular programming languages anyway.

Writing it in C is good for marketing reasons though: "our library is accessible from every language! yeay!"

Ok, if you want to be so pedantic. There is a minor difference between 'must' and 'should', and although my native language is not English, I understand your comment.

Let's stick with 'should'.

Exactly. In Greek, there is one word for both ('must' and 'should').

Allegro 4.9.8 is 66,000 lines of code. It's not that big. With Java, it could probably be a lot less.

I would certainly volunteer, if I did not have to work a full time job.

Exactly.

I disagree about the template system. Compare Java Generics to c++ templates: autoboxing vs native values. Native values win.

I am not so sure about that. They both do not have structs, do they? they fake structs by using the function 'nth' for accessing the 'nth' member of a list. And then in Scheme, polymorphism is achieved through tagged values, which might be slower than vtables. Feel free to correct me if I am wrong.

I agree! but replace it with something with equal performance. It's possible. There is no need to sacrifice performance.

If you manage memory manually, then you are not using the GC. So you can't really say that "the GC does not break performance".

Modern C++ compilers do most of that.

There is only one garbage collector for C++, and that is the concervative Boehm collector.

It is not possible to use the Boehm garbage collector in C++, due to preprocessor and linking issues, unless your app does not contain 3rd party libraries and very little STL (I've been there and tried it).

Smart pointers are good. I've recently finished a 75,000 lines of code project, which use smart pointers. I have no memory leaks, but I needed to copy the boost code, since my Qt library (old version, 3.0.5) is not compatible with boost.

Are you sure? because the VM engine monitors the execution of virtual calls in order to replace them with 'if'.

But that would make C++ a necessary tool for these apps.

So? that does not make my definition wrong or yours wrong. We simply talk about different things.

At compile time. Which, for C++, is before shipping. Halfway compiled languages perform their final compilation step at run time, which means they can take optimizations based on the specific system they are actually running on, instead of the system they were compiled for.

Let me rephrase then: The fact that C# offers GC, and that C#'s GC is turned on by default, doesn't necessarily break runtime performance. In C#, you are free to mix GC'ed code (a.k.a. 'managed') and manual-allocation code ('unsafe code' in C# lingo), with all the consequences this implies. However, where GC is hard to implement or use in C++ (as you state yourself, it's so hard that most people resort to smart pointers, which are typically faster but have a problem with reference cycles), and manual allocation is relatively 'easy', C# reverses the situation by making manual allocation slightly harder (you need to put relevant code inside an unsafe {} block, and your application needs to acquire permission to run unsafe code), and GC'ed code very easy.

I'm not sure, no. What the VM does at runtime, is basically a secret to me. However, when and if the most basic method (a plain compilation from the IM / bytecodes into the current platform's machine code) is NOT chosen, the only obvious reason I can think of is that whatever they use instead is faster in most cases.

Not necessary, no. Only if the development team chooses to use this option. It would, however, turn a 'major application written in C++' into a 'major application written in C# / Java / ..., with some low-level functions written in C++'. The fact that the Paint.NET team chose to use C# even for low-level functions shows that even things like image processing can be coded in C# efficiently enough to not mandate C++.
As for databases; I think the main reason we haven't seen one written in C# or Java is that in order to succeed at that level, one has to compete with the current major players (MySQL, PostgreSQL, Oracle, SQL Server), all of which have been around longer than C# or Java and tap into a huge code base; and since the rise of C# and Java, there hasn't been any entirely new competitor, in any language. I have no idea how well a Java-based heavy-load database would perform, but to be honest, neither does anyone else, simply because there is no such thing yet.

Huh? If you are writing all of your low level high performance functions in C++, then you are not taking advantage of JIT compilation. Why have the JIT if you still have to use the non-JIT compiled code for performance critical components?

Saying that you can write high performance code in C++ and then use it from C#, and then declare that C# is high performance is silly.

As for that, I've heard reports that Paint.NET is a slow program, so I'm not so sure about that. I haven't used it enough to check.

EDIT:

What about OSS software? Gentoo et al? Plenty of people compile C/C++ software on end user systems. I remember when I first used Paint.NET is did this compillation stage, and it took about as long as compiling C/C++ programs from source takes. I don't know how widespread this is, but maybe it's possible to halfway compile C/C++ too, distribute ready to link object code for non-performance critical parts, and the source to the performance critical parts, and then have the compiler compile only the latter files, and the linker link everything together.

I didn't say you have to. I just presented it as an alternative to using C++ for everything, so as to draw the benefits from both worlds. This doesn't mean that it is impossible to use C# for everything.

I have never heard of any such thing, except for Microsoft's 'managed C++', which is basically C++ with some syntax extensions for garbage-collected types that compiles into IL instead of machine code.
'As long as compiling C/C++ programs from source takes' is a bit vague - 'Hello world' takes less than a second, but large projects might easily amount to several minutes, maybe even hours, for a full build.

Thats almost right. Structs are made with vectors (basically constant sized lists) and doing the nth element of a vector is basically the same as array lookup (i.e. extremely fast).

Yes polymorphism is achieved with tagged values but vtables don't come into play there. All data types are tagged using the lower two bits so that native types can be used (you are right with the autoboxing vs native type thing). The class systems don't use those tags and have their own vtables somewhere.

(I can really only talk about mzscheme since I know the implementation, other schemes might do things differently but the fast ones probably do things the way I described.)