|
Boost : |
Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-11-18 08:01:21
Nevin Liber wrote:
> On 17 November 2010 16:23, Edward Diener
> <eldiener_at_[hidden]> wrote:
>
> > Alternatively I could even see putting all the operator
> > traits in their own namespace of 'boost::operators',
> > dropping the 'operator_' in their name, and allowing the
> > end-user to surface them to just the 'boost' namespace via a
> > using declaration as they like.
>
> The problem, of course, is when you need them in a header, where using
> declarations cannot be scoped. This makes Boost.Multi-index a bit
> unwieldly, for example.
>
> I really don't mind if it gets spelled with namespaces instead of
> underscores, but a using declaration is not a motivation for it.
boost::operators::has_less_than
boost::has_operator_less_than
The "penalty" in a header, assuming no typedefs or using directives in class definitions or in template or inline function definitions, is two extra characters. In those contexts where a using directive is not a problem, the advantage is nine characters. I think the namespace wins pretty handily in that equation.
Obviously, one isn't too likely to use many such traits in any given inline or template function definition, so a using directive to use just one means an even worse penalty: "using namespace boost::operators; has_less_than" has 18 more characters than does "boost::has_operator_less_than." Thus, the namespace loses significantly in that comparison. Add the use of a second trait and the balance tips in favor of the namespace again.
There is, however, one additional benefit to the namespace approach: dealing with boost::has_new_operator. We can keep has_new_operator as a vestigial and even deprecated oddity and put the rest, including has_new, in the operators namespace. Thus, folks will be encouraged to use boost::operators::has_new due to its consistency with all of the rest. (One might even make has_new_operator hard to find in the documentation to further the adoption of the other.)
_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer, Core Software using std::disclaimer;
Susquehanna International Group, LLP http://www.sig.com
IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk