2011/3/24 Stewart, Robert <Robert.Stewart@sig.com>:
Joachim Faulhaber wrote:
Comparing the names I tried to find "Most Unifying Proposals" for names in column MUP:
https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators
The summary table was helpful, Joachim. Thanks.
Names in the standard are certainly appropriate candidates for use in the Type Traits library,
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?
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
Given that Proto uses those names for the operators, there's some precedence for applying them in the traits, but I'd still prefer "addition," "subtraction," "multiplication," and "division"
ahh, a much more consistent naming :)
as the traits names. For brevity, and to more closely match the corresponding concept names, "add," "subtract," "multiply," and "divide" would be acceptable.
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. (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, ...
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. Maybe this mail http://www.mail-archive.com/boost@lists.boost.org/msg07394.html was the cause of their naming and appearance in the new standard. But from a wider perspective of maximizing naming consistency in boost and the standards, I think bitwise_* would be wise ;-) Also it'd be better to implement those functors completely (for all possible operators) and in their most general form e.g. template<class T, class U=T, class R=T> struct a_binary_op; // instead of template<class T>struct a_binary_op; which is in the current proposal.
Editorial comments:
- For others just reading the table, putting "logical_not" with the other "logical_*" entries would be, well, logical
In order to be "most helpful" I chose the sequence found in Frédéric's docs that seem to be odered by arity. In the long run I'd prefer to order according to precedences, which is probably the most useful ordering for users.
- Similarly, putting pre- and post-increment and decrement together would be helpful
- In the legend: s/MPU/MUP/ done.
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 :-/ Thanks Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de