Re: [boost] Boost and exceptions

Subject: Re: [boost] Boost and exceptions
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-06-23 18:56:03

Daniel James wrote:
> On 22 June 2012 20:41, Robert Ramey <ramey_at_[hidden]> wrote:

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

lol - that's the way it's suppose to be.

Time for a story.  When I first made the serialization library, I couldn't
serialize a shared_ptr.  In order to do it I needed for shared_ptr to
include friend::serialization.  I asked Peter to do this and refused in
a pretty abrupt way.  This really annoyed me.  After all, it was no
big deal for him to add this one line!!!. His point was that
by doing this it would tie his hands in the future implementation of
shared_ptr.  After some time I came to understand why he was
right and I was wrong.  As you can imagine this is sort of a rare
event.  I know it's not exactly the same as the current situation
but it's similar in my view.

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

This is a little confusing.  Here is the way I think about it.

"standard library" - the C++ standard library.
"core library" - things that directly are in namespace/directory boost and 
depend only on other "core libraries" or the C++ standard library
    example boost_static_assert, boost_non_copyable.
"application library" - thingls that are in their own namespace/directory 
and can depend upon anything.
    example serialization, exception, etc.
"user header" - a header expected to be used by library users as opposed to 
something internal to the library.
"convenience header" - a file with a list of includes for all the user 
headers for a particular library.

rules:
"core library" code can only call other core library modules
"application library" code can call anything
directory names should match namespace names.

misc:

boost/utility - an application library which includes a bunch of small 
applications

Much of Boost falls together along these lines anyway.  There are some 
notable exceptions
boost.range is in the boost namespace but in the directory,  a bunch of 
others etc.

This is very helpful to me when I write code (to the extent that its true). 
It gives me a very clear
idea of what I'm sucking into the library/application.  Sometimes I'll 
include a large header just
for one tiny function and I can see that when I do it.  I can decide on a 
case by case basis
as to which library function I might replace with a home brew version.

I think were sort of on the same page here.

The only thing I would differ with what you've said is that I don't believe 
Boost exception
adds anything when called from a library.  To me it's a "user code" 
facility.

Robert Ramey