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.

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.

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.

PHPEdit is actually written in Delphi...

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 haven't forgotten any of those things. None of them affect what I've said.

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.

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

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++.

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.

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

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 seems like a very biased chart, to say the least.