Boost logo

Boost :

Subject: Re: [boost] [type_traits] Most Unifying Proposal for operator names Was: Review Typetraits Extension.
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-24 12:48:33


Joachim Faulhaber wrote:
> 2011/3/24 Stewart, Robert <Robert.Stewart_at_[hidden]>:
>
> > even if I would rather the standard's names were different.
>
> [Non native speaker questions] Is this expression colloquial? Does it
> mean you wish the standard's names were different?

The use of "rather" versus "prefer" in that context is, probably, colloquial, perhaps even antiquated (I read a lot written by the likes of Dickens, Austen, etc.).

> > I have some quibbles with your MUP choices, though.
> > For example, you cite std::plus, minus, multiplies, and divides
> > as naming examples from the standard,
>
> I was thinking about you, when I saw them, they're pretty
> inconsistent, aren't they?
>
> > yet those are the names of function objects, not of operators.
>
> true

This is, in my mind, a significant point which you overlook below.

[snip "addition," etc. and "add," etc.]

> I agree these names are nicer as those chosen by the standard
> and proto ...
>
> Still
>
> (1) I would prefer uniformity over improvement here. I think it is of
> greater value, if we manage to converge names in boost and the
> standard, specifically in fields that are very fundamental to c++ as a
> language, which is clearly the case here.

It isn't uniformity when they name different things. Indeed, I consider using the same names for different things to be confusing.

> (2) If we considered to choose new names, I'd clearly prefer names
> that emphasize on syntax, to make clear that semantics is attached to
> operators by implementation
>
> sign semantics
> + cross addition, set union, concatenation, ...
> - dash subtraction, set difference, deletion ...
> * star multiplication, intersection, Cartesian product ...
> / slash division, factorization, ...

I'd never think of "cross" for "+". It has always been a "plus sign" to me. You also have the problem of "*" being "asterisk" and "-" being "hyphen" to different people. Besides, what would you call the corresponding concepts? IsDashable? IsStarable?

> > Similarly, you used the function objects from the C++0x
> > standard as the basis to justify "bit_and," "bit_or," and "bit_xor."
> > Proto uses the better "bitwise_*" forms for the operators.
>
> Those three are a proposed addition to the new upcoming standard, all
> the others are in the current standard already.

It doesn't matter because, again, they are names for different things.

> But from a wider perspective of maximizing naming consistency in boost
> and the standards, I think bitwise_* would be wise ;-)

Certainly, though conforming to names in the standard is wiser when they apply. That is, Boost should conform to the standard when reasonable.

> Also it'd be better to implement those functors completely (for all
> possible operators) and in their most general form e.g.

Unrelated to naming the operators, I think.

> If we can reach an agreement among boosters quickly we might be able
> to influence the standard now. Otherwise we'd have to wait for another
> decade :-/

One can always dream.

_____
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