Why is that? Is the application using only pure C++ and nothing outside the standard?

Perhaps the biggest problem with C++ is the extreme ease with which one finds oneself lost in the dreadful land of undefined behaviour...

Not really. By itself C++ is more portable than Java et al. In fact, the problem is rather that C++ is too portable (ie general)!

For example, for I/O there is the basic notion about files for example, but anything more specific (like, directories or how to get a list of files etc. And don't even mention graphical thingies!) the standard is completely silent, precisely too keep things as portable as possible.

That means if one wants non-general things, one has go outside the C++ standard. Preferably there is some other standard to follow then, such as POSIX, or maybe QT.

When I think of, por ejemplo, the word pronounced as 'hait' [*], I don't have to "translate" that at all. No, sir! Just type it straight in, exactly as it is pronounced: "height" of course! =)

[*] IPA doesn't work on /.

If true, g++ is broken and needs to be fixed.

You are certainly insistent about the badness of that missed return statement :) But it is certainly not true that in plain C such a bug can only cause data corruption (if that were even desireable); just imagine the consequences if the return value is a pointer...

What is the language design problem, and is there a better solution than RAII?

Well, C++ was never a "preprocessor". Cfront was always a full-fledged compiler albeit the output was not native assembler but C code. The Comeau C++ compiler works on the same principle. There is no need for C compatibility in the language in order to do this though.

When Stroustrup says C compatibility was crucial for its success, it is your final sentence that's relevant: the userbase was originally very small, and they basically demanded C compatibility. In "Design and evolution", Stroustrup explains how he eg tried to fix function declaration to something saner, but his audience threatened to walk-out on him if he did, so he was basically forced to cater to their whims because otherwise the language would be dead.

Without actually having read the "why C++ sucks" argument, I tend to agree that C compatibility was not necessarily a good thing, even if pragmatic.

1. Undefined behavior does not mean that a compiler is supposed to stop with an error. In fact, it means that the compiler should accept the code, but that the standard does not mandate any particular behavior in the code that is generated.
2. This is not equivalent to saying that a function which declares a non-void return type must have at least one return statement.

A compiler is certainly not required to stop with an error, but it is perfectly legal for it to do so:

"1.3.12 undefined behavior
behavior, such as might arise upon use of an erroneous program construct or erroneous data, for which this International Standard imposes no requirements. Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. [Note: permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message)."

Perhaps you are thinking of unspecified behaviour?

What you are saying is not correct. The C++ standard says:

"6.6.3 The return statement
[...]
A return statement without an expression can be used only in functions that do not return a value, that is, a function with the return type void, a constructor (12.1), or a destructor (12.4).
[...]
Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function."

It is perfectly legal for a compiler to issue a warning for this or even an error. I consider a compiler refusing to compile it a superior compiler.

Thanks for stepping up and fielding the question for me :) Japanese already has a phonetic alphabet (well, syllabary) that is very well suited to write Japanese in the kana. Problem is, only small children write exclusively with it. To appear at all literate, kanji is certainly needed. It's actually a lot easier to read a Japanese text if there is kanji, as long as one knows the kanji in question.

You are completely ignorant of both runes and kanji if you think them similar, and that runes fell out of use because the latin alphabet is "superior".

eFuses are not affected by UV light; perhaps you're thinking of EPROM, a completely different technology?

An efuse is a physical alteration of the circuit. An FPGA uses SRAM or flashrom to hold the logic. Coming from PS3, I don't know anything about this Motorola phone, but I do know that people throw around the magical "efuse" whenever something happens that they don't understand. Example: "Sony prevented downgrades with firmware 2.10" -"OMG, they've blown an EFUSE!!" From reading the brief of the previous story, this seems very much like one of those instances...

HAM didn't work quite as you describe. Six bits per pixel were used. The top two bits decided the operation according to: 00: bits 0-3 decides pixel value direct by indexing into the color palette 01: The pixel immediately to the left is copied and the blue component is replaced by bits 0-3 10: The pixel immediately to the left is copied and the red component is replaced by bits 0-3 11: The pixel immediately to the left is copied and the green component is replaced by bits 0-3 The palette also need not be fixed but could be replaced mid screen, as could the resolution. The Amiga had four non-pannable PCM audio channels: two fixed to the left audio output and two to the right. The Amiga blitter could be used for rendering filled vectors, although not in the most efficient manner since it required line-drawing first, followed by a copy and fill.