www.digitalmars.com         C & C++   DMDScript  

D - struct constructors

reply Hauke Duden <H.NS.Duden gmx.net> writes:
I have read multiple times in this newsgroup that D structs cannot have 
constructors or destructors. The reason that was given is that this 
would complicate exception handling.

I can understand how the need to call destructors makes exception 
handling more complicated, but what about constructors?

I would very much like to be able to specify constructors for a struct, 
even if it cannot have a destructor. It could make struct initialization 
a lot easier.

Are constructors only not supported because destructors aren't? Or is 
there actually some constructor-specific reason why we cannot have them?


Hauke
Oct 28 2003
next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
They should both be supported. I can't see any compelling reason why they
should not be.

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnlk1r$2g2p$1 digitaldaemon.com...
 I have read multiple times in this newsgroup that D structs cannot have
 constructors or destructors. The reason that was given is that this
 would complicate exception handling.

 I can understand how the need to call destructors makes exception
 handling more complicated, but what about constructors?

 I would very much like to be able to specify constructors for a struct,
 even if it cannot have a destructor. It could make struct initialization
 a lot easier.

 Are constructors only not supported because destructors aren't? Or is
 there actually some constructor-specific reason why we cannot have them?


 Hauke

Oct 28 2003
parent reply Juan C <Juan_member pathlink.com> writes:
In my opinion... the difference between structs and classes is becoming very
minimal. The only two differences I know are:
Classes can have ctors and dtors and are created on the heap.
Structs cannot have ctors and dtors and are created on the stack.

Am I correct so far?

If structs are allowed to have ctors and dtors that leaves allocation location
as the only difference.

Therefore I have a suggestion:

Don't have two separate concepts, just have one. I suggest some new syntax to
indicate where to allocate the instance when it's newed. A side benefit of this
is that it will be apparent from the new statement where the instance is, I
don't like that in a statement like [ X x = new X ; ] that I have to know
whether X is a class or struct to determine where the instance is allocated.
Plus (if this is possible) it would allow the user of the class to decide where
to allocate the instance.

<aside>
It seems to me that the only reason to have both is for backward-compatibility
with C. And while I see the benefit of that, you must decide whether or not this
is a new language. I for one want a new language and scroo the compatibility.
But that's just me.
</aside>



In article <bnlkik$2gn3$1 digitaldaemon.com>, Matthew Wilson says...
They should both be supported. I can't see any compelling reason why they
should not be.

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnlk1r$2g2p$1 digitaldaemon.com...
 I have read multiple times in this newsgroup that D structs cannot have
 constructors or destructors. The reason that was given is that this
 would complicate exception handling.

 I can understand how the need to call destructors makes exception
 handling more complicated, but what about constructors?

 I would very much like to be able to specify constructors for a struct,
 even if it cannot have a destructor. It could make struct initialization
 a lot easier.

 Are constructors only not supported because destructors aren't? Or is
 there actually some constructor-specific reason why we cannot have them?


 Hauke


Oct 28 2003
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Juan C wrote:
 In my opinion... the difference between structs and classes is becoming very
 minimal. The only two differences I know are:
 Classes can have ctors and dtors and are created on the heap.
 Structs cannot have ctors and dtors and are created on the stack.
 
 Am I correct so far?

Not only. D class is like a Java class - it always has a VTable entry - making it heavyweight out of a sudden, as opposed to a C++ class. All member functions in D classes are virtual, all functions in structs are directly called (non-virtual), since a struct doesn't have a VTable. The class VTable also stores the class information, and gives the standardised way to access a destructor, GC scanner, and other member functions, which are predefined in "Object", the mother-of-all, and are requiered for correct functioning of runtime, as it currently is, including the GC.
 <aside>
 It seems to me that the only reason to have both is for backward-compatibility
 with C. And while I see the benefit of that, you must decide whether or not
this
 is a new language. I for one want a new language and scroo the compatibility.
 But that's just me.
 </aside>

