Daniel James wrote:
On 22 June 2012 20:41, Robert Ramey <ramey@rrsd.com> 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