C++ Class design - easily init / build objects

Question

Using C++ I built a Class that has many setter functions, as well as various functions that may be called in a row during runtime. So I end up with code that looks like:

A* a = new A();
a->setA();
a->setB();
a->setC();
...
a->doA();
a->doB();

Not, that this is bad, but I don't like typing "a->" over and over again.
So I rewrote my class definitions to look like:

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

    A* setA();
    A* setB();
    A* setC();
    A* doA();
    A* doB();

    // other functions

private:

    // vars
};

So then I could init my class like: (method 1)

A* a = new A();
a->setA()->setB()->setC();
...
a->doA()->doB();

(which I prefer as it is easier to write)
To give a more precise implementation of this you can see my SDL Sprite C++ Class I wrote at http://ken-soft.com/?p=234

Everything seems to work just fine. However, I would be interested in any feedback to this approach. I have noticed One problem. If i init My class like: (method 2)

A a = A();
a.setA()->setB()->setC();
...
a.doA()->doB();

Then I have various memory issues and sometimes things don't work as they should (You can see this by changing how i init all Sprite objects in main.cpp of my Sprite Demo).
Is that normal? Or should the behavior be the same?
Edit the setters are primarily to make my life easier in initialization. My main question is way method 1 and method 2 behave different for me?

Edit: Here's an example getter and setter:

Sprite* Sprite::setSpeed(int i) {
    speed = i;
    return this;
}

int Sprite::getSpeed() {
    return speed;
}

Answer 1

What you have implemented there is called fluent interface. I have mostly encountered them in scripting languages, but there is no reason you can't use in C++.

Answer 2

One note unrelated to your question, the statement A a = A(); probably isn't doing what you expect. In C++, objects aren't reference types that default to null, so this statement is almost never correct. You probably want just A a;

A a creates a new instance of A, but the = A() part invokes A's copy constructor with a temporary default constructed A. If you had done just A a; it would have just created a new instance of A using the default constructor.

If you don't explicitly implement your own copy constructor for a class, the compiler will create one for you. The compiler created copy constructor will just make a carbon copy of the other object's data; this means that if you have any pointers, it won't copy the data pointed to.

So, essentially, that line is creating a new instance of A, then constructing another temporary instance of A with the default constructor, then copying the temporary A to the new A, then destructing the temporary A. If the temporary A is acquiring resources in it's constructor and de-allocating them in it's destructor, you could run into issues where your object is trying to use data that has already been deallocated, which is undefined behavior.

Take this code for example:

struct A {
    A() { 
        myData = new int;
        std::cout << "Allocated int at " << myData << std::endl;
    }
    ~A() { 
        delete myData; 
        std::cout << "Deallocated int at " << myData << std::endl;
    }
    int* myData;
};

A a = A();
cout << "a.myData points to " << a.myData << std::endl;

The output will look something like:

Allocated int at 0x9FB7128
Deallocated int at 0x9FB7128
a.myData points to 0x9FB7128

As you can see, a.myData is pointing to an address that has already been deallocated. If you attempt to use the data it points to, you could be accessing completely invalid data, or even the data of some other object that took it's place in memory. And then once your a goes out of scope, it will attempt to delete the data a second time, which will cause more problems.

Answer 3

If you really, really hate calling lots of set functions, one after the other, then you may enjoy the following code, For most people, this is way overkill for the 'problem' solved.

This code demonstrates how to create a set function that can accept set classes of any number in any order.

#include "stdafx.h"
#include <stdarg.h>

// Base class for all setter classes
class cSetterBase
{
public:
    // the type of setter
    int myType;
    // a union capable of storing any kind of data that will be required
    union data_t {
        int i;
        float f;
        double d;
    } myValue;

    cSetterBase( int t ) : myType( t ) {}
};

// Base class for float valued setter functions
class cSetterFloatBase : public cSetterBase
{
public:
    cSetterFloatBase( int t, float v ) :
        cSetterBase( t )
        { myValue.f = v; }
};

// A couple of sample setter classes with float values
class cSetterA : public cSetterFloatBase
{
public:
    cSetterA( float v ) :
        cSetterFloatBase( 1, v )
        {}
};
// A couple of sample setter classes with float values
class cSetterB : public cSetterFloatBase
{
public:
    cSetterB( float v ) :
        cSetterFloatBase( 2, v )
        {}
};


// this is the class that actually does something useful
class cUseful
{
public:
    // set attributes using any number of setter classes of any kind
    void Set( int count, ... );

    // the attributes to be set
    float A, B;
};

    // set attributes using any setter classes
void cUseful::Set( int count, ... )
{
    va_list vl;
   va_start( vl, count );

     for( int kv=0; kv < count; kv++ ) {
        cSetterBase s = va_arg( vl, cSetterBase );
        cSetterBase * ps = &s;
        switch( ps->myType ) {
        case 1:
            A = ((cSetterA*)ps)->myValue.f; break;
        case 2:
            B = ((cSetterB*)ps)->myValue.f; break;
        }
     }
     va_end(vl);
}


int _tmain(int argc, _TCHAR* argv[])
{
    cUseful U;
    U.Set( 2,  cSetterB( 47.5 ), cSetterA( 23 ) );
    printf("A = %f B = %f\n",U.A, U.B );
    return 0;
}

Answer 4

You may consider the ConstrOpt paradigm. I first heard about this when reading the XML-RPC C/C++ lib documentation here: http://xmlrpc-c.sourceforge.net/doc/libxmlrpc++.html#constropt

Basically the idea is similar to yours, but the "ConstrOpt" paradigm uses a subclass of the one you want to instantiate. This subclass is then instantiated on the stack with default options and then the relevant parameters are set with the "reference-chain" in the same way as you do.

The constructor of the real class then uses the constrOpt class as the only constructor parameter.

This is not the most efficient solution, but can help to get a clear and safe API design.