I'm up, baby. Can't keep me down. <G>

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:bns7l9$2ike$1@digitaldaemon.com...
> 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.
> > >
> > >
> >
> >
>
>

Have just started working through all this terminological undergrowth for
the book, and have
come across the following:

9;4 "A POD-struct is an aggregate class that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union, or arrays of such types, or reference, and has no user-defined copy assignment operator and no user-defined destructor."

Note that it says nothing about not having a user-defined ctor. ;)

Aggregates:

8.5.1 "an array or a class with no user-defined constructors, no private or protected non-static data members, no base classes, and no virtual functions."

Note that it says nothing about not having a user-defined dtor.

I presume this is an oversight in both cases. The union (arf arf) of the two definitions is that a POD-struct can have neither ctor nor dtor.


"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.
>
>

Have just started working through all this terminological undergrowth for
the book, and have
come across the following:

9;4 "A POD-struct is an aggregate class that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union, or arrays of such types, or reference, and has no user-defined copy assignment operator and no user-defined destructor."

Note that it says nothing about not having a user-defined ctor. ;)

Aggregates:

8.5.1 "an array or a class with no user-defined constructors, no private or protected non-static data members, no base classes, and no virtual functions."

Note that it says nothing about not having a user-defined dtor.

I presume this is an oversight in both cases. The union (arf arf) of the two definitions is that a POD-struct can have neither ctor nor dtor.


"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.
>
>

Hmm, thanks! (My confidence level regarding the
Holy Word is at an all time low recently... Too
bad the Creator is not a regular visitor of the
D newsgroup, so we could ask...)

Cheers,
Sz.

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnt7sg$19m1$1@digitaldaemon.com...
> Have just started working through all this terminological undergrowth for
> the book, and have
> come across the following:
>
> 9;4 "A POD-struct is an aggregate class that has no non-static data members of type pointer to member, non-POD-struct, non-POD-union, or arrays of such types, or reference, and has no user-defined copy assignment operator and no user-defined destructor."
>
> Note that it says nothing about not having a user-defined ctor. ;)
>
> Aggregates:
>
> 8.5.1 "an array or a class with no user-defined constructors, no private or protected non-static data members, no base classes, and no virtual functions."
>
> Note that it says nothing about not having a user-defined dtor.
>
> I presume this is an oversight in both cases. The union (arf arf) of the two definitions is that a POD-struct can have neither ctor nor dtor.
>
>
> "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.
> >
> >
>
>
>
>

"Matthew Wilson" <matthew-hat@-stlsoft-dot.-org> wrote in message news:bnrphn$1vah$1@digitaldaemon.com...
> 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.

The other reason is to avoid the need for overloadable assignment operators.

On Fri, 31 Oct 2003 06:48:50 +1100, Matthew Wilson <matthew-hat@-stlsoft-dot.-org> wrote:
> 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.

As an extra data point, my C++ code frequently has structs with constructors, but no destructors or overloaded assignment operators. This is especially useful when throwing exceptions (although granted, those would be classes in D), but not exclusively so.

Thus, struct constructors in the absence of such things are still useful, IMHO.

-Scott

Scott Wood wrote:
>
> Thus, struct constructors in the absence of such things are still
> useful, IMHO.

Are struct values still default constructed though?

Sean

can someone give me a reason why structs shouldnt have constructors? If there is one then how about struct literals:

struct MyStruct
{
int x;
float f;
}

MyStruct getStruct()
{
return {10, 10.0f};
}

In article <c06skm$8ns$1@digitaldaemon.com>, Sean Kelly says...
>
>Scott Wood wrote:
>>
>> Thus, struct constructors in the absence of such things are still useful, IMHO.
>
>Are struct values still default constructed though?
>
>Sean
>

imr1984 wrote:
> can someone give me a reason why structs shouldnt have constructors? If there is
> one then how about struct literals:

I'd also like one of these options. In C++ I often use struct ctors so I can easily add instances to containers with value semantics knowing that the compiler will optimise out the creation of temporaries. eg:

struct Thing {
    int a;
    int b;
    Thing (int a_, int b_) : a(a_), b(b_) {;}
};
...
std::vector<Thing> v;
v.push_back (Thing(1,2));

Note that I'd also need operator< if I want to use the struct to instantiate an associative container, such as std::set<>.

What would be the D way? I can't see any way to avoid the (mild) inefficiency of executing the default struct member initialisers & the copying of a temporary struct.

Chris.

"Chris Paulson-Ellis" <chris@edesix.com> wrote in message
news:c07o3k$1n67$1@digitaldaemon.com...
| imr1984 wrote:
| > can someone give me a reason why structs shouldnt have constructors? If
there is
| > one then how about struct literals:
|
| I'd also like one of these options. In C++ I often use struct ctors so I
| can easily add instances to containers with value semantics knowing that
| the compiler will optimise out the creation of temporaries. eg:
|
| struct Thing {
|      int a;
|      int b;
|      Thing (int a_, int b_) : a(a_), b(b_) {;}
| };
| ...
| std::vector<Thing> v;
| v.push_back (Thing(1,2));
|
| Note that I'd also need operator< if I want to use the struct to
| instantiate an associative container, such as std::set<>.
|
| What would be the D way? I can't see any way to avoid the (mild)
| inefficiency of executing the default struct member initialisers & the
| copying of a temporary struct.
|
| Chris.

I wonder if just supplying the body of a struct member function

struct Thing {
   int a;
   int b;
   void init(int a_, int b_) {a=a_;b=b_;}
   static Thing make(int a_,int b_) {Thing x; x.init(a_,b_);return x;}
}

making it available for inlining would cut out some of the overhead. I'm not really sure. I guess it would be hard for an optimizer to determine if it is ok to avoid initializing the struct with the default values since it would have to keep track of which fields were assigned before they were ever referenced - doesn't seem _too_ hard but what do I know. Plus could it figure out that the x inside Thing.make is initialized and then just copied on return.

-Ben