wiki:Guidelines/Naming/Operators

Version 10 (modified by bronf, 12 years ago) ( diff )

--

Operator Names

This page has been created on occasion of the extension of Boost.TypeTraits by operator traits to give an overview over existing naming of operators and related operator-fuctors in the standard and boost libraries. The purpose of the page is to collect differences and support convergence.

Column Comment
op The operator sign
alt An alternative tokens, if available
type_traits boost::type_traits naming as proposed by Frédéric Bron.
MUP Most Unifying Proposal
std = : Equal naming in the standard
=* : Equal naming, new in next standard.
proto = : Equal naming in boost::proto
*_p : Partial equality except for a prefix or postfix
operator Corresponding naming of concepts from boost::operator

The names in column MUP are trying to minimize the differences between names and maximize the naming consistency. The naming from Boost.Proto is found in other boost libraries, e.g. accumulator and phoenix.

op alt type_traits MUP std proto boost::operator proposed new name
== equal_to equal_to = = equality_comparable can_call_operator_equal_to
!= not_eq not_equal_to not_equal_to = = can_call_operator_not_equal_to
< less less = = less_than_comparable can_call_operator_less
<= less_equal less_equal = = can_call_operator_less_equal
> greater greater = = can_call_operator_greater
>= greater_equal greater_equal = = can_call_operator_greater_equal
+ plus plus = = addable can_call_operator_plus
- minus minus = = subtractable can_call_operator_minus
* multiplies multiplies = = multipliable can_call_operator_multiplies
/ divides divides = = dividable can_call_operator_divides
% modulus modulus = = modable can_call_operator_modulus
+= plus_equal plus_assign *_assign can_call_operator_plus_assign
-= minus_equal minus_assign *_assign can_call_operator_minus_assign
*= multiplies_equal multiplies_assign *_assign can_call_operator_multiplies_assign
/= divides_equal divides_assign *_assign can_call_operator_divides_assign
%= modulus_equal modulus_assign *_assign can_call_operator_modulus_assign
&& and logical_and logical_and = = can_call_operator_logical_and
|| or logical_or logical_or = = can_call_operator_logical_or
& bitand bit_and bit_and =* bitwise_* andable can_call_operator_bitwise_and
| bitor bit_or bit_or =* bitwise_* orable can_call_operator_bitwise_or
^ bit_xor bit_xor =* bitwise_* xorable can_call_operator_bitwise_xor
<< left_shift left_shift shift_left left_shiftable can_call_operator_shift_left
>> right_shift right_shift shift_right right_shiftable can_call_operator_shift_right
&= and_eq bit_and_equal bit_and_assign bitwise_and_assign can_call_operator_bitwise_and_assign
|= or_eq bit_or_equal bit_or_assign bitwise_or_assign can_call_operator_bitwise_or_assign
^= xor_eq bit_xor_equal bit_xor_assign bitwise_xor_assign can_call_operator_bitwise_xor_assign
<<= left_shift_equal left_shift_assign shift_left_assign can_call_operator_shift_left_assign
>>= right_shift_equal right_shift_assign shift_right_assign can_call_operator_shift_right_assign
++ prefix_increment pre_increment pre_inc incrementable can_call_operator_pre_increment
-- prefix_decrement pre_decrement pre_dec decrementable can_call_operator_pre_decrement
+ unary_plus unary_plus = can_call_operator_unary_plus
- unary_minus negate negate negate can_call_operator_unary_minus
! not logical_not logical_not = logical_not can_call_operator_logical_not
~ compl complement complement complement can_call_operator_complement
* dereference dereference dereference can_call_operator_dereference
++ postfix_increment post_increment post_inc can_call_operator_post_increment
-- postfix_decrement post_decrement post_dec can_call_operator_post_decrement

There are some conflicts that have been solved under these rationals.

An name is chosen along these priorities

  1. If the name exists in the current c++ standard.
  2. If the name exists in the new upcoming c++ standard.
  3. Name is not given by 1 or 2 but is used in proto
  4. For the remaining conflicts
    1. Does the name follow general boost naming conventions?
    2. Can it be completed to a typical concept name "conceptified". E.g. left_shift -> left_shiftable
o= op_equal vs. op_assign proto and other boost::libs agree on op_assign. We can better conceptify to OpAssignable
bit vs. bitwise bitwise seems to be more "natural" but some naming in the standard prefers bit_ prefix
<< >> shift_xxx or xxx_shift goes to xxx_shift, because we can conceptify to xxx_shiftable more nicely.
++ -- pre/postfix vs. pre/post goes to pre_in/decrement post_in/decrement. Seems simpler and more natural.

A higher naming consistency could be reached, if the standard was changed for 3 names:

// 20.8.7, bitwise operations:
template <class T> struct bit_and;
template <class T> struct bit_or;
template <class T> struct bit_xor;

In this case all the bit prefixes could be replaced by bitwise, so it would be consistent with all proto names referring to bitwise operations. Note that "20.8.7, bitwise operations" are all part of the new upcoming standard and could still be changed.

operator =| |=trait name
+ =| |=can_add<T1, T2>
- =| |=can_subtract<T1, T2>
* =| |=can_multiply<T1, T2>
/ =| |=can_divide<T1, T2>
% =| |=can_modulate<T1, T2>
+= =| |=can_add_assign<T1, T2>
-= =| |=can_subtract_assign<T1, T2>
*= =| |=can_multiply_assign<T1, T2>
/= =| |=can_divide_assign<T1, T2>
%= =| |=can_modulate_assign<T1, T2>
& =| |=can_bitwise_and<T1, T2>
| =| |=can_bitwise_or<T1, T2>
^ =| |=can_bitwise_xor<T1, T2>
&= =| |=can_bitwise_and_assign<T1, T2>
|= =| |=can_bitwise_or_assign<T1, T2>
^= =| |=can_bitwise_xor_assign<T1, T2>
<< =| |=can_left_shift<T1, T2>
>> =| |=can_right_shift<T1, T2>
<<= =| |=can_left_shift_assign<T1, T2>
>>= =| |=can_right_shift_assign<T1, T2>
== =| |=can_call_equal_to<T1, T2>
!= =| |=can_call_not_equal_to<T1, T2>
< =| |=can_call_less<T1, T2>
<= =| |=can_call_less_equal<T1, T2>
> =| |=can_call_greater<T1, T2>
>= =| |=can_call_greater_equal<T1, T2>
&& =| |=can_logical_and<T1, T2>
|| =| |=can_logical_or<T1, T2>
! =| |=can_logical_not<T>
+ =| |=can_unary_plus<T>
- =| |=can_negate<T>
~ =| |=can_complement<T>
* =| |=can_dereference<T>
++ =| |=can_pre_increase<T>
-- =| |=can_pre_decrease<T>
++ =| |=can_post_increase<T>
-- =| |=can_post_decrease<T>
Note: See TracWiki for help on using the wiki.