On Sat, Apr 26, 2008 at 5:22 PM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
... boost should at least _try_ to be easy to for newbies as well as experts right? That would also help you by reducing the number of times you have to say RTFM ;-)
Yes, of course. At least to the extent that other aspects of a library do not suffer unduly. Must always strike that balance, and this *is* a set of c++ libraries after all. I think that Tom's point was that gil is a 'generic' library and is
all-headers (it must be, it is generic), so adding a feature that would require a _new_ depency on _another_ library, particularly one that has to be compiled, would be a big hassle.
I think we're trying to agree on the meaning of 'big' and 'hassle' in this context. At least that was my goal. I hear people asserting that libs should be "header-only" to avoid major hassles, and was wondering why. Also, I'm not so bold as to assert that a generic piece of code should not use any other code that is not also generic. I'm also not suggesting that you were implying that either.
The feature had better be REAL important, or it should be ommitted.
This is of course totally subjective, based on your definition of 'big' and 'hassle' above. Expert or not, you have to agree
that adding a new build dependancy is more of a hassle than not doing so.
It certainly adds a new build dependency. ;-) I honestly don't personally consider adding -lboost_date_time<blah> to my link line to be a hassle of any magnitude. But that's me. I already have that lib built and in place. It may be much more of a "hassle" for others.
I dont think that the comment had to do with moving chunks of code from a '.cpp' file into a '.hpp' file, I think that would be silly (except maybe for the way Boost.Test does it optionally ...).
I agree. That would be quite silly, unless it really ought to have been that way in the first place. Jon