Hi,
>>>
>> From the paper:
>>
>> <<snip>>
>> "Note that an explicit class that does not have a declared destructor
>> cannot reside on the stack or as a static >object because it is not
>> destructible. However it could be constructed dynamically. The burden
>> for clean-up then
>> remains with the class user (possibly through explicit destruction of
>> sub-objects followed
>> by a call to operator delete)."
>> <<snip>>
>>
>> This looks like lot of trouble. Maybe destructor should be left out
>> the scheme (requiering that explict class must have explicit
>> destructor, maybe?).
>
>
> I, and I think my co-author agrees, think otherwise. The quote you give
> was our demonstration that it is not necessarily a programming error to
> have a type that has no destructor. Much of the motivation for explicit
> classes is that the programmer gets exactly what they ask for, no more
> and no less.
>
> There are already idioms that use such things as undefined private
> dtors. It is our contention that all such idioms (private, undefined for
> otherwise implicitly defined functions) are, at best, hacks working
> round a deficiency in the current language. They necessarily fail to
> express intent fully in code (the user has to check the implementation
> to ensure that the function has not, in fact, been defined.
First of all, I completelly agree with the intent of the proposal.

Anyway, it's not clear for me what is the utility of the private
*undefined* destructor. Maybe I'm misssing something, but if we want
heap only class isnt't it enough to make destructor private?

Boris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Regarding the paper "Explicit Class and default definitions" (N1717)
at http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf

I can see many more defaultable functions than the four mentioned.
There are many functions with a "best practice" implementation:
- operator+ calling operator+=
- postfix++ calling prefix++
- less() calling operator<
- ...

Example: it's much easier to write:
   Foo operator+(const Foo&, const Foo&) { default }
than
   Foo operator+(const Foo&l, const Foo&r) { return Foo(l)+=r; }
as I don't know how to use the various return value optimalizations.

Are there any plans to add more defaultable functions to the proposal,
or is this something left to the compiler implementators to experiment
with?

Sjoerd

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi, > Regarding the paper "Explicit Class and default definitions" (N1717)
> at http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf

>
 From the paper:

<<snip>>
"Note that an explicit class that does not have a declared destructor
cannot reside on the stack or as a static >object because it is not
destructible. However it could be constructed dynamically. The burden
for clean-up then
remains with the class user (possibly through explicit destruction of
sub-objects followed
by a call to operator delete)."
<<snip>>

This looks like lot of trouble. Maybe destructor should be left out the
scheme (requiering that explict class must have explicit destructor,
maybe?).

Boris

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <co6rrf$a3s$1@sunce.iskon.hr>, Boris Bralo
<boris_bralo@hotmail.com> writes
>Hi, > Regarding the paper "Explicit Class and default definitions" (N1717)
>> at http://www2.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1717.pdf
>
>>
>From the paper:
>
><<snip>>
>"Note that an explicit class that does not have a declared destructor
>cannot reside on the stack or as a static >object because it is not
>destructible. However it could be constructed dynamically. The burden
>for clean-up then
>remains with the class user (possibly through explicit destruction of
>sub-objects followed
>by a call to operator delete)."
><<snip>>
>
>This looks like lot of trouble. Maybe destructor should be left out the
>scheme (requiering that explict class must have explicit destructor,
>maybe?).

I, and I think my co-author agrees, think otherwise. The quote you give
was our demonstration that it is not necessarily a programming error to
have a type that has no destructor. Much of the motivation for explicit
classes is that the programmer gets exactly what they ask for, no more
and no less.

There are already idioms that use such things as undefined private
dtors. It is our contention that all such idioms (private, undefined for
otherwise implicitly defined functions) are, at best, hacks working
round a deficiency in the current language. They necessarily fail to
express intent fully in code (the user has to check the implementation
to ensure that the function has not, in fact, been defined.

Rather than simplifying the proposal, making a dtor required complicates
it by special casing one of the special functions. We want no
unnecessary special cases because those have to detailed in the Standard
itself. At best the quoted paragraph would form part of a rationale and
would never be part of the Standard.

--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]