"OddesE" <OddesE_XYZ@hotmail.com> wrote in message news:a3uuhv$2aqo$1@digitaldaemon.com...
> "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?

As it turns out, the way D builds objects is all class members, including base classes, get initialized with the static defaults.

"Walter" <walter@digitalmars.com> wrote in message news:a3vsm6$1e1s$2@digitaldaemon.com...

> As it turns out, the way D builds objects is all class members, including base classes, get initialized with the static defaults.

So what? Base constructor might perform some initialization that is cruical for its methods to work properly. And, following the incapsulation paradigm, it's not responsible for telling you that it does, right?

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a40jgb$1p1j$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a3vsm6$1e1s$2@digitaldaemon.com...
>
> > As it turns out, the way D builds objects is all class members,
including
> > base classes, get initialized with the static defaults.
>
> So what? Base constructor might perform some initialization that is cruical for its methods to work properly. And, following the incapsulation paradigm, it's not responsible for telling you that it does, right?

You're right. I was just pointing out that it is not initialized to random data.

"Walter" <walter@digitalmars.com> wrote in message news:a41imf$2pnk$5@digitaldaemon.com...

> You're right. I was just pointing out that it is not initialized to random data.

...just as stated in the spec. Yes, I'm aware of that. Good idea BTW.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a41jke$2q5a$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a41imf$2pnk$5@digitaldaemon.com...
>
> > You're right. I was just pointing out that it is not initialized to
random
> > data.
>
> ...just as stated in the spec. Yes, I'm aware of that. Good idea BTW.

It actually winds up more efficient than the way C++ does it. How a class object is initialized is a static default version of it is defined, and then is memcpy'd over the allocated object. This sets up all the static defaults, and even initializes all the vptr's automatically!

"Walter" <walter@digitalmars.com> wrote in message news:a41oeq$2se5$7@digitaldaemon.com...

> It actually winds up more efficient than the way C++ does it. How a class object is initialized is a static default version of it is defined, and
then
> is memcpy'd over the allocated object. This sets up all the static
defaults,
> and even initializes all the vptr's automatically!

I've seen that code. Yep, it's quite fast. Also, if you add the pointer to constructor to the classinfo (pleeeease!), it could be used to construct objects by their classinfos - could be used for serialization.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a42kgo$6oa$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a41oeq$2se5$7@digitaldaemon.com...
>
> > It actually winds up more efficient than the way C++ does it. How a
class
> > object is initialized is a static default version of it is defined, and
> then
> > is memcpy'd over the allocated object. This sets up all the static
> defaults,
> > and even initializes all the vptr's automatically!
>
> I've seen that code. Yep, it's quite fast. Also, if you add the pointer to constructor to the classinfo (pleeeease!), it could be used to construct objects by their classinfos - could be used for serialization.

I plan on adding serialization support. ClassInfo will likely acquire more stuff over time. Info on each field will be necessary to make a copying gc, for example. Serialization is another, as you mentioned.

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

> I plan on adding serialization support. ClassInfo will likely acquire more stuff over time. Info on each field will be necessary to make a copying
gc,
> for example. Serialization is another, as you mentioned.

Serialization is easy to make as long as we have a globally accessible list of classinfos, and each classinfo knows its constructor. Then, an instance of the class can be easily created from the class name:

    // object.d
    class ClassInfo
    {
        ...
        Object newInstance() { ... }      // creates new object of that type
        static ClassInfo[char[]] classes; // list of all classinfos in
program
    }

    // stream.d
    interface IPersistent
    {
        void saveToStream(Stream);
        void loadFromStream(Stream);
    }

    class Stream
    {
        ...

        Object readObject()
        {
            int len;
            char[] classname;
            Object obj;
            IPersistent pers;
            // read classname
            file.read(len);
            classname = file.readString(len);
            // create a class instance
            obj = ClassInfo.classes[classname].newInstance();
            // check if it is IPersistent
            pers = cast(IPersistent) obj;
            assert(pers);
            // call user-defined loading routine
            pers.loadFromStream(this);
            // and return what we have
            return obj;
        }
    }

The list of classes is already globally available, look at how modules get initialized!

"Pavel Minayev" <evilone@omen.ru> wrote in message news:a434lo$lmu$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> wrote in message news:a42tca$hrc$3@digitaldaemon.com...
>
> > I plan on adding serialization support. ClassInfo will likely acquire
more
> > stuff over time. Info on each field will be necessary to make a copying
> gc,
> > for example. Serialization is another, as you mentioned.
>
> Serialization is easy to make as long as we have a globally accessible list of classinfos, and each classinfo knows its constructor. Then, an instance of the class can be easily created from the class name:
>
>     // object.d
>     class ClassInfo
>     {
>         ...
>         Object newInstance() { ... }      // creates new object of that
type
>         static ClassInfo[char[]] classes; // list of all classinfos in
> program
>     }
>
>     // stream.d
>     interface IPersistent
>     {
>         void saveToStream(Stream);
>         void loadFromStream(Stream);
>     }
>
>     class Stream
>     {
>         ...
>
>         Object readObject()
>         {
>             int len;
>             char[] classname;
>             Object obj;
>             IPersistent pers;
>             // read classname
>             file.read(len);
>             classname = file.readString(len);
>             // create a class instance
>             obj = ClassInfo.classes[classname].newInstance();
>             // check if it is IPersistent
>             pers = cast(IPersistent) obj;
>             assert(pers);
>             // call user-defined loading routine
>             pers.loadFromStream(this);
>             // and return what we have
>             return obj;
>         }
>     }
>
>
>
>
>

"Walter" <walter@digitalmars.com> wrote in message news:a43tq4$11uk$3@digitaldaemon.com...

> The list of classes is already globally available, look at how modules get initialized!

Ahh... now I see. But the _moduleinfo_array[] is not "official" part of the language, right? So it's not portable...

Also I've just thought that it'd be great for the class to know the module where it's declared. Well you know, just a ModuleInfo member in the ClassInfo. Might be useful to handle cases where classnames match...