Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-23 21:41:06

on Sat Jun 23 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> Dave Abrahams wrote:
>> on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>>
>>> Dave Abrahams wrote:
>>>> on Fri Jun 22 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
>>>
>
>>>>> 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?
>>>
>>> No. I don't do this.
>>
>> I believe you mean that sincerely, but I just don't see how it's
>> possible for you to know that.  Do you keep track of exactly which of
>> Boost.Serialization's headers is being used by every dependent Boost
>> library and make sure that *no* new capabilities creep into any of
>> those headers as you extend/evolve the library?  Even if you _can_ do
>> that for other Boost libraries, you can't possibly do it for your
>> users.
>
> I use other libraries in the implementation.  These implementation
> details are generally not directly accessible by the library user. 

Of course they are, if they end up in the user's translation unit.  The
user only has to have a "using namespace boost;" in his code to create
an instant ambiguity when one of your "implementation details" adds a
new name, or when you add a new implementation detail yourself.  Blame
it on the C language inclusion model.  We need true modules in C++, but
that's irrelevant to this conversation.

> Any code injection/enhancement would be something that users would see
> in library portability, performance, robustness etc. It's my job to
> ensure that that is what happens.

You mean to ensure that it (users seeing changes in portability,
performance, robustness, etc) *doesn't* happen?

> Actually, you've hit the nail on the head here.  Chaning
> boost::throw_exception injects a dependency on a whole other boost
> library into the serialization library. And of course this is the crux
> of my complaint.

In general it's hard for me to believe that you'd complain (or probably
even ever notice) if one of the libraries you depend on as an
"implementation detail" added a dependency of its own, and thereby
injected a new dependency into Boost.Serialization... unless this change
happened to break something.  I assert that this kind of thing happens
all the time: every Boost library author (well, maybe Peter Dimov is an
exception) feels free to start using some new library as an
"implementation detail" of his own.

>> Of course it was.  Do you think the problems with
>> boost::throw_exception were intentional?
>
> I'm sure the changes were intentional.  I think the dispute is
> about whether those changes are problems (my view) or
> useful features whose value far exceeds any side effects
> of the changes (other's view) that.
>
>>> But surely you do change existing headers from
>> time-to-time?
>
> only to
>
> a) fix bugs
> b) re-implement some existing interface
> c) add some new feature to the serialization library
> d) improve robustness, portability, etc.
>
> note that this above list does not include changing the functionality
> corresponding to some already existing interface - which is what
> we're talking about here.

Any of these actions could result in "new bodies of code" being
"injected" that "add add no functionality used/needed by" Boost.MPI (to
choose "at random" one dependent of Boost.Serialization), and probably,
they often do.

>>> But that would of course that be a different case.
>>>
>>>> Don't you expect the author of type_traits to do the same thing?
>>>
>>> No. I don't.
>>>
>>> If I use something like "is_arithmetic" I expect it's functionality
>>> to not change in the future.
>>
>> That's not at all like what you said happened.  Sure you would expect
>> is_arithmetic to remain the same.
>
>> What you said was that "new bodies
>> of code" were "injected" that "add no functionality used/needed by
>> Boost.Serialization."
>
> well, boost::throw_exception(x) wraps the x in some other class
> with some other stuff and does a throw.  

Right.  That changes the type actually thrown, and that's a change of
behavior someone slipped in, which is a totally different issue from the
header dependency issue.  The change of behavior in this case is almost
certainly benign most of the time, since the exception actually thrown
has a copy of x as a base subobject...but still, it's a substantial
change of behavior, and it's entirely legitimate to complain if and when
something like this happens behind your back (I'm not saying it did or
didn't happen behind your back, though; I don't know the history well
enough to judge).

> The serialization library does't use this.  In order do this, I has to
> include some headers from boost exception.  I've labeled this "code
> injection".  Maybe it should have been "dependcy extension" but not
> the less I don't think I've said anything misleading..

No, I don't think so either.  I just think you fail to appreciate how
easily, silently, and commonly header dependencies actually proliferate
in Boost.  These things happen *all the time*, and you never even
notice.

>> We did that to type_traits when we upgraded it
>> to work more smoothly with Boost.MPL.  Changes like that are rare, but
>> changes like this one aren't:
>>
>>        The maintainer of is_arithmetic makes changes to support
>>        compiler X.  Boost.Serialization does not support compiler X.
>>        Therefore these changes "add no functionality used/needed by
>>        Boost.Serialization."
>>
>> Such changes might be arbitrarily complicated, including pulling in
>> new header files.
>
> In this example the choice is clear.  Either add suport for compiler X
> at the cost of increasing the code base or leave compiler X
> unsupported.  And as the person responsable for the serialization
> library - I need to have the authority to make this decision.  In this
> case the decision was made for me

The decision about change of behavior was made for you.  Let's just keep
that clearly distinguished from the library dependency issue, please.

> and didn't really evaluate all the concequences. 

Who didn't?

> This is no surprise because changes like this have a much larger
> ripple effect that first meets the eye.  This has been my principal
> objection from the begining.
>
> Take the pottery barn rule:
>
>     "if you break it, you bought it"
>
> this seems reasonable.  Hence the following must be true:
>
>     "If you're not prepared to buy it, don't risk breaking it!"
>
> So, unless one is prepared to take responsablity for the consequences,
> to muck with some other library.

Emil clearly was prepared to take responsibility for the consequences,
and he did.  He broke something (bad Emil!), and then he fixed it (good
man!).  What am I missing?

>> We have a plan that's less ad-hoc than the last one?
>
> There are number of other libraries which have implemented the
> same work around that the serialization library has - presumably
> for similar motivations.  Each of these has been specified in it's own
> namespace.  We're considering consolidating these into one header
> in the boost namespace/directory to put all these work arounds in
> a single place.  Basically this would give a new name to the original
> boost::throw() functionality.

I see.  Doesn't handle the cultural rift, but it's cleaner
architecturally than the status quo.  I'm still concerned that we get
this issue figured out though.

>> My guess so far is that you have something real in mind, but you're
>> not expressing it with enough precision for others to grasp it.  I
>> think it might help if you could make an effort to be extremely
>> concise, so your point is in a non-TL;DR context.  If you use very
>> few words it should be very obvious to you whether they'll
>> communicate what you actually mean to say.
>
> lol - could be.  but it's not as easy as it looks. 

Of course not.  There are several famous quotations about how concision
is harder than verbosity.  But it is worth the effort.  I work at it
every time I write.

> I'll try.

Thank you!  I mean that sincerely.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com