Subject: Re: [boost] review request: addition to type_traits library ofhas_operator_xxx
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2010-11-22 10:01:35
Stewart, Robert wrote:
> Jeff Flinn wrote:
>> Also given the growth of EDSL's and operator overloading in
>> general are these names too domain specific? For example
>> boost::filesystem overloads operator/ for concatenating a
>> path: p / "file.txt".
>>
>> Has thought been given to more agnostic names such as:
>>
>> has_operator_star
>> has_operator_slash
>> has_operator_plus
>> has_operator_minus
>> ...
>
> That's an interesting idea, but standardized names for the characters would be necessary. "Star" is colloquial; "asterisk" is more appropriate. Instead of "minus," "hyphen" seems more correct and what about the unary versus binary overloads? Here's a longer list to consider:
>
> has_operator_hyphen_unary
> has_operator_hyphen_binary
> has_operator_tilde
> has_operator_exclamation
> has_operator_percent
> has_operator_caret (not "circumflex" which is a diacritical)
> has_operator_ampersand
> has_operator_asterisk
> has_operator_pipe
> has_operator_left_guillemet?
> has_operator_right_guillemet?
>
> Since the guillemets are real characters, and the C++ operators are formed by two characters parsed as one token, using "guillemet" isn't correct. One could also use "chevron" which are sometimes doubled to represent guillemets, but the less-than and greater-than characters are not chevrons. Calling them "left shift" and "right shift" brings one full circle to naming the operators for the operations they represent on built-in types, while "insertion" and "extraction" are related to their use with IOStreams. I don't know what to call those.
>
> The contrary view to what you've suggested is to note in the documentation that the operators are named for their use with built-in types and leave it at that.
This latter approach is probably sufficient, as it merely explicitly
states what has been implied all along.
Jeff