In article 7C96@pratique.fr, Valentin Bonnard <bonnardv@pratique.fr> writes:
>Igor Boukanov wrote:
>>
>> auto_ptr destructor nothrow now?
>>
>> Is it true that the final version of auto_ptr has the following
>> destructor signature:
>> ~auto_ptr() throw();
>
>Yes
>
>> Would it mean in this case that each ~auto_ptr implementation
>> should look like:
>>
>> ~auto_ptr() throw() {
>>   try { delete ptr_holder; } catch (...) { }
>> }
>
>No
>
>Types used in the library can't throw in their dtor (otherwise
>undefined behaviours follows (at least that's what I have been
>told)).

I believe it is a problem only if the exception escapes from
the dtor. In this example, the dtor does not exit via an exception.
I don't know of a reason why the example code would not be OK.

---
Steve Clamage, stephen.clamage@sun.com
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage<clamage@Eng.Sun.COM> wrote:
>Valentin Bonnard <bonnardv@pratique.fr> writes:
>>Igor Boukanov wrote:
>>> Would it mean in this case that each ~auto_ptr implementation
>>> should look like:
>>>
>>> ~auto_ptr() throw() {
>>>   try { delete ptr_holder; } catch (...) { }
>>> }
>>
>>No
>>
>>Types used in the library can't throw in their dtor (otherwise
>>undefined behaviours follows (at least that's what I have been
>>told)).
>
>I believe it is a problem only if the exception escapes from
>the dtor. In this example, the dtor does not exit via an exception.
>I don't know of a reason why the example code would not be OK.

Here, the destructor in question is the one called by the
delete expression.  User code cannot count on ~auto_ptr<>
being implemented as above, because it is undefined what
happens if "delete ptr_holder" throws.  Therefore, ~auto_ptr<>
may be implemented as efficiently as possible, which might
mean propagating the exception, calling _exit(), or crashing.

--
Nathan Myers
ncm@nospam.cantrip.org  http://www.cantrip.org/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
<snip>
>
> >> Would it mean in this case that each ~auto_ptr implementation
> >> should look like:
> >>
> >> ~auto_ptr() throw() {
> >>   try { delete ptr_holder; } catch (...) { }
> >> }
> >
> >No
> >
> >Types used in the library can't throw in their dtor (otherwise
> >undefined behaviours follows (at least that's what I have been
> >told)).
>
> I believe it is a problem only if the exception escapes from
> the dtor. In this example, the dtor does not exit via an exception.
> I don't know of a reason why the example code would not be OK.
>

Though the implementation shown above gaurantees that exception would
not propagate out of ~auto_ptr() method, IMO the implementation is
flawed. A library class cannot suppress information propagation
deliberately to gaurantee the interface. The implementation shown above
is providing false security to its users. I would rather have the
program terminate abnormally than suppress exception propagation.

Srinivas
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Srinivas Vobilisetti <srv@cs.wayne.edu> wrote in article
<3500427A.52D2@cs.wayne.edu>...
> Steve Clamage wrote:
> <snip>
> >
> > >> Would it mean in this case that each ~auto_ptr implementation
> > >> should look like:
> > >>
> > >> ~auto_ptr() throw() {
> > >>   try { delete ptr_holder; } catch (...) { }
> > >> }
> > >
> > >No
> > >
> > >Types used in the library can't throw in their dtor (otherwise
> > >undefined behaviours follows (at least that's what I have been
> > >told)).

And told correctly:

  17.4.3.6  Other functions                       [lib.res.on.functions]

1 In certain cases (replacement functions, handler functions, operations
  on types used to instantiate standard  library  template  components),
  the  C++ Standard Library depends on components supplied by a C++ pro-
  gram.  If these components do not meet their requirements,  the  Stan-
  dard places no requirements on the implementation.

