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.
What problems has it caused?
lol - this discussion for one. But your comments are sincere and really deserve a more serious answer so I'll try to supply one. TL;DR Someone comes up with some idea for a program/application/library or whatever. This idea is meant to solve some problem that this person has in mind. At this point - any subsequent point, this idea will move in two directions 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 How to recognize a) 1) You use it or incorporate into your app in a very short time because it's easy to understand what it does and how to use it. 2) you use it and you forget you used it because it caused no surprises. 3) It works for years without a hassle 4) it saves total work - rather than expanding it. 5) if anything breaks - its easy to find the cause and the person who should fix it. b) It can evolve into a more amorpheous and all encompassing idea that looks more like a "bag of features" rather than a coherent concept which one can understand immediately and systematically unwrap to understand at a more detailed level. We have some software in boost which exmplefies this. How to recognise b) 1) It might look simple to use, but turns out to consume a lot of time when you try to use it. (I love it when a salesman demonstrates how simple something is to use and I take it home - and damned if I'm not mystified by it!) 2) It's has surprising behavior 3) It breaks when you don't expect it 4) if you complain - it's "your fault" because you didn't understand how to use it, didn't read the docs, didn't look the code or whatever. 5) It adds total work rather than diminishing it. 6) it becomes hard to determine who is responsable for problems when they occur. Of course these are idealized descriptions no library/application will fall 100% in either camp. This description applies to a lot more stuff than just software - see the book "The design of everyday things". Even if the idea is seems clearly defined, as time goes on there is a huge amount of pressure to add "just one feature" because someone would find it useful. The result is that the original idea morphs from a clearly defined purpose to some sort of .... well hard to describe. The project start's to suffer from the symptoms in b) above. Projects in the "b)" category tend to grow and die of a combination of obesity, weakness, lack of direction. Basically they tend ot become victims of their own success. I realize this is "just one feature which a lot of people would find useful" but who speaks for the people who don't find it useful? I do. You're thinkng this is a one time special case. But it's not. I fight a constant running battle to keep the serialzation library from evolving into something that is unmaintainble, overly bloated, harder to understand and use, etc. I can't tell you how many times I've had to disappoint someone who feels they need this "one more tihng". So now maybe you can understand how I can object to having this "great feature" injected into the library without my knowing about it. I'm not intending to be the "savanorla" of boost, C++, or software developement practices. I just happened to be the person at the scene of this particular accident. Robert Ramey