Nevin Liber wrote:
On 22 June 2012 15:40, Robert Ramey <ramey@rrsd.com> wrote:
In a previous post, I specifically excluded "convenience headers" from being considered as "violating" this "rule". They are not at issue here.
You keep asserting this, but I haven't seen you explain *what* makes the convenience headers so special that they do not violate your rule.
I'm sure of what "my rule" means. But I try to clarify my view.: I have no complaint or issue with headers whose function is to contain a list of library headers so that uses can include a bunch of related headers at with just one include statement. I have referred to this practice as a "convenience header" which I believe is common practice on this list. FWIW I presonally don't like "convenience headers" because I like to have a better idea of what I'm actually including. But let's chalk that up to personal taste and not anybody's problem. The following sort of example file:boost/throw_exception.hpp #include <boost/exception/.?.hpp> is what I'm objecting to. This means that when I my code contains #include <boost/throw_exception.hpp>
From reading the code, I don't it to expect to include a whole 'nother library. And that's they way it was before it was changed. The change created surprises for me - and I just like to minimize surprises. This is about writing code which does what it looks like it says it's going to do - no more no less.
Also note that I'm not saying that following the practice I recommend will solve all problems and avoid all surprises. But it contributes to diminishing them and also helps keep the program/library scope from expanding beyond the minimum it needs to be to do the job. It's not that complicated and I don't think it should be all that controversial. Robert Ramey