2 In particular, the effects are undefined in the following cases:

  --for  replacement  functions  (_lib.new.delete_),  if  the  installed
    replacement function does not implement the semantics of the  appli-
    cable Required behavior paragraph.

  --for  handler  functions (_lib.new.handler_, _lib.terminate.handler_,
    _lib.unexpected.handler_), if the installed  handler  function  does
    not  implement  the  semantics  of  the applicable Required behavior
    paragraph

  --for types used as template arguments when instantiating  a  template
    component, if the operations on the type do not implement the seman-
    tics  of  the  applicable   Requirements   subclause   (_lib.alloca-
    tor.requirements_,     _lib.container.requirements_,     _lib.itera-
    tor.requirements_, _lib.numeric.requirements_).  Operations on  such
    types can report a failure by throwing an exception unless otherwise
    specified.

  --if any replacement function or handler function or destructor opera-
    tion  throws an exception, unless specifically allowed in the appli-
    cable Required behavior paragraph.

  --if an incomplete type (_basic.types_) is used as a template argument
    when instantiating a template component.

> > I believe it is a problem only if the exception escapes from
> > the dtor. In this example, the dtor does not exit via an exception.
> > I don't know of a reason why the example code would not be OK.
> >
>
> Though the implementation shown above gaurantees that exception would
> not propagate out of ~auto_ptr() method, IMO the implementation is
> flawed. A library class cannot suppress information propagation
> deliberately to gaurantee the interface. The implementation shown above
> is providing false security to its users. I would rather have the
> program terminate abnormally than suppress exception propagation.

I think the correct implementation is simply:

   ~auto_ptr() throw() {
      delete get();
   }

Which implies an implementation something like:

   ~auto_ptr() {
 try {
         delete get();
      } catch (...) {
         unexpected();
      }
   }

It is true that the destructor and the global operator delete are
forbidden from throwing, but a class-specific operator delete might
throw.  A decent compiler will use throw() specs, if any, on the
operator delete and destructor to optimize away the try/catch.

Greg Colvin
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

auto_ptr destructor nothrow now?

Is it true that the final version of auto_ptr has the following
destructor signature:
~auto_ptr() throw();

Would it mean in this case that each ~auto_ptr implementation
should look like:

~auto_ptr() throw() {
  try { delete ptr_holder; } catch (...) { }
}

???

--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Igor Boukanov wrote:
>
> auto_ptr destructor nothrow now?
>
> Is it true that the final version of auto_ptr has the following
> destructor signature:
> ~auto_ptr() throw();

Yes

> Would it mean in this case that each ~auto_ptr implementation
> should look like:
>
> ~auto_ptr() throw() {
>   try { delete ptr_holder; } catch (...) { }
> }

No

Types used in the library can't throw in their dtor (otherwise
undefined behaviours follows (at least that's what I have been
told)).

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c++ Valentin Bonnard <bonnardv@pratique.fr> wrote:
> Igor Boukanov wrote:
> >
> > auto_ptr destructor nothrow now?
> >
> > Is it true that the final version of auto_ptr has the following
> > destructor signature:
> > ~auto_ptr() throw();
>
> Yes
>
> > Would it mean in this case that each ~auto_ptr implementation
> > should look like:
> >
> > ~auto_ptr() throw() {
> >   try { delete ptr_holder; } catch (...) { }
> > }
>
> No
>
> Types used in the library can't throw in their dtor (otherwise
> undefined behaviours follows (at least that's what I have been
> told)).

And I supose that the same true for a user-defined operator delete? I.e
is it possible to deduce from the standard that
void opeartor delete(void* p) {
   if (debug && p was not allocated) { throw logic_error("Bad pointer"); }
   free(p);
}
causes undefined behaviour when used with auto_ptr ?

--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Igor Boukanov <boukanov@sentef1.fi.uib.no> wrote in article
<6dj7u5$4kf$1@toralf.uib.no>...
> ...
> is it possible to deduce from the standard that
> void opeartor delete(void* p) {
>    if (debug && p was not allocated) { throw logic_error("Bad pointer");
}
>    free(p);
> }
> causes undefined behaviour when used with auto_ptr ?

No.  The unexpected_handler will be called if you throw during the
auto_ptr destructor.

Greg Colvin
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]