method running on an object BEFORE the object has been initialised?!

Question

#include <iostream>
using namespace std;

class Foo
{

public:

 Foo(): initialised(0)
 {
  cout << "Foo() gets called AFTER test() ?!" << endl;
 };

 Foo test()
 {
  cout << "initialised= " << initialised << " ?! - ";
  cout << "but I expect it to be 0 from the 'initialised(0)' initialiser on Foo()" << endl;
  cout << "this method test() is clearly working on an uninitialised object ?!" << endl;
  return Foo();
 }

 ~Foo()
 {};

private:

 int initialised;

};


int main()
{

 //SURE this is bad coding but it compiles and runs
 //I want my class to DETECT and THROW an error to prevent this type of coding
 //in other words how to catch it at run time and throw "not initialised" or something

 Foo foo=foo.test();

}

Answer 1

Yes, it is calling the function on a yet not constructed object, which is undefined behavior. You can't detect it reliable. I would argue you also should not try to detect it. It's nothing which would happen likely by accident, compared to for example calling a function on an already deleted object. Trying to catch every and all possible mistakes is just about impossible. The name declared is visible already in its initializer, for other useful purposes. Consider this:

Type *t = (Type*)malloc(sizeof(*t));

Which is a common idiom in C programming, and which still works in C++.

Personally, i like this story by Herb Sutter about null references (which are likewise invalid). The gist is, don't try to protect from cases that the language clearly forbids and in particular are in their general case impossible to diagnose reliably. You will get a false security over time, which becomes quite dangerous. Instead, train your understanding of the language and design interfaces in a way (avoid raw pointers, ...) that reduces the chance of doing mistakes.

In C++ and likewise in C, many cases are not explicitly forbidden, but rather are left undefined. Partially because some things are rather difficult to diagnose efficiently and partially because undefined behavior lets the implementation design alternative behavior for it instead of completely ignoring it - which is used often by existing compilers.

In the above case for example, any implementation is free to throw an exception. There are other situations that are likewise undefined behavior which are much harder to diagnose efficiently for the implementation: Having an object in a different translation unit accessed before it was constructed is such an example - which is known as the static initialization order fiasco.

Answer 2

The constructor is the method you want (not running before initialization but rather on initialization, but that should be OK). The reason it doesn't work in your case is that you have undefined behavior here.

Particularly, you use the not-yet-existent foo object to initialize itself (eg. the foo in foo.Test() doesn't exist yet). You can solve it by creating an object explicitly:

Foo foo=Foo().test()

You cannot check for it in the program, but maybe valgrind could find this type of bug (as any other uninitialized memory access).

Answer 3

You can't prevent people from coding poorly, really. It works just like it "should":

1. Allocate memory for Foo (which is the value of the "this" pointer)
2. Going to Foo::test by doing: Foo::test(this), in which,
3. It gets the value by this->initialised, which is random junk, then it
4. Calls Foo's default constructor (because of return Foo();), then
5. Call Foo's copy constructor, to copy the right-handed Foo().

Just like it should. You can't prevent people from not knowing the right way to use C++.

The best you could do is have a magic number:

class A
{
public:
    A(void) :
    _magicFlag(1337)
    {
    }

    void some_method(void)
    {
        assert (_magicFlag == 1337); /* make sure the constructor has been called */
    }

private:
    unsigned _magicFlag;
}

This "works" because the chances _magicFlag gets allocated where the value is already 1337 is low.

But really, don't do this.

Answer 4

You're getting quite a few responses that basically say, "you shouldn't expect the compiler to help you with this". However, I'd agree with you that the compiler should help with this problem by with some sort of diagnostic. Unfortunately (as the other answers point out), the language spec doesn't help here - once you get to the initializer part of the declaration, the newly declared identifier is in scope.

A while back, DDJ had an article about a simple debugging class called "DogTag" that could be used as a debugging aid to help with:

• using an object after deletion
• overwriting an object's memory with garbage
• using an object before initializing it

I haven't used it much - but it did come in handly on an embedded project that was running into some memory overwrite bugs.

It's basically an elaboration of the "MagicFlag" technique that GMan described.