Can I use something other than dynamic_cast in this design?

Question

In our system, we have

• multiple deviceTypes
• each deviceType can have a different configuration type
• each deviceType will be a library of its own

I'm in a situation where I am forced to use dynamic_cast. I'm wondering if there is a better way to design this ?

what I have is:

// in common code
class Config {public: virtual ~Config(){} }; 

    class Device {
     protected:
        Config* devConfig;
    protected:
        virtual void createDevConfig() = 0;
    public:
        virtual void display() = 0;
    };

    // Device specific Code
    class A0Device : public Device {
    protected:
        virtual void createDevConfig() { this->devConfig = new A0Config(); }
    public:
        A0Device() { this->createDevConfig(); }

        virtual void display(){
        A0Config* config = dynamic_cast<A0Config*>(this->devConfig);

        if(!config) std::cout << "Null object\n";

        }
    };

    class A0Config : public Config {};

    int main() {
        Device* dev = new A0Device();
        dev->display();
        return 0;
    }

Essentially A0Device has its own config type: A0Config, which is composed of other members. A0Device has devConfig defined as Config* in base class. In A0Device::display() - I need to access the devConfig object (as A0Config type). The virtual createDevConfig() ensures the config object will always be of type A0Config in A0Device => Is it safe to use dynamic_cast here ? Is there a better way of designing this ?

Answer 1

If you can support the extra (minimal in general-purpose systems, enormous in real-time/embedded systems) runtime overhead, you can use dynamic_cast<> safely.

However, you must be aware of this "small" detail. Given the expression dynamic_cast<T*>(expr), whenever the dynamic type of *expr is neither T or a subclass of T, the expression evalutates to the null pointer, nullptr. And, of course, dereferencing nullptr invokes undefined behaviour, and will cause a crash on most platforms.

However, it's probably not worth it checking for nullptr if, ando only if, you know your code shall crash on such a situation.

Because C++ is a bowl with both soup and ice cream, potatoes and coffee, and of course, each idea that came through Stroustrup's/the C++ commitee's ears/mind, there are several alternatives:

• A downcasting static_cast<T*>(expr), although this has the same issues as casting something to something else that it isn't.
• For C people who found it "necessary", reinterpret_cast<T*>(expr) is not necessary in this but it's there.
• If you both think that something is engineeringly-perfect if it works, and you know all the types that the object may have at runtime in a single place, you can use a enum for the type with union for holding the data with placement new with explicit destructor calls supercombo.
• If data stuff is involved in the problem, you can have something like virtual Config &getConfig() = 0 in the Base, and something like ABC123Config config; Config &getConfig { return this->config; } in the Derived.
• For crazyies like me only: Use a C-style/constructor-style cast.

Hope this helps!

Answer 2

You could have a pure virtual function in the base which returns a Config pointer or reference (which I would prefer unless you need a pointer), then have the storage in the derived classes. This question/answers cover the differences between pointers and references: When to use references vs. pointers

The advantage of this design is that anything in the base that needs a Config can use getConfig, while anything that needs to use the derived class can without casting. Plus you don't need to call new and delete.

class Device {
   protected:
      virtual Config& getConfig() = 0;
   ...
};

class A0Device {
public:
   ...
   Config& getConfig() {return config;}
   ...
private:
   A0Config config;
};

Answer 3

[Not sure, if I'm missing something here, but it more or less sounds like a design-smell]

Why can't A0Config aggregate Config?

Quite often, hitting upon dynamic_cast is a clue that something is not right in terms of establishing IS-A relationship. In this case A0Configprovides some functionality (getA()) which doesn't fit into its base class Config, perhaps it is violating LSP-Liskov Substitution Principle thereby violating strong IS-A.

Nevertheless, If a class relationship can be expressed in more than one way, use the weakest relationship that's practical – Herb Sutter

... and Sean Parent goes to this extent. Inheritance is the base class of evil