Differences between the C++ and the Java object model [closed]

Question

1. In Java it is very easy to serialize objects. In C++ it is only safe(?) to memcpy objects as long as they are like C structs (no polymorpism). In C++, if the compiler is able to generate the default (trivial) copy constructor then why can't it generate code for automatic serialization?

2. In Java, only static functions and data members are reachable from the ctor. In C++ I can happily use the non-static members and functions from the ctor.

3. In Java, I can initialize data members inline, in the class. In C++ it is a compile error.

4. In Java I can initialize final members in the ctor. In C++ I have to do the initialization of the const members in the initialization list. In C++, when control reaches the body of the ctor, all the members ctor has run, right?

5. In Java a ctor can call another ctor. In C++ we cannot do that.

6. In Java, the this is not valid until after the ctor returns (escape of the this reference, a bug in multi-threading). When is this valid in C++? The this can easily escape both in C++ and in Java: registering a not yet constructed object to Listeners in the ctor (observer pattern).

7. In Java, I cannot make a public function of the base class private in the derived class. I was shocked to see that in C++ is OK and even useful.

Could anyone give a short explanation for these differences?

Update. Trying to collect the answers got so far.

1. Boost has some serialization-like support. (Tony)

2. Even though I messed up this point, Alf P. Steinbach gave an interesting example.

3. C++0x will support much more practical initialization than C++98. (Alf P. Steinbach) #3 will be legal in C++0x (Ken Bloom)

4. The data members declared in the constructor's own class are guaranteed to have been fully constructed by the time the constructor's {body} starts executing. (c++-faq-lite)

5. C++0x will allow constructors to call other peer constructors (Wikipedia, C++0x)

6. C++03 considers an object to be constructed when its constructor finishes executing (Wikipedia).

7. Things like access control have little to do with the object model: that's a feature of the access control system which is a compile time feature. (Yttrill)

Answer 1

In Java it is very easy to serialize objects. In C++ it is only safe(?) to memcpy objects as long as they are like C structs (no polymorpism).

Java is an interpreted language (or more recently, as Billy comments, JIT compiled), so it has no choice but to carry around metadata baggage of every data type in the program at run time. Between the interpreter, VM, optional compiler and metadata overheads, Java programs need a lot of memory. C++ is a compiled language, where many of the decision Java makes are made once at compile time, and the metadata isn't around for interpretation to guide serialisation at run-time. In general, the metadata isn't exposed even at compile time, probably because different compiler vendors model the program quite differently, and they haven't collectively negotiated a suitable representation. It's also considerable work. Bjarne Stroustrup has some papers on how to expose such information, but it's not even planned for C++0x. Meanwhile, with a little manual markup C++ programs can serialise objects - see boost for a good implementation.

In Java, I can initialize data members inline, in the class. In C++ it is a compile error.

Each C++ constructor provides a complete, independent view of how the object will be initialised. If worthwhile, common construction steps can be factored into a support routine, but the call to that is still visible in the constructor. Having to inspect various assignments scattered through the class would delocalise that, though it can certainly be convenient. Much of a muchness here, I'd hazard.

In Java I can initialize final members in the ctor. In C++ I have to do the initialization of the const members in the initialization list.

This reflects the idea that const members are created with their one and only value, and do not transition from some indeterminate or null state to an initialised state.

In Java a ctor can call another ctor. In C++ we cannot do that.

Yes, it's a little annoying in C++ sometimes - particularly for references and consts that need to be in the initialiser list, but you can factor other common construction steps into a support function. I think C++'s position reflects the job of a constructor in constructing bases, members, pointers to virtual dispatch tables etc. - it's not necessarily possible at the machine code level to call into one constructor from another and have just the right steps execute. The compiler could be required to generate a second callable-from-another-constructor version, or inline the right parts of the called constructor, but that's kind of hidden bloat.

In Java, I cannot make a public function of the base class private in the derived class. I was shocked to see that in C++ is OK and even useful.

Given you acknowledge it's useful, maybe Java should add it.

Could anyone give a short explanation for these differences?

Well, I tried.

Answer 2

Many of these are covered by design philosophy.

In a lot of cases, Java disallowed practices that were dangerous or didn't make sense most of the time. For instance, you cannot call a method from a constructor because there is no guarantee that the members have been initialized until the constructor exits. Java tries not to let any reference to an object escape until the constructor has completed.

In C++ they generally assume the programmer knows all the potential ramifications of his actions and lets them do whatever they want.

Also Java threw away C backwards compatibility, you can't take a C file and hand it to a Java compiler.

The rest of the differences are probably just cases where C++ was designed before Java and Java learned some stuff from problems people had with C++. The same way C# has cleaner syntax or more functionality than Java in some cases, because they learned from Java.