Re: C++ Speed Vs. Java
Thomas Richter wrote:
James Kanze wrote:
That is also unexpected and interesting to me. What particular reasons
could make Java inappropriate for large scale projects?
The fact that you cannot separate the external specification of
the class and its implementation into separate files is almost a
killer. (The C++ solution here---header files, with textual
inclusion---is probably about the worst one you could think of,
but it's better than no solution, and with a bit of discipline,
works.) Trying to do any form of programming by contract tends
to be difficult as well---it requires using abstract classes
instead of interfaces, which in turn means that you cannot use
multiple inheritance.
Sorry, but I don't buy this. I would rather say it's the other
way around. In Java, if you want to have external specializations,
you write an interface and implement it by a class, and the
class is then the implementation.
That's the usual work-around, but there are things that you can
do with a class, like create instances, that you cannot do with
an interface.
The interface makes no statements
on the internal workings of the code whatsoever and doesn't make
the internal state of the class visible. On C++, however, you
still have all "private" data readable (by the human) in the
header file, and it IMHO really shouldn't belong here, it's an
implementation detail.
Which is a serious (and known) flaw in the C++ model; in
practice, at the application level, we use the compilation
firewall idiom a lot because of it.
So likely, I think this is a
misunderstanding how to express the concepts within Java.
There is a definite difference: in C++, I can define a class,
without implementing it. Other people can then write code
against that definition, and compile their code, effectivelly
working in parallel with me while I implement the class.
In Java, I have to define an interface. Other people cannot
write all of their code against it, since they cannot write
anything which creates an instance of it. They have to wait
until I've finished the implementation of the actual class.
Of course, something the like can be arranged in C++ using the
pimpl idiom, but it requires additional work and is not expressed
in the syntax of the language itself.
And in Java, it cannot even be arranged.
[...]
What I - personally - consider most irritating in Java that you
do not have destructors, and thus cannot really release resources
at controlled times without writing additional code - it cannot
be expressed in Java.
You have to write the additional code in C++ as well, the
destructor:-). The problem isn't that you, as author of the
class, has to write additional code; the problem is that every
single one of your users will have to write additional code, at
the site of use. And that's very error prone.
I agree that its a serious drawback in Java. One could argue
that it affects large projects more, since it increases the
communications burden; I didn't mention it, because I find that
it also affects even small projects negatively.
I'm also working here on a code using Corba
on the Java side, and now it's cluttered with "close()" methods
all over the place just to ensure that the Corba proxies are shutdown
early, with the result that you can have Zombie objects, etc.
Not to mention that the lack of out parameters means a lot of
extra proxy objects.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]