Boost logo

Boost :

Subject: Re: [boost] Boost and exceptions
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-22 14:24:53

on Fri Jun 22 2012, "Robert Ramey" <> wrote:

> Dave Abrahams wrote:
>>> I mean, if there is a problem with boost::throw_exception or any
>>> other part of Boost Exception, I'd like to know about it.
>> Attempting to break a deadlock here...
>> It seems clear to me from his posts that Robert wants to talk about
>> the process and has forgotten any specifics about actual problems.
>> It seems clear to me from your posts that you are most concerned with
>> actual problems.
>> Since he doesn't have the information, why not take
>> his suggestion and search the lists for problems involving
>> throw_exception and serialization?
>> Seems like the only way for you to make progress.
>> I'm not sure how to create progress for Robert, unfortunately.
> lol - then it doesn't matter as it seems I'm (almost) the only one
> that is concerned by this.
> The problem was the gratuitious inclusion of a new
> dependency.

I wish you would stop using the term "gratuitous" here. I don't have
any position on who's right or what's better, but clearly some people
thought the inclusion of this dependency had a purpose and wasn't
totally unnecessary.

> The extent/nature of any problem it created or didn't create is not
> relevant here. Just the injection of a new body of code which
> replaced two lines and added no functionality used/needed by the
> serialization library makes the any library which used
> boost::throw_exception "bigger" for no reason. It makes the library
> more "fragil". It means I have I a new place to look if something
> needs looking into. etc.etc.
> Sorry, I just can't understand why anyone fails to see this point.

Because, while it's true that it has those effects, that sort of thing
happens all the time, and most of us see no reasonable way of stopping
it without severely constraining Boost development.

Don't you regularly "inject new bodies of code" into Boost.Serialization
that "replace lines and add no functionality used/needed by" Boost.MPI?

Don't you expect the author of type_traits to do the same thing?

> So we'll just move on as Vicente suggested. That will
> be satisfactory from my standpoint.

I'm happy to move on if you're really going to put this behind you. If
you won't truly be able to, then we should keep talking until we can all
understand each other because this is at least the 2nd time we've had a
long argument about it and it would be a shame to have to go over the
same ground again.

Dave Abrahams
BoostPro Computing

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