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

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

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

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

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

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

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
>

"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

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>

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