Re: On Java and C++
"peter koch" <peter.koch.larsen@gmail.com> wrote in message
news:1146177855.488879.211610@e56g2000cwe.googlegroups.com...
Very interesting post, Koch. I've snipped the parts I've agreed with, and am
only including some concerns I have about C++ and clarifications on Java.
I do not
understand why each class MUST have its own file (unless you make that
class a secondary citizen).
Actually, only the top level public classes should be in their own
files. Private classes, or nested classes, can be within any file. I suspect
the reason why is primarily a pragmatic one: So that the classloader can
easily locate the file that contains the bytecode for the classes and load
them.
It has some nice side effects. When I'm given someone else's code base,
and I have a qualified class name, I always immediately know the full path
to the source code file. I don't even have to browse a directory listing or
anything like that.
There are three kinds of lies. Lies, statistics and benchmarks.... or
so I've heard. The nice thing about C++ strings is that the number of
characters in a string is a O(1) operation. In Java, you would have to
check the number of surrogates making it a O(n) operation. Also C++
strings are more powerful than Java strings. All in all I believe I'd
prefer using C++ strings, switching to some specialised class in the
unlikely case string-handling did turn up to take a significand part of
my programs execution time.
I'm surprised unicode-stuff would appear as an advantage of C++ over
Java. I won't dispute this, since I don't know enough about the state of C++
libraries, but I was under the impression that the lowest common denominator
for C++ was ASCII, while the lowest common denominator for Java was the BMP
(Basic Multilingual Plane) portion of unicode.
I can't speak for others (e.g. archeologists, etc.), but I've never used
characters characters outside the BMP. For example, while I am interested in
writing text in English, French and Japanese, I am not interested in writing
in cuneiform, cypriot, or byzantinne musical notation. So I've never had a
problem with text in Java applications.
However, I have had problems with C++ applications which assumed ASCII.
WinAmp is one example. It has trouble handling the ID3 tags of my Japanese
songs. iTunes seems a bit better at this. *SOMETIMES* it properly renders
the kanji characters, but other times the track name will show up as a bunch
of question marks.
So I was under the impression that C++ support for unicode was behind
Java, not ahead of it. I guess times have changed.
Javas type system is not freedom but rather a jail. It has prevented
porting of Java to several platforms, it gives cumbersome Unicode
support and it forces Java to stick with inefficient 32-bit integers in
a world that is soon turning to 64 bits.
In its defense, I think the fact that the size of Java's primitive
datatypes remains constant is a "good thing". If an when you want to use a
64 bit datatype, you'd simply use "long" instead of "int". And I don't think
there's any technical reason why, in a few years from now, if 128 bit were
desired, a new datatype couldn't be added to Java to support that, without
breaking any previous code (except possibly via the addition of a new
keyword, which could no longer be used as a variable or method name).
The company I work at, Castor Technologies, makes some money by porting
C code from 32 bit platforms to 64 bit platforms. The fact that we're making
money must mean it's too painful for our clients to do the migration
themselves. I don't know if this C situation applies to C++ as well.
- Oliver