Using new (this) to reuse constructors

Question

This came up recently in a class for which I am a teaching assistant. We were teaching the students how to do copy constructors in c++, and the students who were originally taught java asked if you can call one constructor from another. I know the answer to this is no, as they are using the pedantic flag for their code in class, and the old standards do not have support for this. I found on Stackoverflow and other sites a suggestion to fake this using new (this) such as follows

class MyClass
{
    private:
        int * storedValue;
    public:
        MyClass(int initialValue = 0)
        {
            storedValue = new int(initialValue);
        }

        ~ MyClass()
        {
            delete storedValue;
        }

        MyClass(const MyClass &b)
        {
            new (this) MyClass(*(b.storedValue));
        }

        int value() {
            return *storedValue;
        }
};

This is really simple code, and obviously does not save any code by reusing the constructor, but it is just for example.

My question is if this is even standard compliant, and if there are any edge cases that should be considered that would prevent this from being sound code?

Edit: I should note that this seems very dangerous to me, but that is more from a view point of I don't really understand it more than knowing how it can go bad. I just wanted to make sure that if asked about it by students that I can direct them towards why the can or shouldn't do it. I already suggested to them for all practical purposes to use a shared initialization method. This is more of a teaching question than for a practical project.

Answer 1

Unless you're trying to call a parent's constructor, I'd suggest making a private initialization method. There's no reason you couldn't call a shared initializer across your constructors.

Answer 2

This does not work if you have a constructor like that:

class MyClass {
public:
    MyClass( const std::string & PathToFile )
    : m_File( PathToFile.c_str( ) )
    {
    }
private:
    std::ifstream m_File;
}

The original argument cannot be recovered, so you cannot call that constructor from a copy-constructor.

Answer 3

The members and base classes will be initialised before entering the constructor body, then initialised again when you call the second constructor. In general this will lead to memory leaks and possibly undefined behaviour.

So the answer is "no, this is not sound code".

Answer 4

C++0x will introduce syntax to allow constructors to call other constructors.

Until then, new(this) works in some cases, but not all. In particular, once in the constructor, your base class(es) are already fully constructed. Reconstructing via new(this) re-calls the base constructors without calling the base destructors, so expect problems if the base classes weren't expecting this kind of hackery - and they probably weren't.

An example for clarity:

class Base
{
public:
   char *ptr;
   MyFile file;
   std::vector vect;
   Base()
   {
       ptr = new char[1000];
       file.open("some_file");
   }
   ~Base()
   {
       delete [] ptr;
       file.close();
   }
};

class Derived : Base
{
    Derived(Foo foo)
    {
    }
    Derived(Bar bar)
    {
       printf(ptr...);  // ptr in base is already valid
       new (this) Derived(bar.foo); // ptr re-allocated, original not deleted
       //Base.file opened twice, not closed
       // vect is who-knows-what
       // etc
    }
}

or as they say 'hilarity ensues'

Answer 5

Here is what C++ FAQ Lite has to say about it, question 10.3, “Can one constructor of a class call another constructor of the same class to initialize the this object?”:

BTW do NOT try to achieve this via placement new. Some people think they can say new(this) Foo(x, int(x)+7) within the body of Foo::Foo(char). However that is bad, bad, bad. Please don't write me and tell me that it seems to work on your particular version of your particular compiler; it's bad. Constructors do a bunch of little magical things behind the scenes, but that bad technique steps on those partially constructed bits. Just say no.

Answer 6

As that exact code is written, it should work -- though I can't imagine exactly why you'd write code like that. In particular, it depends on the fact that all the pointer is only ever used to refer to a single int. That being the case, why didn't they just put an int in the object, instead of using a pointer and allocating the int dynamically? In short, what they have is long and inefficient, but not significantly different from:

class MyClass {
    int v;
public:
    MyClass(int init) : v(init) {}
    int value() { return v; }
};

Unfortunately, the minute you try to get some real use from the pointer (e.g., allocating different amounts of memory in different objects) the "trick" they using with placement new quits working -- it depends completely on the fact that every object is allocating exactly the same amount of memory. Since you're limited to exactly the same allocation in each, why put that allocation in the heap instead of making it part of the object itself?

Truthfully, there are circumstances when it would make sense. The only one I can think of right off, however, is that the allocation is large and you're running in an environment where there's a lot more heap space than stack space.

The code works, but it's only useful under fairly narrow, specific circumstances. It doesn't strike me as something I'd recommend as an example of how to do things.