Since D classes are Java-like heavyweights, there was a need to create lightweight custom types, which could stand for custom implementations of, e.g. data types for Colors, Quotient numbers, or whatever small and handled directly for efficiency. It makes a big difference if you store a color inside a class, or want to make an array of colors - a snap with structs, a potential pit for classes. And there comes the need for generics, etc! So this is our solid groundwork, we cannot move from it. We need a new language, not another Java. :) As far as i know this newsgroup, the idea to drop compatibility further would not be welcomed. After all, we need something to access C structs, else we would be even unable to call Windows APIs without descending near modern Java performance. -eye
Oct 28 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
If you run { X x = new X; } where X is a struct, it won't compile.  You
would need { X* x = new X; } or just { X x; }

Sean

"Juan C" <Juan_member pathlink.com> wrote in message
news:bnmbi9$f3u$1 digitaldaemon.com...
 In my opinion... the difference between structs and classes is becoming

 minimal. The only two differences I know are:
 Classes can have ctors and dtors and are created on the heap.
 Structs cannot have ctors and dtors and are created on the stack.

 Am I correct so far?

 If structs are allowed to have ctors and dtors that leaves allocation

 as the only difference.

 Therefore I have a suggestion:

 Don't have two separate concepts, just have one. I suggest some new syntax

 indicate where to allocate the instance when it's newed. A side benefit of

 is that it will be apparent from the new statement where the instance is,

 don't like that in a statement like [ X x = new X ; ] that I have to know
 whether X is a class or struct to determine where the instance is

 Plus (if this is possible) it would allow the user of the class to decide

 to allocate the instance.

 <aside>
 It seems to me that the only reason to have both is for

 with C. And while I see the benefit of that, you must decide whether or

 is a new language. I for one want a new language and scroo the

 But that's just me.
 </aside>

Oct 28 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
The ctors are not supported because Walter believes that if he adds them,
people will want dtors too and they will then have a more compelling
argument for the dtors (orthogonality).  Walter does not want to add dtors
to structs.

Currently if you want to use auto you have to use a class (what's the point
if it's a struct with no dtor?).  Which means auto variables are *not* light
weight.  That limits their usefulness.

In my mind, the only difference between struct and class is that struct is a
value type and class is a reference type.  I do not believe that dtors are
only needed for reference types.  But the D spec is intended to make
exception handling have no work to do besides calling auto class dtors.  I
figure if it can do that, it can destruct other things as well.  Most of the
time the dtor would be empty, generating no code.

We just have to convince Walter.  ;)

Sean

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnlk1r$2g2p$1 digitaldaemon.com...
 I have read multiple times in this newsgroup that D structs cannot have
 constructors or destructors. The reason that was given is that this
 would complicate exception handling.

 I can understand how the need to call destructors makes exception
 handling more complicated, but what about constructors?

 I would very much like to be able to specify constructors for a struct,
 even if it cannot have a destructor. It could make struct initialization
 a lot easier.

 Are constructors only not supported because destructors aren't? Or is
 there actually some constructor-specific reason why we cannot have them?

 Hauke

Oct 28 2003
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Sean L. Palmer wrote:
 The ctors are not supported because Walter believes that if he adds them,
 people will want dtors too and they will then have a more compelling
 argument for the dtors (orthogonality).  Walter does not want to add dtors
 to structs.

Hmmm. So this is all about Walter wanting to protect himself from feature-requests? If Walter wanted that he shouldn't have started D at all - he gets these requests all the time and it will get worse. There is no way around it now ;). But seriously, this argument is a pretty silly one. If you have two problems and you cannot / do not want to solve one of them, but you can solve the other one, then why not do it? Isn't it better to have one out of two instead of none? Hauke
Oct 28 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
I can't see any reason not to have both. Can anyone explain?

"Hauke Duden" <H.NS.Duden gmx.net> wrote in message
news:bnmkir$rfq$1 digitaldaemon.com...
 Sean L. Palmer wrote:
 The ctors are not supported because Walter believes that if he adds


 people will want dtors too and they will then have a more compelling
 argument for the dtors (orthogonality).  Walter does not want to add


 to structs.

