Boost logo

Boost :

Subject: Re: [boost] [Review] Boost.Type Traits Extension by Frederic Bron
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-15 07:04:41


Vicente Botet wrote:
> Frédéric Bron wrote:
> >
> >> Last I agree that the use of equal should be replaced by
> >> assign when assignment is intended
> >> += has_operator_plus_equal -> has_operator_plus_assign
> >> -= has_operator_minus_equal -> has_operator_minus_assign
> >
> > Why? is it to avoid confusion with "equal to"?
> > I like plus_equal because plus is a sign and equal is also
> > a sign. So I think it is easier to remember.
>
> No, it is because the intended behavior on the builtin types
> is to make an assignment. Remember in C++ user defined types
> should follow the builtin semantics when possible.

The "when possible" is a hint that such semantics are not always followed. There are legitimate cases in which a type has no relationship to built-in types, yet overloads operators. In such cases, the built-in semantics don't guide the naming of the operators. For example, the use of the left and right shift operators which, by the way, I never call "bit shift left" and "bit shift right" but just "left shift" and "right shift," are called the insertion and extraction operators in IOStreams. That augurs for naming the traits for the symbols rather than the semantics as Frédéric has done in this case so as to be more general.

The question is whether all of the type traits names consistently follow the symbolic approach. If some are symbolic and others semantic, confusion is more likely.

_____
Rob Stewart robert.stewart_at_[hidden]
Software Engineer using std::disclaimer;
Dev Tools & Components
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