Setting member variables before constructor call

Discussion in 'C++' started by syntheticpp@yahoo.com, Jan 16, 2006.

  1. Guest

    Is the program at the end a correct C++ program?

    I ask because the output is:

    B::eek:perator A&()
    A::A()
    B::B()
    B::~B()
    A::~A()

    that means the casting operator which sets the
    member variable B::p is called before the constructor
    of B.


    Here the program:


    #include <iostream>

    using std::cout;

    struct A
    {
    A(){ cout <<"A::A()\n"; }
    ~A(){ cout <<"A::~A()\n"; }
    };

    struct B
    {
    B() // : p(0) // this kills the desruction of p
    { cout <<"B::B()\n"; }

    ~B()
    {
    cout <<"B::~B()\n";
    delete p;
    }

    A* p;

    operator A&()
    {
    cout <<"B::eek:perator A&()\n";
    p = new A;
    return *p;
    }
    };

    struct C
    {
    A& a;
    B b;

    C() : a(b) {}
    };

    int main()
    {
    C* c = new C;
    delete c;

    #if defined(__BORLANDC__) || defined(_MSC_VER)
    system("PAUSE");
    #endif

    }
     
    , Jan 16, 2006
    #1
    1. Advertising

  2. wrote:
    > Is the program at the end a correct C++ program?


    A member function is called for an object whose lifetime hasn't started
    yet because it's not been constructed. The storage the object occupies
    is already create at that time. A pointer to that storage can be used,
    but that use is limited. Dereferencing that pointer to access any member
    of the object causes the program to have undefined behaviour. In your
    case you attempt to assign the 'p' member inside B::eek:perator A&(). Due
    to that, your program has undefined behaviour.

    It is a correct C++ program whose behaviour is undefined.

    > I ask because the output is:
    >
    > B::eek:perator A&()
    > A::A()
    > B::B()
    > B::~B()
    > A::~A()
    >
    > that means the casting operator which sets the
    > member variable B::p is called before the constructor
    > of B.
    >
    >
    > Here the program:
    >
    >
    > #include <iostream>
    >
    > using std::cout;
    >
    > struct A
    > {
    > A(){ cout <<"A::A()\n"; }
    > ~A(){ cout <<"A::~A()\n"; }
    > };
    >
    > struct B
    > {
    > B() // : p(0) // this kills the desruction of p
    > { cout <<"B::B()\n"; }
    >
    > ~B()
    > {
    > cout <<"B::~B()\n";
    > delete p;
    > }
    >
    > A* p;
    >
    > operator A&()
    > {
    > cout <<"B::eek:perator A&()\n";
    > p = new A;

    ^^^^
    This is the cause of the undefined behaviour.

    > return *p;
    > }
    > };
    >
    > struct C
    > {
    > A& a;
    > B b;
    >
    > C() : a(b) {}


    It is generally a BAD IDEA(tm) to use uninitialised or only partially
    constructed objects in the constructor initialisation list.

    > };
    >
    > int main()
    > {
    > C* c = new C;
    > delete c;
    >
    > #if defined(__BORLANDC__) || defined(_MSC_VER)
    > system("PAUSE");
    > #endif
    >
    > }
    >


    V
     
    Victor Bazarov, Jan 16, 2006
    #2
    1. Advertising

  3. Guest

    I've assumed such a answer.
    One way to circumvent the undefined behaviour is to use inheritance,
    but is there a way to initialize the refernce without using
    inheritance?
    Peter
     
    , Jan 16, 2006
    #3
  4. Guest

    Victor Bazarov schrieb:
    > A member function is called for an object whose lifetime hasn't started
    > yet because it's not been constructed. The storage the object occupies
    > is already create at that time.


    But why is it then dangerous to use this storage?
     
    , Jan 16, 2006
    #4
  5. wrote:
    > Victor Bazarov schrieb:
    >
    >>A member function is called for an object whose lifetime hasn't started
    >>yet because it's not been constructed. The storage the object occupies
    >>is already create at that time.

    >
    >
    > But why is it then dangerous to use this storage?


    "Use" is a very vague term. What do you mean by "use"? It's allowed to
    pass the pointer to that storage elsewhere, and even store that pointer
    in another object, for example, since the storage is not going away. I
    don't want to quote the entire subclause of the standard, if you want to
    see what is disallowed, please look at "3.8 Object Lifetime".

    If you'd like a speculation on the subject of possible problems you can
    run into, then imagine that you're trying to access a member of a class
    that adjusts its own layout when initialising. There is no layout at all
    when an object is still under construction, even if the compiler will let
    you access a member, it's possible that the address (or the offset) it
    will use is incorrect since the initialisation proper hasn't yet been
    completed. So, you'll write something in the wrong place where it either
    gets overridden or worse where your action overrides some other value,
    which the program needs. That's just one example.

    V
     
    Victor Bazarov, Jan 16, 2006
    #5
  6. wrote:
    > I've assumed such a answer.
    > One way to circumvent the undefined behaviour is to use inheritance,
    > but is there a way to initialize the refernce without using
    > inheritance?


    I think you need to rearrange the members. Your 'b' will have been
    already initialised at the time when you initialise 'a'.

    V
     
    Victor Bazarov, Jan 16, 2006
    #6
  7. Guest

    It depends on the declaration order:

    B b;
    A& a;

    solves the problem.
     
    , Jan 16, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matt Graham
    Replies:
    3
    Views:
    526
    Matt Graham
    Feb 7, 2004
  2. lallous

    Constructor call constructor

    lallous, Mar 5, 2004, in forum: C++
    Replies:
    3
    Views:
    36,979
    Chris \( Val \)
    Mar 5, 2004
  3. Replies:
    10
    Views:
    631
    msalters
    May 9, 2005
  4. Generic Usenet Account
    Replies:
    10
    Views:
    2,319
  5. Replies:
    9
    Views:
    997
Loading...

Share This Page