Oh I see. For example, you could delete the object at that address. That wouldn't be very nice to everyone else holding a pointer to the ModelReader. Would using a std::shared_ptr resolve all of the troubles?Originally Posted by grumpy
Oh I see. For example, you could delete the object at that address. That wouldn't be very nice to everyone else holding a pointer to the ModelReader. Would using a std::shared_ptr resolve all of the troubles?
That's superstition.
It is unsafe for some other object to access the object while it is being constructed, as that other object cannot know the details of initialization.
So, if you pass "this" to some object/function in a constructor's initialization list, that object/function should not access the object pointed to by that pointer, because it isn't constructed yet. This has nothing to do whether an object can access its own internals during construction -- if it could not, how could one implement a constructor?
But this isn't due to some unknown and unknowable behavior on the part of the compiler. In fact, the compiler makes a number of guarantees about how things happen during construction. The members in the constructor initialization list will be initialized in the order they are declared in the class declaration. The statements inside the body of the constructor will be executed according to the same rules about expressions and sequence points that all other code abides by. The moment at which the vtable is initialized is a bit less clear, however, so objects should not invoke virtual functions on themselves during construction.
Accessing an uninitialized or partly-initialized object is always a bad thing. It is not limited to the this pointer in a constructor.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
