So if you want to keep structs POD, mandate that there is always an implicit bitwise copy constructor that you cannot override, and always a memberwise assignment from a struct literal that you can't get rid of or hide.  That keeps you from making your own smart pointers though.  Not that we can make them now in D anyway...  There is no need to prohibit constructors for structs to get POD-ness.  We already have the implicit default ctor that zeroes everything out.

It always seemed an unnecessary restriction that you can't put a class with a ctor into a union in C++.  I should be able to if I want to, and initialize any part of it I choose by value copy or by constructor call.

Sean

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:bnr9v2$18gq$1@digitaldaemon.com...
> > I can't see any reason not to have both. Can anyone explain?
>
> I think it's about structs being POD types (not just
> being value types -- but almost). And remember: POD
> types cannot have ctor/dtor in C++ either.
>
> That may sound really annoying sometimes (and I find
> it strange there, too, sometimes), but as soon as you
> try implementing a *fast* generic container, you come
> to appreciate those constructorless POD objects...
>
> Classes have a special feature: an object's valid
> lifetime starts when its ctor has finished OK, and
> lasts until its dtor is entered. AFAIK, C++ tries
> hard to maintain a guarantee that if you can access
> an object, then it really is initialized (constructed).
>
> If a struct had ctor/dtor, that same guarantee would
> need to be introduced for them, too. That would mean
> giving up the advantages of being a primitive POD type
> that can be created, destroyed, moved, copied, passed
> around and "mapped-to", without worrying about the
> "properly initialized == ctor done" semantics.
>
> (Dunno if this really is the reason.)
> Sz.

> > I can't see any reason not to have both. Can anyone explain?
>
> I think it's about structs being POD types (not just
> being value types -- but almost). And remember: POD
> types cannot have ctor/dtor in C++ either.

Not true.

> That may sound really annoying sometimes (and I find
> it strange there, too, sometimes), but as soon as you
> try implementing a *fast* generic container, you come
> to appreciate those constructorless POD objects...

No-one's saying that structs have to have ctors/dtors, just that it should be supported. And since objects are zero-initialised in D, it's arguable that simple ctors would have little/no perf difference than none

> Classes have a special feature: an object's valid
> lifetime starts when its ctor has finished OK, and
> lasts until its dtor is entered. AFAIK, C++ tries
> hard to maintain a guarantee that if you can access
> an object, then it really is initialized (constructed).
>
> If a struct had ctor/dtor, that same guarantee would
> need to be introduced for them, too. That would mean
> giving up the advantages of being a primitive POD type
> that can be created, destroyed, moved, copied, passed
> around and "mapped-to", without worrying about the
> "properly initialized == ctor done" semantics.

Sorry, but that just doesn't make sense to me.

IIRC, the reason for not having ctors was because it inclines people not to request dtors, and the reason for not having dtors is implementation complexity. My position is that this is not a good enough reason, and my question was to understand if there was a compelling example supporting that.

So far, no-one's given one.

> structs to get POD-ness.  We already have the implicit default ctor that zeroes everything out.

Hmm, yes that's true!

> It always seemed an unnecessary restriction that you can't put a class with a ctor into a union in C++.  I should be able to if I want to, and initialize any part of it I choose by value copy or by constructor call.

With the C++ union, that's not so easy, I think.
If you'd try

    union U { Constructible1 o1; Constructible2 o2; };
    U u;

C++ cannot decide which ctor to call. It cannot either
skip both, obviously. This would probably be a really
serious hit on the general ctor-init guarantee, which
C++ otherwise does a good job about.

Cheers,
Sz.

> "Luna Kid" <lunakid@neuropolis.org> wrote in message news:bnr9v2$18gq$1@digitaldaemon.com...
> > > I can't see any reason not to have both. Can anyone explain?
> >
> > I think it's about structs being POD types (not just
> > being value types -- but almost). And remember: POD
> > types cannot have ctor/dtor in C++ either.
> >
> > That may sound really annoying sometimes (and I find
> > it strange there, too, sometimes), but as soon as you
> > try implementing a *fast* generic container, you come
> > to appreciate those constructorless POD objects...
> >
> > Classes have a special feature: an object's valid
> > lifetime starts when its ctor has finished OK, and
> > lasts until its dtor is entered. AFAIK, C++ tries
> > hard to maintain a guarantee that if you can access
> > an object, then it really is initialized (constructed).
> >
> > If a struct had ctor/dtor, that same guarantee would
> > need to be introduced for them, too. That would mean
> > giving up the advantages of being a primitive POD type
> > that can be created, destroyed, moved, copied, passed
> > around and "mapped-to", without worrying about the
> > "properly initialized == ctor done" semantics.
> >
> > (Dunno if this really is the reason.)
> > Sz.
>

