From: Jonathan Franklin (franklin.jonathan_at_[hidden])
Date: 2008-04-26 19:38:24
On Sat, Apr 26, 2008 at 5:22 PM, John Femiani <JOHN.FEMIANI_at_[hidden]> 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