Hmmm. So this is all about Walter wanting to protect himself from feature-requests? If Walter wanted that he shouldn't have started D at all - he gets these requests all the time and it will get worse. There is no way around it now ;). But seriously, this argument is a pretty silly one. If you have two problems and you cannot / do not want to solve one of them, but you can solve the other one, then why not do it? Isn't it better to have one out of two instead of none? Hauke

Oct 28 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 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.
Oct 30 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.

Oct 30 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 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.


Oct 30 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
 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.
Oct 30 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 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.
Oct 30 2003
next sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 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.
Oct 30 2003
next sibling parent "Luna Kid" <lunakid neuropolis.org> writes:
 (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.

Oct 30 2003
prev sibling next sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
 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
Oct 30 2003
prev sibling parent reply "Luna Kid" <lunakid neuropolis.org> writes:
 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.
Oct 30 2003
parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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.

Oct 30 2003
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
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.


Oct 30 2003
parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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

 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:



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



Oct 30 2003
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"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

 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.
Feb 08 2004
prev sibling parent reply Scott Wood <scott buserror.net> writes:
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
Feb 08 2004
parent reply Sean Kelly <sean ffwd.cx> writes:
Scott Wood wrote:
 Thus, struct constructors in the absence of such things are still
 useful, IMHO.

Are struct values still default constructed though? Sean
Feb 08 2004
parent reply imr1984 <imr1984_member pathlink.com> writes:
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

Feb 09 2004
parent reply Chris Paulson-Ellis <chris edesix.com> writes:
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.
Feb 09 2004
next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"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
Feb 09 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Chris Paulson-Ellis" <chris edesix.com> wrote in message
news:c07o3k$1n67$1 digitaldaemon.com...
 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.

The optimizer's job is to remove the redundant assignments.
Feb 11 2004
prev sibling next sibling parent reply "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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.

Oct 31 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
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.


Nov 01 2003
prev sibling parent "Matthew Wilson" <matthew-hat -stlsoft-dot.-org> writes:
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.

Oct 31 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Sean L. Palmer" <palmer.sean verizon.net> a écrit dans le message de
news:bnmbmb$f85$1 digitaldaemon.com...
 The ctors are not supported because Walter believes that if he adds them,
 people will want dtors too and they will then have a more compelling
 argument for the dtors (orthogonality).  Walter does not want to add dtors
 to structs.

 Currently if you want to use auto you have to use a class (what's the

 if it's a struct with no dtor?).  Which means auto variables are *not*

 weight.  That limits their usefulness.

If a class is declared auto, does we have all the overhead associated with a normal class. In particular, I think that we won't have any overhead for the memory allocation and since the variable would be local, the compiler might even be able to skip much of the initialisation (of base Object, v-table,...) if the variable is used only locally (for exemple a class that would restore the current color for a graphical UI). If this is so, then the need for destructors in struct is not so important since we could uses auto class instead. OTOH, constructors are more interesting since they allows an object to be constructed in different ways. But IMHO, I think that struct should be POD struct as in C... particulary if we do not want to support compatibility with C++ classes. Maybe the best solution would be to have more choices by having attributes (like we have auto for classes) that would allows to modify the behaviour to our needs... But then, the problem is that having so much possibilities, someone would never knows from the code what to expect from some basic operations like copy-construction, assignment,... Or should we care ? Is it the designer or the user (or both) that should decide what it is possible to do and how it works? Philippe
 In my mind, the only difference between struct and class is that struct is

 value type and class is a reference type.  I do not believe that dtors are
 only needed for reference types.  But the D spec is intended to make
 exception handling have no work to do besides calling auto class dtors.  I
 figure if it can do that, it can destruct other things as well.  Most of

 time the dtor would be empty, generating no code.

But this is a big difference... If we allows struct to have destructors, it mean that we also need assignment and copy-construction (as in C++). Is this the case? OTOH, allowing constructors (but no copy constructor) can works even if the type is otherwise a POD type. The only difference with C would be that the struct would always be initialized...
 We just have to convince Walter.  ;)

 Sean

Oct 28 2003