C / C++ / MFC

20-Jun-01 9:12

Hi, I have a design I am considering implementing and I was wondering if I could get some feedback on it.
Basically I am considering implementing a refcounting scheme (nothing too difficult there) as well as an instantiation techniques that works as follows:
All classes that need to be allocated on the heap will have a virtual method called init(). init() provides a common place to initialize variables, etc.

All classes provide a static method called create() that returns a new instance of the class. the create() method should mirror the constructor for the class as it will call this constructor when creating a new instance for the class. Example:
class Foo {
Foo();
Foo( int count );

static Foo* create() {
Foo* result = new Foo();
result->init();
return result;
}

static Foo* create( int count ) {
Foo* result = new Foo( count );
result->init();
return result;
}
};

This allows for virtual init function to be called, allowing single step creation, which is convenient for many kinds of classes, at least in what I am working on, so the syntax is now the following for creating things on the heap:
Foo* f = Foo::create();
instead of
Foo* f = new Foo();

The base class would provide addRef(), release(), and getRefCount() for performing refcounting.

The base class would also have two more functions. A protected virtual function called destroy() that would contain common termination code. Another public method called free() that would call destroy() and then delete this to destroy the object. the release() method would call free() (instead of delete this) when the refcount dropped to 0. So to completely destroy an object on the heap where you "own" that object (i.e. an object that doesn't get used by anyone else but the class instantiating it) you would do the following:
Foo* f.... //stuff happens
//later on...
f->free();

To simply release the object the sfollowing syntax is used:

f->release();

The advantage (or at least what I am thinking is the advantage), is the ability to have a common virtual function for both initialization ( init() ) and clean up ( destroy() ) that will safely get called, since constructors and destructors cannot call virtual functions in their implementation (well they can, they just don't behave like you'd expect them ).

In addition, a ref counting scheme is in place to allow potential COM features in the library.

Hope all this is reasonably clear, and I look forward to any feedback ( even if you think I am flat out crazy Smile | :)

)

Tomasz Sowinski20-Jun-01 9:25

20-Jun-01 9:25

Do you expect init() to be called from places other than create() ?

Tomasz Sowinski -- http://www.shooltz.com.pl

Jim Crafton20-Jun-01 12:07

20-Jun-01 12:07

no - good point, I suppose it should be protected

Tomasz Sowinski20-Jun-01 23:59

20-Jun-01 23:59

I'm also not sure why do you need free() function. Isn't virtual destructor enough? I'm fully aware that virtual functions are called non-virtually from d'tor, but can't see any serious issue here. Do you expect problems related to the order of destructor calls?

Tomasz Sowinski -- http://www.shooltz.com.pl

Jim Crafton21-Jun-01 4:38

21-Jun-01 4:38

Normally I'd agree with you but I have some stuff that needs to have virtual clean up methods that need to be called prior to the destructor to work right. That is the idea behind the free() call, a single place where the virtual clean up methods can get called prior to the destructor, sort of like the FinalConstruct()/FinalDestruct() of ATL.

Tomasz Sowinski21-Jun-01 1:12

21-Jun-01 1:12

> no - good point, I suppose it should be protected

So it doesn't have to be virtual... Note that you're always dealing with object of type Foo in Foo::create:

static Foo* create( int count )
{
Foo* result = new Foo( count );
result->init(); //calls Foo::init even if init isn't virtual
return result;
}

In fact, if you don't have two or more versions of Foo::create, you could place all init functionality inside create.

Personally, I'd move the parameters from the constructor to non-virtual init:
static Foo* create( int count )
{
Foo* result = new Foo();
result->init(count);
return result;
}

The only thing that constructor does in this scenario is initializing vtable pointer (this of course is done automatically for you). 'Real' init would be performed in init() itself.

Tomasz Sowinski -- http://www.shooltz.com.pl

Jim Crafton21-Jun-01 4:35

21-Jun-01 4:35

Well the init function is virtual so that base class initialization will take place in one common place. No arguments are needed for it - the constructor will initialize member variables (set pointers to NULL, etc )and then init does the rest. All classes will be a part of a single rooted hierarchy.

Tomasz Sowinski21-Jun-01 4:42