Hello,

could some body please explain construction/destruction conventions in D, because I'm confused with the fact:
"allowing one constructor to call another at any point".

That's confuses a little bit, because I can't imagine subclass without constructed baseclass.

Ruslanas

"Ruslanas Abdrachimovas" <anubis@03bar.ktu.lt> wrote in message news:3C57E45C.7010804@03bar.ktu.lt...
> Hello,
>
> could some body please explain construction/destruction conventions in
> D, because I'm confused with the fact:
> "allowing one constructor to call another at any point".
>
> That's confuses a little bit, because I can't imagine subclass without constructed baseclass.
>
> Ruslanas
>

I think what Walter means by it is that two constructors of the *same* class can call each other. You might have a constructor that takes parameters and a default constructor. The default constructor might then call the other constructor with the default values as parameters:

class Test
{
   this ()
   {
        this (10);
   }

   this (int iParam)
   {
      m_iValue = iParam;
   }

   int m_iValue;
}


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a39jnj$21em$1@digitaldaemon.com...
> "Ruslanas Abdrachimovas" <anubis@03bar.ktu.lt> wrote in message news:3C57E45C.7010804@03bar.ktu.lt...
> > Hello,
> >
> > could some body please explain construction/destruction conventions in
> > D, because I'm confused with the fact:
> > "allowing one constructor to call another at any point".
> >
> > That's confuses a little bit, because I can't imagine subclass without constructed baseclass.
> >
> > Ruslanas
> >
>
> I think what Walter means by it is that two constructors of the *same* class can call each other.

   Actually, it's a bit more profound than that.

   What's the meaning of a constructor?

C++ -> It is the "thingy" that gets called to make an object usable. It begins the "life" of the object. Before the constructor, there's no object. Not even an uninitialized one. For all the language cares, a compiler might make it so that the memory itself (the bits and bytes) is not accessible before constructing the object or after destructing it. That makes the whole constructor-destructor thng very strict. Until the base class' constructor runs, there is nothing there, and nothing is accessible. This means that the base class constructor HAS to be called before the derived class constructor begins.

D -> It's a function that is used to initialize the object. Just a function that hopefully puts meaningful values there. Now, when a derived class' constructor gets called, the base class constructor hasn't been called yet. It has to be called manually, if so desired. But the memory is definitely there and accessible.

Salutaciones,
                         JCAB

"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a39jnj$21em$1@digitaldaemon.com...

> I think what Walter means by it is that two constructors of the *same* class can call each other. You might have a constructor

Actually, your constructor may call the constructor of the base class - but doesn't have to! This might seem strange from the point of view of C++ programmer, but the resulting object will be pretty valid, vtable is there; most likely, however, you will have to call super() just to make sure you don't break some code in the base class...

Once again, what about _requiring_ call to super() to be present in all execution branches of a constructor?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3c1nl$2hfk$1@digitaldaemon.com...
> "OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a39jnj$21em$1@digitaldaemon.com...
> > I think what Walter means by it is that two constructors of the *same* class can call each other.

Yes.

> Actually, your constructor may call the constructor of the base class - but doesn't have to! This might seem strange from the point of view of C++ programmer, but the resulting object will be pretty valid, vtable is there; most likely, however, you will have to call super() just to make sure you don't break some code in the base class...
>
> Once again, what about _requiring_ call to super() to be present in all execution branches of a constructor?

I'm not sure what the right answer is here. I don't like the C++ way with the base initializer syntax, it's too restrictive.

"Walter" <walter@digitalmars.com> wrote in message news:a3er6r$sr$3@digitaldaemon.com...

> I'm not sure what the right answer is here. I don't like the C++ way with the base initializer syntax, it's too restrictive.

I don't mean the C++ syntax. I suggest to leave it as it is now, but raise an error if base constructor occasionally doesn't get called.

An example:

    // legal code
    this(int x)
    {
        if (x > 0)
            super(x);
        else if (x < 0)
            super(abs(x));
        else
            super();
    }

    // illegal code
    this(int x)
    {
        if (x > 0)
            super(x);
        else if (x < 0)
            super(abs(x));
    }

The latter should raise a "not all control paths call base constructor"
error (or maybe warning?), because sometimes (x == 0) base constructor
is not called at all - which is almost always a bug.

True. I think you're on to a good addition here. -Walter

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3es6c$i5$1@digitaldaemon.com...
> An example:
>
>     // legal code
>     this(int x)
>     {
>         if (x > 0)
>             super(x);
>         else if (x < 0)
>             super(abs(x));
>         else
>             super();
>     }
>
>     // illegal code
>     this(int x)
>     {
>         if (x > 0)
>             super(x);
>         else if (x < 0)
>             super(abs(x));
>     }
>
> The latter should raise a "not all control paths call base constructor"
> error (or maybe warning?), because sometimes (x == 0) base constructor
> is not called at all - which is almost always a bug.
>
>

I like such idea. Because if you want to be implementation independent, you MUST call super() - it moves base class objects to correct state (if ther aren't some bugs in base class).

I think that REQUIRING super() call is a MUST. :)

Pavel Minayev wrote:
> An example:
> 
>     // legal code
>     this(int x)
>     {
>         if (x > 0)
>             super(x);
>         else if (x < 0)
>             super(abs(x));
>         else
>             super();
>     }
> 
>     // illegal code
>     this(int x)
>     {
>         if (x > 0)
>             super(x);
>         else if (x < 0)
>             super(abs(x));
>     }
> 
> The latter should raise a "not all control paths call base constructor"
> error (or maybe warning?), because sometimes (x == 0) base constructor
> is not called at all - which is almost always a bug.
> 
> 
> 

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a3es6c$i5$1@digitaldaemon.com...
> An example:
>
>     // legal code
>     this(int x)
>     {
>         if (x > 0)
>             super(x);
>         else if (x < 0)
>             super(abs(x));
>         else
>             super();
>     }
>
>     // illegal code
>     this(int x)
>     {
>         if (x > 0)
>             super(x);
>         else if (x < 0)
>             super(abs(x));
>     }
>
> The latter should raise a "not all control paths call base constructor"
> error (or maybe warning?), because sometimes (x == 0) base constructor
> is not called at all - which is almost always a bug.
>
>

I think Java is already doing this isn't it? Would be a very good idea anyhow. I don't know about the warning though? Is there a situation where this is not an error?


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail