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