Re: C++ Speed Vs. Java

I of course don't know what James had in mind but I share his
conclusion after completing two medium-to-large projects which were
both developed in parallel in C++ and Java with exact same purpose and
external functionality.


found problematic. Here is the short list I could come up with in a
couple of minutes.

1. You mentioned that Java can easily separate interface from
implementation making headers unnecessary. However there is one small
detail that ruins it. Java interfaces are always public in a package.
There is no way to have a hidden internal interface. Which means that
as soon as you created an interface be prepared for an ignorant client
to use it even you you marked it as "internal do not use" in the
documentation. This is not a problem for a smaller projects but a
serious one for big ones that may have uncontrolled external clients.
C++ makes this much less of a problem because you can separate public
and private header files. (Of course things can always be
reverse-engineered but at least in C++ you are safe from accidental
misuse)

2. Do you know that "protected" in Java opens the access not only to
derived classes but also to any class within the package? Good bye
encapsulation. If you want to establish controlled communication
between parent and child classes you expose your internals to anybody
(maintenance programmer) working on the same package

Incidentally 1 and 2 both stem from the fact that Java 'married'
visibility with access control for security

3. In the library a huge amount of things are runtime error instead of
being impossible or compile time ones. Here is one example. Java
Iterator interface (the only one you can use if you want compatibility
with the rest of the library and foreach loops) has a remove() method
that erases the element pointed to. The only way to disallow removal is
to throw an UnsupportedOperationException from it. That's right, if you
want to let somebody iterate over your collection you either allow them
to remove stuff from it or expose them to a runtime error.

4. There are no const references. Please tell me what happens in this
Java code

void doStuff(Foo foo)
{
   Bar bar = foo.getBar();
   bar.setBogosity(42);
}

Did it modify the Bar stuff stored it Foo or a local copy? That's
right, you don't know and the documentation is unlikely to tell you
since authors of Java libraries don't think about the issue. This is
why all good Java coding standards recommend making classes immutable
(see for example Effective Java book which is similar in status to
Effective C++ in Java world)

5. Since everything is a pointer everything can be null. You cannot
enforce that something is not null at compile time. No matter how hard
you try you will leave a lot of undetected nulls around to be found by
your customers. ;-)

6. Verbosity. An average line of Java code is much longer and harder to
read than in well written C++.
This is because a) there are no typedefs which starts to really hurt
now when we have generics i.e.

Foo<? super X extends Comparable<? extends Bar>> foo; //Java

vs.

Foo_t foo; //C++

b) everything has to be newed but there is no auto deduction

  Foo<? super X extends Comparable<? extends Bar>> foo = new
   Foo<? super X extends Comparable<? extends Bar>>(...);

vs.

Foo_t foo;

c) no free functions so you have

SomeClass.foo(AnotherClass.bar(a, b), c)

vs.

foo(bar(a, b), c);

and a few others such as no package name aliases or partial package
names, no operator overloading etc.

7. There is no concept of "binary module" which in [practical] C++ is
played by shared libraries/DLLs. You just get classes from wherever the
environment is configured to load them. Let me clarify why this
important. In [practical] C++ I can say "let's load the library foo.so
from this specific location". After I did this and assuming I put
foo.so in this location in the first place I can be reasonably sure
that classes Foo and Bar contained in foo.so match and can work with
each other. In Java (with standard class loader) all I can do is to ask
for class Foo and class Bar and pray that they come from the a single
..jar or even from a .jar I wanted them to come. There are ways around
it with custom loaders but they are complicated and not always
applicable. I have lost count of times I had to spend time researching
a bug caused by the fact that the system picked up a wrong .class file.
We solved these issues at the end but it was a big effort that wasn't
needed in C++.

Well, that's a long enough list already though I am sure there is more.
That is not to say C++ doesn't have its own huge issues but on the
balance I'd prefer to write something big in C++

--
Eugene

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]