Serializing a class hierarchy to JSON I have a hierarchical object structure which needs to be converted to JSON. I have a following basic implementation of how it will be done:

#include &lt;iostream&gt;
using namespace std;

class base
{
    public:
    base():a(1){};
    void serialize()
    {
        cout&lt;&lt;"{"&lt;&lt;endl;
        toString();
        cout&lt;&lt;"}";
    };
    virtual void toString()
    {
        cout&lt;&lt;"\"base-a\": "&lt;&lt;a&lt;&lt;endl;
    };

    private:
    int a;
};

class derived: public base
{
    public:
    derived():b(2){};
    virtual void toString()
    {
        base::toString();
        cout&lt;&lt;"\"derived-b\": "&lt;&lt;b&lt;&lt;endl;
    };

    private:
    int b;
};


int main() {
    derived d;
    base&amp; b = d;
    b.serialize();
    return 0;
}


The only problem I see here is when derived is extended then that class' toString function has to call the toString function of derived and so on.

Is calling a overridden function from overriding function a bad practice?
Is there a better way to write this code?

Note: I cannot use C++11.
Is calling a overridden function from overriding function a bad practice? Is there a better way to write this code?


If you are adding serialization support to an existing class hierarchy, then what you are doing is A-O-K.

However, if you are in the process of designing that structure, then it's indirectly considered bad practice.

The whole "subclass to extend" design pattern is frowned upon in general by modern design sensibilities. 

If you want to be "modern", then your virtual functions should be pure in the base class, and your class hierarchy should rarely go beyond a single inheritance depth. 

The mantra is "prefer composition to inheritance, unless you need type erasure". However, this doesn't mean that everything is fair game as soon as type erasure is needed. You should still strive to limit your use of hierarchy to the minimum required in order to achieve erasure, i.e: Base classes should be pure interface classes, nothing more.

The details on how best to do that really depends on the project, so I can't really go into details here.

Edit: As requested, a more in-depth explanation of composition vs inheritance.

Disclaimer: It's a fairly subtle, almost academic, subject.

The theory goes like this: 


Apart from type erasure, there is nothing gained by inheritance that cannot be accomplished through composition.
Composition is more flexible. Primarily because you don't run the risk of running into clashing namespaces, but also because diamond patterns are easier to work with.


A good example of this is shared_ptr&lt;&gt; vs having a RefCounted base class at the bottom of your hierarchy. 

With shared_ptr&lt;&gt;, which is composition-based, you get a few major benefits:


You can apply the feature to anything, even base types.
You won't run into a diamond pattern if you need to inherit from two interfaces.
You don;t pay for the feature until  you are actually using it.