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