Boost logo

Boost :

From: Thomas Plum (tplum_at_[hidden])
Date: 2000-07-18 14:13:38

Please excuse if late or irrelevant ...

Since exception-specs need to be
consistent throughout a compilation, what about using boost-standardized
macros to enable or disable them uniformaly ... such as
  #define THROWS(x) throw x

to accept something like
  void f() THROWS(()) OR void g() THROWS((range_error, domain_error))
and produce something like
  void f() throw () OR void g() throw (range_error, domain_error)
if throw-specs are desired for this compilation,
or empty replacements if throw-specs are not desired.

I know some folks consider macros like this to be inelegant, but they
are well suited to situations like this current topic, IMHO ...

At 12:35 PM 7/16/00 -0400, you wrote:
>David Abrahams wrote on 7/16/2000 11:29 AM
>>From: "Beman Dawes" <beman_at_[hidden]>
>>> Should boost programming guidelines ban exception-specifications?
>>Yes, without specific compiler switches which turn them on when it's been
>>determined that it is an optimization.
>>But I am absolutely *certain* that we've discussed this on the list and that
>>there was (at least) a published web page which said they should be avoided.
>>I think it was the library guidelines. I am also pretty sure that the
>>discussion was specifically in reference to smart_ptr and that we had
>>decided to leave them off on purpose. So I'm surprised to hear that they
>>crept back in.
>No I don't think they should be banned. Though I will admit that I would
>vote against they're use in every project I'm currently familiar with.
>But I think they should be considered on a case by case basis, and not
>banned with a blanket statement. They provide a runtime behavior that
>could be desirable in some circumstances.
>Wish you had something rad to add to your email?
>We do at


Thomas Plum Plum Hall Inc, 3 Waihona Box 44610, Kamuela HI 96743 USA
tplum_at_[hidden] TEL +1-808-882-1255 FAX +1-808-882-1556

Boost list run by bdawes at, gregod at, cpdaniel at, john at