|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2003-10-08 14:33:14
"Powell, Gary" <powellg_at_[hidden]> writes:
> I have read the code and the documents and vote to accept.
>
> I have one suggestion and that is the names "enable_if_c" and the rest
> which end in "_c" should be changed to end in "_cond" or "_condition"
> rather and use the terse and non Hungarian, and non intuitive suffix
> notation "_c" for "char". AFAIK these additional classes are to help
> certain compilers and library writers. Code that uses this stuff will
> be read far more often than written so clarity in naming is worth the
> extra bit of typing.
The "_c" suffix was chosen for compatibility with the convention used
in MPL, and it doesn't stand for "_condition" but "(integral)
Constant". To understand why it should be so terse you really need to
understand the whole design of the library, but you could consider:
typedef list_c<int, 1, 2, 3, 5> l;
typedef vector_c<long, 1, 2, 3, 5> v;
typedef at_c<v, 3>::type v3rd;
typedef at<v, integral_c<unsigned, 2> > v3rd_;
if_c<enabled, a, b>
apply_if_c<enabled, f1<X>, f2<Y> >
and a few others.
> And while its a bicycle shed issue, I do think that good names are
> extremely important.
Agreed. In this case, the argument will have to be over what's
"good".
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk