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


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




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


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


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


point

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


light

 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


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.


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