> > POD types cannot have ctor/dtor in C++ either.
>
> Not true.

Oops, I based my statement on unofficial sources like the online C++ FAQ, Comeaus's site and a paper from Grosse-Kunstleve & D. Abrahams:

http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.7 http://www.comeaucomputing.com/techtalk/#pod http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1356.html

and some vague memories of reading it somewhere from Stroustrup (either ARM or the C++/3rd), which I cannot find right now.

The ISO standard, OTOH, indeed, does not seem to mention constructors of POD types. Hmm.

> be supported. And since objects are zero-initialised in D, it's arguable that simple ctors would have little/no perf difference than none

(Well, actually I never 100% liked any mandatory default autoinit idea *exactly* instead of defining my own ctors. Any non-ctor initialization may have little to do with the actual semantics of my custom type. It can be meaningful only by the "accident" of "zeroinit is just fine". OTOH, that "accident" is sufficiently common to make it a good practical compromise; but I digress.)

> > Classes have a special feature: an object's valid
> ...
> > "properly initialized == ctor done" semantics.
>
> Sorry, but that just doesn't make sense to me.

In fact I was trying to convince myself, too -- with questionable succes... :)

However, that view still does make some sense to me.

Suppose you have a ctor for a struct S. You can memcopy/
memset/otherwise tamper with S legally, as any PODs. So,
if one gets to say that "Hey, I have these S instances
here in my buffer; how come their constructor has never
been called? Is it really my fault or is it D's fuzziness?"

At best, this can be a question Walter my not be very
keen on receiving all too often...

To safely add ctors for structs, I guess it is *our*
duty to prove that there can never be a practical problem
related to D's type system, resulting from this slight(?)
conceptual crack.

// Note: I'm highly unfamiliar with the exact rules
// on using D classes (instead of structs), so the same
// thing may be relevant to classes, too, dunno. I'm
// simply trying to make up some rationale here...

BTW, another tip: POD types can typically be initialized
compile-time. Types with ctors (POD types) cannot. (True?)

> IIRC, the reason for not having ctors was because it inclines people not to request dtors, and the reason for not having dtors is implementation complexity. My position is that this is not a good enough reason,

Well, I never really believed that to be the reason.

Cheers,
Sz.

