Re: [boost] Boost and exceptions

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

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 have made some mistakes - particularly in the implementation
> of binary_iarchive which have broken other peoples code.  But
> I assure you this was totally unintentional.

Of course it was.  Do you think the problems with boost::throw_exception
were intentional?

> This wouldn't mean that no new code is never added.  Natually
> one could add a new archive type.  But that would only affect
> those who conciously chose to use it. 

Yes, if you never touch existing headers, you will never cause such a
situation.  But surely you do change existing headers from time-to-time?

> 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."  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.

>> 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.
>
> I'm sympathetic to you view here.  It wasn't really resolved before -
> we just worked around it.  Basically this is what we're going to
> continue to do albeit is a less ad hoc way.

We have a plan that's less ad-hoc than the last one?

> I'm really sympathetic to those who see this as a pointless, endless
> argument.

I'm not among them.  I'm just trying to do everything possible to ensure
that this time around the argument is point-ful.

> But obviously it's not for those of us involved in it. For the most
> part I don't doubt the good intentions and sincerity of those who are
> disagreeing with me here.  I just think they're wrong and they they
> have failed to make a convincing argument that I'm wrong.  And I
> believe that these "wrong ideas" (my view) make a large negative
> impact on software usability and quality.  

Some of us are arguing with you because we respect your opinions on
these matters, but aren't able to see the "wrong ideas" you've been
pointing at.  Arguing is a way of probing for enlightenment.  

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.

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