Abstract Class like Java

[sarmadys]

Hi everyone,

I am converting my large scientific simulation program into C++ (currently in Java). I appreciate if you can advise on below issues.

My design has excessively used abstract classes and interfaces which do not have implementation or just incomplete implementation. Now I want to have almost the same thing (for use in Factory pattern ... for example).

Does this code make sense to you (specially the main() function). Do you see any problem?

class Vehicle {
public:
	Vehicle();
	virtual ~Vehicle();

	virtual void start()=0;
	virtual void run()=0;
};
----
#include "Vehicle.h"

Vehicle::Vehicle() {
}

Vehicle::~Vehicle() {
}



----
#include "Vehicle.h"

class Car: public Vehicle {
public:
	Car();
	virtual ~Car();

    void start();
    void run();
};
----
#include <iostream>
#include "Car.h"
using namespace std;

Car::Car() {
}

Car::~Car() {
}

void Car::start()
{
	cout << "car started" << endl;
}

void Car::run()
{
	cout << "car is moving" << endl;
}


----
#include <iostream>
#include "Car.h"
using namespace std;

int main() {
	Car car1;

	Vehicle& v1=car1;
	v1.start();
	v1.run();

	return 0;
}

Is there any other way to implement java interfaces in C++? Or abstract classes?

Thanks in advance.

Mac

[monarch_dodra]

Looks correct to me. Consider using a pointer instead of a reference though when dealing with polymorphic classes.

While references work, most C++ programmers are more used to dealing with polymorphic classes through pointers. References use value syntax, and users can be confused to see a dynamic calls when they expected a static one (as expected from a direct by value call).

That said, if your background is Java, it shouldn't be a problem for you.

Java interfaces works pretty much like a C++ pure virtual abstract base classes. The differences are that in C++, a class can adhere to more than one interface (multiple inheritance), and that in C++, you can give default implementations to functions in the abstract base class, including the pure virtual ones.

[JohnW@Wessex]

You don't need 'virtual' for the Car destructor.
Once 'virtual', forever 'virtual'.

[JohnW@Wessex]

Is there any other way to implement java interfaces in C++? Or abstract classes?

You may find that some techniques that you were using in Java may not be optimal in C++. I've seen Java code where multiple inheritance/mixins has been emulated using separate interface and and implementation classes. In C++ you can make them one and the same. Multiple inheritance can reduce the code replication or 'workarounds' that can occur when you are forced to only inherit interfaces.

[D_Drmmr]

Java interfaces works pretty much like a C++ pure virtual abstract base classes. The differences are that in C++, a class can adhere to more than one interface (multiple inheritance), and that in C++, you can give default implementations to functions in the abstract base class, including the pure virtual ones.

Seems like you are confusing terminology. AFAIK, there is no such thing in C++ as a virtual base class. You have abstract (base) classes, which are classes that have at least one pure virtual function.

In C++ there is no notion of interfaces as there is in Java. Instead, a class can have a mix of pure virtual functions (thereby making the class abstract) and other members. Also, you can derive an abstract class from another class. So, you can mimic Java interfaces in C++ by making all functions pure virtual, but there is nothing that limits a class from having member variables or (non-pure virtual) member functions.

[laserlight]

AFAIK, there is no such thing in C++ as a virtual base class.

There is, except that it is in the context of virtual inheritance.

[monarch_dodra]

Seems like you are confusing terminology. AFAIK, there is no such thing in C++ as a virtual base class. You have abstract (base) classes, which are classes that have at least one pure virtual function.

You are correct, I crammed one too many word in there.

[Lindley]

The biggest consideration when moving from Java to C++ is whether the inheritance paradigm is even optimal. It may be; but in many cases, C++ has better ways to solve problems which Java just shoves into the inheritance framework. Consider whether you really need *runtime* polymorphism (inheritance), or whether compile-time polymorphism (templates) will do.

Java uses the "new" keyword everywhere, but that's not appropriate in C++. Dynamic allocation is expensive, so don't do it more than necessary. Make use of scoped objects (something Java almost entirely lacks) as much as possible, and when you do dynamically allocate, leverage smart pointers to make your memory handling cleaner and safer.

[Zaccheus]

Here is a very simplified example of what I might do in C++:

--- VehicleInterface.h ---

struct VehicleInterface  
{
    virtual void start()=0;
    virtual void run()=0;
};

--- Car.h ---
#include <iostream>
#include "VehicleInterface.h"

class Car: public VehicleInterface 
{
public:
    virtual void start()  { std::cout << "car started" << std::endl; }
    virtual void run() { std::cout << "car is moving" << std::endl; }
};

--- Plane.h ---
#include <iostream>
#include "VehicleInterface.h"

class Plane: public VehicleInterface
{
public:
    virtual void start(){ std::cout << "Plane taking off" << std::endl; }
    virtual void run(){ std::cout << "Plane is flying" << std::endl; }
};

--- Traveler.h --- 
#include "VehicleInterface.h"

class Traveler
{
public:
void useVehicle(VehicleInterface& vehicle)
{
	vehicle.start();
	vehicle.run();
}

};

--- main.cpp ---
#include "Car.h"
#include "Plane.h"
#include "Traveler.h"

int main() 
{
	Car    car;
	Plane plane;

        Traveler traveler;

        traveler.useVehicle(car);
        traveler.useVehicle(plane);

	return 0;
}

As you can see, and are no doubt familiar with, is the concept that the traveller does not know anything about cars and planes. Notice that my interface is written as a struct with only pure virtual functions.

[sarmadys]

Thanks everyone for your great information. I really enjoyed every single message in this thread.