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

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.

They're different languages. <- how's that for short.

The OP's title is a bit confused. 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. The sequencing of object construction is part of the object model. The key difference between C++ and Java is actually that Java is garbage collected, whereas C++ is not.

Another core differences is that Java uses archaic crud for polymorphism, whereas C++ uses a broken template concept: in C++ templates are compile time and don't impact the object model, in Java polymorphism is hacked around what in C++ is called a dynamic cast.

Another major core difference is that Java supports threads whereas in C++ you have to use a library of some kind.

There are lower level type system differences too: Java has minimal static typing but otherwise is basically a dynamic language. C++ on the other hand is almost entirely a statically typed language, with the exception of exceptions ..:)

A bit of Java:

class Base
{
    public static void say( String s )
    {
        System.out.println( s );
    }

    public void sayHello()
    {
        say( "Base.sayHello says..." );
        say( "Base hello" );
    }

    public Base()
    {
        sayHello();
    }
}

class Derived
    extends Base
{
    private String[] myWords;   // = new String[]{ "Derived", "hello" };

    public void sayHello()
    {
        say( "Derived.sayHello says..." );
        say( myWords[0] + " " + myWords[1] );
    }

    Derived()
    {
        myWords = new String[]{ "Derived", "hello" };
    }
}

class ConsCallDemo
{
    public static void main( String[] args )
    {
        Derived o = new Derived();
    }
}

Output:

Derived.sayHello says...
Exception in thread "main" java.lang.NullPointerException
        at Derived.sayHello(conscall.java:28)
        at Base.(conscall.java:16)
        at Derived.(conscall.java:32)
        at ConsCallDemo.main(conscall.java:41)

The problem is that in Java the calls go down to the class that the object is instantiated from, even before that instance has been initialized.

C++ guards against this problem by dynamically adjusting the type of the object during construction and destruction. In C++ the object is of type Base when the Base constructor executes. Thus, calls from within the Base constructor behave is if the object was instantiated from class Base, regardless of actual instantiation class.

Example of that, just translating the Java code above to C++:

#include <iostream>
#include <string>
#include <vector>
using namespace std;

void say( string const& s )
{
    cout << s << endl;
}

class Base
{
public:
    virtual void sayHello() const
    {
        say( "Base::sayHello says..." );
        say( "Base hello" );
    }

    Base()
    {
        sayHello();
    }
};

class Derived
    : Base
{
private:
    vector< string >    words_;

public:
    void sayHello() const
    {
        say( "Derived::sayHello says..." );
        say( words_[0] + " " + words_[1] );
    }

    Derived()
    {
        words_.push_back( "Derived" );
        words_.push_back( "hello" );
    }
};

int main()
{
    Derived o;
}

Output:

Base::sayHello says...
Base hello

One way to obtain the probably intended effect in C++, which also suggests how to do it (properly) in Java:

#include <iostream>
#include <string>
#include <vector>
#include <boost/shared_ptr.hpp>
using namespace std;

void say( string const& s )
{
    cout << s << endl;
}

class Base
{
protected:
    struct Greeter
    {
        typedef boost::shared_ptr< Greeter >    Ptr;

        virtual void sayHello() const
        {
            say( "Base::sayHello says..." );
            say( "Base hello" );
        }
    };

private:
    Greeter::Ptr    greeter_;

public:
    void sayHello() const
    {
        greeter_->sayHello();
    }

    Base( Greeter::Ptr greeter = Greeter::Ptr( new Greeter ) )
        : greeter_( greeter )
    {
        sayHello();
    }
};

class Derived
    : Base
{
protected:
    struct Greeter
        : Base::Greeter
    {
        vector< string >    words_;

        virtual void sayHello() const
        {
            say( "Derived::sayHello says..." );
            say( words_[0] + " " + words_[1] );
        }

        Greeter()
        {
            words_.push_back( "Derived" );
            words_.push_back( "hello" );
        }
    };

public:
    Derived()
        : Base( Greeter::Ptr( new Greeter ) )
    {}
};

int main()
{
    Derived o;
}

Output:

Derived::sayHello says...
Derived hello

Regarding your other points, it's too much to discuss here. Just be aware that C++0x will support much more practical initialization than C++98. And also that the formal side of your point 7 is a bit contested, there's a Defect Report about it (it was not allowed in pre-standard C++ as described by the Annotated Reference Manual, but it was apparently intended to be allowed in standard C98, however, the wording is a bit self-contradictory).

Cheers & hth.,

About 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.

If you were able to hide a superclass method that would not guarantee your method can not be called by a user. One could always cast to the superclass and call the method, since all non-static methods in Java are as C++ virtual methods your subclass method would actually be called.

It would work with static methods but I don't think overriding static methods is a good practice.

The need to hide methods in subclasses usually means bad design, but if you really need to, you should throw an exception. The down side of this is that it's runtime, but when a call occurs it WILL crash. Whereas in C++, if you hide a method but cast to the parent class, if its virtual the method will actually get called and if it's statically linked the parent class method will get called, both are probably not what you want.