Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Daniel James (dnljms_at_[hidden])
Date: 2012-06-23 16:21:56

On 22 June 2012 20:41, Robert Ramey <ramey_at_[hidden]> wrote:
> Daniel James wrote:
>> On 22 June 2012 18:30, Robert Ramey <ramey_at_[hidden]> wrote:
>>> Stewart, Robert wrote:
>>>
>>>> The more dependencies you
>>>> introduce, the more fragile your code becomes, but there's a great
>>>> deal of benefit to reuse, too. The only issue in this case is that
>>>> one can reasonably expect a top-level header to avoid dependencies
>>>> on libraries.
>>>
>>> Personally I wouldn't say it's the only issue. But I'm glad we can
>>> agree that it's its a BIG issue.
>>
>> There are a lot of headers violating your rule.
>
> assuming that's true, it's a bad idea there as well.

>From a quick look there's more than twenty, possibly a lot more. I'm
not counting headers which just include other headers. There used to
be more, I moved the implementation of the unordered containers into
subdirectories to make version control easier. Peter Dimov moved all
of his libraries' implementation into subdirectories as well, I'm not
sure what his motivation was.

I suspect that this might be a different perception of what a top
level header means. When I was first involved with boost (I think Emil
got involved a little while later) this was pretty much standard
practice. I guess that when you were first involved (a few years
earlier) it might have been reserved for more self contained headers.
After I'd been involved for a while, people started to get concerned
as more and more libraries were added and wanted a bit more structure.
Although from what I recall they were more concerned with the boost
namespace getting crowded.

> a) It will become more specific and narrowed in scope and evolve
> into a very clear concept what can easily be grasped as to what it's
> function is.  We have great examples of this in boost - shared_ptr
> static_assert.  Deeper understanding

Well, shared_ptr has evolved. The interface has remained mostly
constant, but the internals have changed quite a lot, which has caused
some issues, particularly on more obscure platforms.

Also, some libraries, while well defined and self contained have
gained dependencies. For example, here are Boost.Array's dependencies:

  DEPENDS
    BoostConfig
    BoostCore
    BoostException
    BoostFunctionalHash
    BoostUtility (for swap)

In terms of headers, it's still light, and, ignoring exception for a
moment, supporting our standard hash and swap functionality seems
pretty essential to me (obviously, I am biased here).

I've been getting a bit annoyed with how I'm accumulating dependencies
in Boost.Unordered, but it's hard to avoid if I want to support C++11
features (e.g. to implement 'piecewise_construct' I had to add a
dependency on Boost.Tuple).

> So now maybe you can understand how I can object to having this
> "great feature" injected into the library without my knowing about it.

If it wasn't clear, I was asking specifically about including headers
from sub-directories in a top level header.