> (Well, actually I never 100% liked any mandatory default autoinit idea *exactly* instead of defining my own ctors.

-->

> (Well, actually I never 100% liked any mandatory default autoinit idea instead of defining my own ctors.

> > structs to get POD-ness.  We already have the implicit default ctor that zeroes everything out.
>
> Hmm, yes that's true!

(But as I thought about it a bit more, that's
quite a different thing from a ctor.)

> > It always seemed an unnecessary restriction that you can't put a class with a ctor into a union in C++.  I should be able to if I want to, and initialize any part of it I choose by value copy or by constructor call.
>
> With the C++ union, that's not so easy, I think.

Umm, sorry, I misunderstood your statement, Sean,
that's why I replied with my irrelevant example...

Cheers,
Sz.

> > > POD types cannot have ctor/dtor in C++ either.
> >
> > Not true.
>
> Oops, I based my statement on unofficial sources like the online C++ FAQ, Comeaus's site and a paper from Grosse-Kunstleve & D. Abrahams:
>
> http://www.parashift.com/c++-faq-lite/intrinsic-types.html#faq-26.7 http://www.comeaucomputing.com/techtalk/#pod http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1356.html
>
> and some vague memories of reading it somewhere from Stroustrup (either ARM or the C++/3rd), which I cannot find right now.
>
> The ISO standard, OTOH, indeed, does not seem to mention constructors of POD types. Hmm.
>
> > be supported. And since objects are zero-initialised in D, it's arguable that simple ctors would have little/no perf difference than none

I think I shot my mouth off here. So unlike me.

I always think about aggregates, which are defined in the standard as having no ctors (8.5.1;1), as having no ctors. POD is ill-defined, but as soon as I'd sent the post, I thought that they too would have no ctors.

Thinking clearly for a mo, I think an aggregate is a POD that is of struct, union or class type. POD can also include fundamental types. Since POD is a superset of aggregates, which cannot have ctors/etc., the std doesn't mention POD as (not) having ctors/etc. since fundamentals do not. But since the only subset of POD that could have those things are aggregates, which cannot have ctors/etc. it is fair to infer that PODs cannot have ctors/etc.

We need a clearer standard.

However, I'm happy that I've got that clear in my head. :)

Thanks, LK

> > > POD types cannot have ctor/dtor in C++ either.
> >
> > Not true.


I just foud another "rebel" note at informit.com:

http://www.informit.com/isapi/guide~cplusplus/seq_id~32/guide/content.asp

"A POD object begins its lifetime when it obtains storage with the proper alignment and size for its type, and its lifetime ends when the storage for the object is either reused or deallocated. A non-POD object begins its lifetime after its constructor has executed; its lifetime ends when its destructor has started."

Note: this is in sweet accordance with my original
argument about the lifetime of classes vs. structs
in news:bns19t$29sq$1@digitaldaemon.com. In their
better wording, I hope it makes more sense now.

(InformIT has been a good source of C++ information.
Are they really also off the track? Now, what is the
truth in this POD-ctor thing, who knows? I only saw
the draft C++ standard but I guess the official word
is the same in this regard. But we've seen embarrassing
omissions from in standard already (like std::vector
not being guaranteed to be contiguous etc., which is
going to be fixed in the next revision).)

Later,
Sz.

I refer the honourable gentleman to the answer I gave some moments ago.

Yours, caught and bagged

Wilfred the Unworthy

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:bns46v$2du5$1@digitaldaemon.com...
> > > > POD types cannot have ctor/dtor in C++ either.
> > >
> > > Not true.
>
>
> I just foud another "rebel" note at informit.com:
>
> http://www.informit.com/isapi/guide~cplusplus/seq_id~32/guide/content.asp
>
> "A POD object begins its lifetime when it obtains storage with the proper alignment and size for its type, and its lifetime ends when the storage for the object is either reused or deallocated. A non-POD object begins its lifetime after its constructor has executed; its lifetime ends when its destructor has started."
>
> Note: this is in sweet accordance with my original
> argument about the lifetime of classes vs. structs
> in news:bns19t$29sq$1@digitaldaemon.com. In their
> better wording, I hope it makes more sense now.
>
> (InformIT has been a good source of C++ information.
> Are they really also off the track? Now, what is the
> truth in this POD-ctor thing, who knows? I only saw
> the draft C++ standard but I guess the official word
> is the same in this regard. But we've seen embarrassing
> omissions from in standard already (like std::vector
> not being guaranteed to be contiguous etc., which is
> going to be fixed in the next revision).)
>
> Later,
> Sz.
>
>

Now, please, stand up, my son...

The Luna King

;)

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bns706$2hpe$1@digitaldaemon.com...
> I refer the honourable gentleman to the answer I gave some moments ago.
>
> Yours, caught and bagged
>
> Wilfred the Unworthy
>
> "Luna Kid" <lunakid@neuropolis.org> wrote in message news:bns46v$2du5$1@digitaldaemon.com...
> > > > > POD types cannot have ctor/dtor in C++ either.
> > > >
> > > > Not true.
> >
> >
> > I just foud another "rebel" note at informit.com:
> >
> > http://www.informit.com/isapi/guide~cplusplus/seq_id~32/guide/content.asp
> >
> > "A POD object begins its lifetime when it obtains storage with the proper alignment and size for its type, and its lifetime ends when the storage for the object is either reused or deallocated. A non-POD object begins its lifetime after its constructor has executed; its lifetime ends when its destructor has started."
> >
> > Note: this is in sweet accordance with my original
> > argument about the lifetime of classes vs. structs
> > in news:bns19t$29sq$1@digitaldaemon.com. In their
> > better wording, I hope it makes more sense now.
> >
> > (InformIT has been a good source of C++ information.
> > Are they really also off the track? Now, what is the
> > truth in this POD-ctor thing, who knows? I only saw
> > the draft C++ standard but I guess the official word
> > is the same in this regard. But we've seen embarrassing
> > omissions from in standard already (like std::vector
> > not being guaranteed to be contiguous etc., which is
> > going to be fixed in the next revision).)
> >
> > Later,
> > Sz.
> >
> >
>
>