>From: jason@cygnus.com (Jason Merrill)
>
>>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:
>
>>  All class types have destructors, if not user written then compiler
>> generated. In both cases the destructor may be 'trivial', that is, be
>> optimisable to nothing.
>
>I disagree.  If a class has a base or member with a destructor, the
>compiler will generate one; otherwise, it won't.  There is a lot of text in
>[class.dtor] which talks about classes with or without destructors.

 And much of that text is subject to revision.
So my statement is based on coherence not the WP. You cant argue
for changes in the WP based on assuming the WP.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <1994Jun29.200413.7146@ed8200.ped.pto.ford.com> haubert@ed8200.ped.pto.ford.com (Phil Haubert) writes:
>John Max Skaller (maxtal@physics.su.OZ.AU) wrote:
>
>:  There is currently a major proposal to integrate
>: the built-in types into the overload scheme by modelling
>: them "as if they were classes", more specifically, modelling
>: the built-in operators "as if they were functions".
>
>Interesting. Would this allow access to inheritance and promotions
>as well?

 No. I should have more specific: the modelling is ONLY
for overload resolution purposes.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:

>> From: jason@cygnus.com (Jason Merrill)
>>>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:

>>> All class types have destructors, if not user written then compiler
>>> generated. In both cases the destructor may be 'trivial', that is, be
>>> optimisable to nothing.

>> I disagree.  If a class has a base or member with a destructor, the
>> compiler will generate one; otherwise, it won't.  There is a lot of text in
>> [class.dtor] which talks about classes with or without destructors.

>  And much of that text is subject to revision.  So my statement is
> based on coherence not the WP. You cant argue for changes in the WP based
> on assuming the WP.

I wasn't arguing for changes in the WP.  Saying that part of the WP is
subject to revision is meaningless, since the entire WP is (at least
theoretically) subject to revision.  Is there actually a pending proposal
to change that text?

It would appear that one of the last passages modified in [class.dtor] was
the one that says "Using the notation for a type that does not have a
destructor has no effect.  Allowing this enables people to write code
without having to know if a destructor exists for a given type."  This
seems pretty explicit to me.

The problem is that there are currently two conflicting approaches to
essentially the same user-level semantics being used:

1) A class X that does not define Y will have a default version of Y
generated for it.  Rules that restrict the usage of X depending on whether
or not it contains Y only apply if the default version of Y is "complex",
i.e. a base or member of X has either a user-defined or a "complex" Y.
Builtin types are treated as though they have Y defined, even though they
don't.

2) If a class that does not define Y has a base or member that defines Y, a
default version of Y will be generated.  For any type that does not contain
Y, an expression which would normally call Y uses the default semantics
instead.

Currently the default and copy constructors use approach 1, whereas the
destructor uses approach 2.  My personal feeling is that approach 2 is
cleaner, because it avoids having to define a "complex" compiler-generated
implementation of the method, and it treats builtin types and classes that
do not define the method identically.

On the other hand, approach 1 may be necessary for constructors, since they
can be overloaded.

So it would appear to me that the current situation provides a better
solution than using either approach for both constructors and destructors.

Jason

>From: jason@cygnus.com (Jason Merrill)
>
>>>> All class types have destructors, if not user written then compiler
>>>> generated. In both cases the destructor may be 'trivial', that is, be
>>>> optimisable to nothing.
>
>>> I disagree.  If a class has a base or member with a destructor, the
>>> compiler will generate one; otherwise, it won't.  There is a lot of text in
>>> [class.dtor] which talks about classes with or without destructors.
>
>>  And much of that text is subject to revision.  So my statement is
>> based on coherence not the WP. You cant argue for changes in the WP based
>> on assuming the WP.
>
>I wasn't arguing for changes in the WP.  Saying that part of the WP is
>subject to revision is meaningless, since the entire WP is (at least
>theoretically) subject to revision.  Is there actually a pending proposal
>to change that text?

 Yes. As far as I know its an editorial issue.
>
>It would appear that one of the last passages modified in [class.dtor] was
>the one that says "Using the notation for a type that does not have a
>destructor has no effect.  Allowing this enables people to write code
>without having to know if a destructor exists for a given type."  This
>seems pretty explicit to me.

 Yes, but its easier to just allow the notation to be
written BECAUSE all types have a destructor -- and say
trivial destructors have no effect.
>
>destructor uses approach 2.  My personal feeling is that approach 2 is
>cleaner, because it avoids having to define a "complex" compiler-generated
>implementation of the method, and it treats builtin types and classes that
>do not define the method identically.

 There is currently a major proposal to integrate
the built-in types into the overload scheme by modelling
them "as if they were classes", more specifically, modelling
the built-in operators "as if they were functions".

 Its much easier to say all types have destructors.
Consider: What is the lifetime of an object?

 My answer is: it lives from the time its constructed
to the time it is destroyed. That doesnt work if some types
dont HAVE destructors, because then no point of destruction
is determinable by the rule. You have to say crap like
"the object dies when the destructor is executed, or
when the destructor would have been executed had there been one".
Which is in fact non-normative drivel. So you have to go
back to the rules that determine when destructors are executed
and repeat them all over again to specify the death of
the object.

 [This approach doesnt "work" anyhow, char just doesnt
get 'constructed' at all]

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

John Max Skaller (maxtal@physics.su.OZ.AU) wrote:

:  There is currently a major proposal to integrate
: the built-in types into the overload scheme by modelling
: them "as if they were classes", more specifically, modelling
: the built-in operators "as if they were functions".

Interesting. Would this allow access to inheritance and promotions
as well?

class MyInt    : public int    { MyInt    (int    i=0); };
class MyDouble : public double { MyDouble (double d=0); };

MyInt i = MyDouble();

-phil