This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: throw specs on Standard destructors


>> First, in any function so declared that itself called a function
>> which might throw something not listed, the compiler would have to
>> generate code to catch them and call terminate().
>>
>> Third, any code that depends on tight throw specs in libstdc++
>> would not be portable to other implementations. 
>
> I think the first and third points still hold.

Ok, let's break this into two parts:  std::auto_ptr and std::string.
My original post was about std::string, but I think the std::auto_ptr argument is much more clear, so I'll address that.

>From 3.2.1 sources:
  /**
   *  When the %auto_ptr goes out of scope, the object it owns is deleted.
   *  If it no longer owns anything (i.e., @c get() is @c NULL), then this
   *  has no effect.
   *
   *  @if maint
   *  The C++ standard says there is supposed to be an empty throw
   *  specification here, but omitting it is standard conforming.  Its
   *  presence can be detected only if _Tp::~_Tp() throws, but this is
   *  prohibited.  [17.4.3.6]/2
   *  @end maint
  */
  ~auto_ptr() { delete _M_ptr; }

In fact, this lack of throw spec can be detected by exactly my original test:
  #include <memory>
  struct Base
  {
    virtual ~Base() throw() {}
  };

  struct Der : Base
  {
    std::auto_ptr<int> foo;
  };

  int main()
  {
    Der d;
  }

So since every other member of std::auto_ptr does have an empty throw spec,
and the destructor is stated in the spec (according to the comment) to have an empty throw spec,
it would seem the converse of your third point would support adding the empty spec here also:

>> Third, any code that depends on tight throw specs in libstdc++
>> would not be portable to other implementations. 
Any code that depends on tight throw specs of Standard-conformant implementations
would not be portable to GCC.

-Kenny

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only
for the individual named.  If you are not the named addressee you
should not disseminate, distribute or copy this e-mail.  Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.  The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission.  If
verification is required please request a hard-copy version.  This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]