[Review] Type Traits Extension ending tomorrow
Dear All, The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow. If you plan to submit a review, please do so as soon as possible. Thanks in advance to all participants of the review. =========== What is it? =========== This extension adds 37 new traits corresponding to the following 37 operators: - binary: ==, !=,<,<=,>,>=, , +, -, *, /, %, +=, -=, *=, /=, %=, , &&, ||, ,&, |, ^,<<,>>,&=, |=, ^=,<<=,>>= - prefix: ++, --, +, -, !, ~, * - postfix: ++, -- Each trait can detect if the operator can be used with particular types and if needed, if the return type is convertible to some type. =================== Getting the library =================== The latest version can be downloaded by different ways: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.tar.bz2&directory=Extension& - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits-dos.tar.bz2&directory=Extension& - from the sandbox:http://svn.boost.org/svn/boost/sandbox/type_traits/ The entry point of the documentation is type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html The library has been tested with: - MSVC 8, 9, 10 on Windows, - g++ 4.4.5 on Linux, - intel 10.0 and 11.1 on Linux. To test the library, the simplest is to untar the headers in your boost include directory. For this, you can download the header part of the extension: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.headers_only.tar.bz2&directory=Extension& - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.headers_only-dos.tar.bz2&directory=Extension&
With apologies for the late review - I think the extension to type_traits should be accepted into Boost, it's a needed and useful extension to the existing library. I think the comments to the effect that the default for the return value should be changed from void to "dont_care" or some such type are correct. I'm not much concerned whether it's possible to check for void return types as I can't think of a use for that ;-) Possibly the most controvertial part of the library is the names used for the traits classes - I think the existing names used by Frédéric are consistent, and I would be perfectly happy with them - but I'm not against changing them either if there are better options. I notice there are some non-ASCII characters in the header file copyrights - I can't remember off hand whether we still prohibit that, but I suspect we do (with apologies to all non-English folk!!) I realise this is a bit of a short review, but I can't think of anything else to say at present.... just get 'em in Boost ;-) Regards, John.
On 17/03/2011 14:01, John Maddock wrote:
I'm not much concerned whether it's possible to check for void return types as I can't think of a use for that ;-)
Joining the discussion a bit late... isn't it possible with typeof/decltype? In which case the library should allow it, even if it's not possible on all compilers.
I'm not much concerned whether it's possible to check for void return types as I can't think of a use for that ;-)
Joining the discussion a bit late... isn't it possible with typeof/decltype? In which case the library should allow it, even if it's not possible on all compilers.
Good catch - use decltype to get the return type and pass to is_convertible. Of course it complicates the implementation.... John.
I think the comments to the effect that the default for the return value should be changed from void to "dont_care" or some such type are correct. I'm not much concerned whether it's possible to check for void return types as I can't think of a use for that ;-)
If we use "dont_care" instead of "void", we must do something when "void" is used. So to me it means that we have the following choice: 1. default=void -> do not check 2. default=dont_check, void -> check for void return
I notice there are some non-ASCII characters in the header file copyrights - I can't remember off hand whether we still prohibit that, but I suspect we do (with apologies to all non-English folk!!)
I can change that... Frédéric
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Frédéric Bron Sent: Thursday, March 17, 2011 5:08 PM To: boost@lists.boost.org Cc: John Maddock Subject: Re: [boost] [Review] Type Traits Extension ending tomorrow
I notice there are some non-ASCII characters in the header file copyrights - I can't remember off hand whether we still prohibit that, but I suspect we do (with apologies to all non-English folk!!)
As I recall, it is the C++ Standard that prohibits it, but some compilers ignore it (but MSVC warns). But it definitely causes trouble downstream with Quickbook, Bookbook ... toolchain, (and is very difficult to diagnose why it won't build the docs as I recall from referencing Monsieur Bezier ;-) so definitely no proper accents on your names or comments in header files. Sorry! Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
A short review. I used the library on Mac OS X in both clang and g++. The code appears to work fine after one small bug/confusion was fixed. The library is generally complete and functions well. My one request would be for an example or two! I wrote (for my own uses) a "maybe_print" function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". I think a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method. I believe the library should be accepted. On 17 Mar 2011, at 06:11, Joel Falcou wrote:
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow. If you plan to submit a review, please do so as soon as possible.
Thanks in advance to all participants of the review.
=========== What is it? ===========
This extension adds 37 new traits corresponding to the following 37 operators: - binary: ==, !=,<,<=,>,>=, , +, -, *, /, %, +=, -=, *=, /=, %=, , &&, ||, ,&, |, ^,<<,>>,&=, |=, ^=,<<=,>>= - prefix: ++, --, +, -, !, ~, * - postfix: ++, --
Each trait can detect if the operator can be used with particular types and if needed, if the return type is convertible to some type.
=================== Getting the library ===================
The latest version can be downloaded by different ways: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.tar.bz2&directory=Extension& - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits-dos.tar.bz2&directory=Extension& - from the sandbox:http://svn.boost.org/svn/boost/sandbox/type_traits/
The entry point of the documentation is type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html
The library has been tested with: - MSVC 8, 9, 10 on Windows, - g++ 4.4.5 on Linux, - intel 10.0 and 11.1 on Linux.
To test the library, the simplest is to untar the headers in your boost include directory. For this, you can download the header part of the extension: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.headers_only.tar.bz2&directory=Extension& - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_traits.headers_only-dos.tar.bz2&directory=Extension& _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Joel Falcou-3 wrote:
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow.
Hi, I really think that this extension must be accepted in Boost. I would expect that the default void RET type change to a more significant don't_check tag. I have already given my naming preferences, but I will live with the the one chosen. The documentation is simple and concise. Some basic example as proposed by others will be welcome. After inspecting the implementation, I find it quite good. Some renaming could make it more clear. Rename the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that. Good work Frédéric, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Type-Traits-Extension-ending-tomor... Sent from the Boost - Dev mailing list archive at Nabble.com.
2011/3/17 Joel Falcou <joel.falcou@lri.fr>:
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow. If you plan to submit a review, please do so as soon as possible.
Dear Joel, Frédéric, list, I am clearly *in favor* of this extension (BTW what would be the precise name for it?). I had fun evaluating it and trying a few experiments. Alas as a result of those and the discussion on the list, I reached a point where I feel I need some more time and I'd like to see some more discussion on a point that I'd like to highlight: Naming (1) has_operator_xxx seems to be imprecise and misleading. (2) has_operator_xxx introduces a redundant prefix 'has_operator' that IMO is unnecessary (3) If there are close relationships between Concepts and operator traits their names should express this relation as well. My current proposal is: plus_assign_callable or even better plus_assingable instead of has_operator_plus_assign PlusAssignable Name for the concept (I'm aware of: http://www.boost.org/doc/libs/1_46_1/libs/utility/operators.htm#less_than_co... for potential name clashes though.) I'd like to elaborate more on my ideas on naming, but today I won't have time. Therefore I'd like to ask for extension of the review until Monday 03-21. If a general extension is not possible I request an extension for the submission for my review. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow. If you plan to submit a review, please do so as soon as possible.
I am clearly *in favor* of this extension (BTW what would be the precise name for it?). I had fun evaluating it and trying a few experiments. Alas as a result of those and the discussion on the list, I reached a point where I feel I need some more time and I'd like to see some more discussion on a point that I'd like to highlight:
Naming
(1) has_operator_xxx seems to be imprecise and misleading.
How so? Personally I like the idea of a common prefix for all of these.
(2) has_operator_xxx introduces a redundant prefix 'has_operator' that IMO is unnecessary
Maybe, but it makes it explicit what you're testing, and puts all the operator traits together in the alphabetical index - a small point I know, but it is useful none the less!
(3) If there are close relationships between Concepts and operator traits their names should express this relation as well.
My current proposal is:
plus_assign_callable or even better plus_assingable instead of has_operator_plus_assign
I'd prefer is_plus_assignable if we go that route. John.
I'd prefer is_plus_assignable if we go that route.
is_ or are_... Some time ago before this review, we had a long discussion about names and there was also the possibility to use namespace as replacement of common prefix. However I think this should be done for the entire type trait library, not only the extension so that it should be a next step if it is believed to be interesting. Frédéric
Some time ago before this review, we had a long discussion about names and there was also the possibility to use namespace as replacement of common prefix. However I think this should be done for the entire type trait library, not only the extension so that it should be a next step if it is believed to be interesting.
Right or wrong the current naming convention is part of the next standard now, lets not get too creative here, please ;-) John.
2011/3/18 Frédéric Bron <frederic.bron@m4x.org>:
I'd prefer is_plus_assignable if we go that route.
is_ or are_...
good point ;) I think is_ because (1) We can think of the triple <T,U,R> of types that plus_assign *is* applicable on. (2) Each of those operations assigned to an operator can be decomposed is_plus_assignable<T,U,R> U *is* combinable to T and then the result *is* assignable to R
Some time ago before this review, we had a long discussion about names and there was also the possibility to use namespace as replacement of common prefix. However I think this should be done for the entire type trait library,
hmm, I don't think this is an option. We would break existing code.
not only the extension so that it should be a next step if it is believed to be interesting.
once published as official boost library it's too late to change the naming. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
John Maddock wrote:
(1) has_operator_xxx seems to be imprecise and misleading.
How so? Personally I like the idea of a common prefix for all of these.
The intention is that "has_operator_xxx" be read as "expressions involving these two types can use operator xxx." The types needn't "have" such an operator where "have" suggests membership, that the operator is a member of a type. A common prefix doesn't have to be common for all type traits. There are already "add_," "has_," "is_," "make_," and "remove_" common prefixes. Note also that those beginning with "has_" refer to properties of types. These new traits do not.
(2) has_operator_xxx introduces a redundant prefix 'has_operator' that IMO is unnecessary
Maybe, but it makes it explicit what you're testing, and puts all the operator traits together in the alphabetical index - a small point I know, but it is useful none the less!
That's actually a good argument against using "has_" because you *don't* want these new traits grouped with the existing "has_" traits.
(3) If there are close relationships between Concepts and operator traits their names should express this relation as well.
My current proposal is:
plus_assign_callable or even better plus_assingable instead of has_operator_plus_assign
I'd prefer is_plus_assignable if we go that route.
is_add_assignable (The operation is addition followed by assignment, not plus followed by assignment.) _____ Rob Stewart robert.stewart@sig.com 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.
John Maddock wrote:
I'd prefer is_plus_assignable if we go that route.
is_add_assignable
(The operation is addition followed by assignment, not plus followed by assignment.)
How do you pronounce C++ ? ;-)
If you're going that route, then it's is_plus_equal-able, not is_plus_assignable! However, += is the add-and-assign operator, even if you might read the symbol aloud as plus-equal. For grins, I consulted _C: A Reference Manual_ by Harbison and Steele, an old C book I have on my shelf. They use these names (in the index only): += assign sum -= assign difference *= assign product /= assign quotient That would lead to traits names like these: can_assign_sum can_assign_difference can_assign_product can_assign_quotient TCPL uses the following names: += add and assign -= subtract and assign *= multiply and assign /= divide and assign That leads, of course to names like these: can_add_and_assign can_subtract_and_assign can_multiply_and_assign can_divide_and_assign Those names don't match the concept names, as Joachim suggested, but they read well. _____ Rob Stewart robert.stewart@sig.com 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.
Stewart, Robert wrote:
John Maddock wrote:
I'd prefer is_plus_assignable if we go that route.
is_add_assignable
(The operation is addition followed by assignment, not plus followed by assignment.)
How do you pronounce C++ ? ;-)
If you're going that route, then it's is_plus_equal-able, not is_plus_assignable!
However, += is the add-and-assign operator, even if you might read the symbol aloud as plus-equal.
TCPL uses the following names:
+= add and assign -= subtract and assign *= multiply and assign /= divide and assign
That leads, of course to names like these:
can_add_and_assign can_subtract_and_assign can_multiply_and_assign can_divide_and_assign
Those names don't match the concept names, as Joachim suggested, but they read well.
Hi, I like the can_ prefix but I would remove the and as it could be interpreted as can add can assign. can_add can_assign can_multiply can_post_increase can_left_shift ... can_add_assign can_subtract_assign can_multiply_assign can_divide_assign The same pattern can be used for member functions: can_VERB? We could reserve the has for data or nested type members: has_NOUN? The single problem I see with this traits is that they don't follows the existing naming (see 20.9.4.3) as for example: template <class T, class... struct is_constructible; template <class T, class U> struct is_assignable; template struct has_virtual_destructor; So if we follow this pattern we should name it is_addable is_add_assignable is_post_incrementable Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/Review-Type-Traits-Extension-ending-tomor... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 3/18/2011 1:00 PM, John Maddock wrote:
I'd prefer is_plus_assignable if we go that route.
is_add_assignable
(The operation is addition followed by assignment, not plus followed by assignment.)
How do you pronounce C++ ? ;-)
Do you mean 'caddadd' ? Let me calculate that on my plussing machine <g><g>.
2011/3/18 Stewart, Robert <Robert.Stewart@sig.com>:
John Maddock wrote:
(1) has_operator_xxx seems to be imprecise and misleading.
How so? Personally I like the idea of a common prefix for all of these.
The intention is that "has_operator_xxx" be read as "expressions involving these two types can use operator xxx." The types needn't "have" such an operator where "have" suggests membership, that the operator is a member of a type.
+1
A common prefix doesn't have to be common for all type traits. There are already "add_," "has_," "is_," "make_," and "remove_" common prefixes. Note also that those beginning with "has_" refer to properties of types. These new traits do not.
(2) has_operator_xxx introduces a redundant prefix 'has_operator' that IMO is unnecessary
Maybe, but it makes it explicit what you're testing, and puts all the operator traits together in the alphabetical index - a small point I know, but it is useful none the less!
That's actually a good argument against using "has_" because you *don't* want these new traits grouped with the existing "has_" traits.
+1
(3) If there are close relationships between Concepts and operator traits their names should express this relation as well.
My current proposal is:
plus_assign_callable or even better plus_assignable instead of has_operator_plus_assign
I'd prefer is_plus_assignable if we go that route.
is_add_assignable
(The operation is addition followed by assignment, not plus followed by assignment.)
I think there is another naming problem lurking here ;-) which I would call: "Inadequate levels of abstraction" applied. Unfortunately this naming flaw is already applied to names that are part of the existing standard and in other boost libraries so I am afraid we will have to live with them. The basic problem here: Operators are atomic syntactical entities. The language allows to attach arbitrary semantics to them by implementing some behavior for them, except for the built in types, of course. But the names used to refer to them does not refer to their syntax but to the most common semantics attached to them. It would have been wiser to deliberately choose names for operators that referred to syntax, in order to emphasize that semantics vary an is attachable to the syntax. sign semantics + cross addition, set union, concatenation, ... - dash subtraction, set difference, deletion ... * star multiplication, intersection, ... / slash division, factorization, ... which is not always easy since even in natural language basic operations and names operator signes are intermingled (+ plus sign, = equal sign). Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
2011/3/18 John Maddock <boost.regex@virgin.net>:
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow. If you plan to submit a review, please do so as soon as possible.
I am clearly *in favor* of this extension (BTW what would be the precise name for it?). I had fun evaluating it and trying a few experiments. Alas as a result of those and the discussion on the list, I reached a point where I feel I need some more time and I'd like to see some more discussion on a point that I'd like to highlight:
Naming
(1) has_operator_xxx seems to be imprecise and misleading.
How so? Personally I like the idea of a common prefix for all of these.
(1.1) In contrast to, say, has_nothrow_assign<T>, that informs us about the existence of an operator or trait that belongs to the type T, has_operator_multiplies<T,U,R> may refer to a free standing operator, that *is designed* not to belong to a single type in many instances. If we take e.g. has_operator_multiplies<line, polygon, point_set> // BTW multiplies is misleading here as well which one of the types <line, polygon, point_set> "has" operator_multiplies? The question becomes more awkward, if we consider the universe of all the overloads that are already possible for operator * in the context of boost now and even more so in the future. (1.2) The name has_operator_xxx misleads to the assumption, that the signature of an operator can be checked directly. At least naive users (like me;) may fall into this trap.
(2) has_operator_xxx introduces a redundant prefix 'has_operator' that IMO is unnecessary
Maybe, but it makes it explicit what you're testing, and puts all the operator traits together in the alphabetical index - a small point I know, but it is useful none the less!
on the other hand, operator names are already standardized names that can stand for themselves such that a "reminder-prefix" "operator_" for operator_plus_assign is not needed. In contrast, we introduce redundancy: has_operator_plus has_operator_minus has_operator_divides In the example above over 70% of naming information is redundant ;)
(3) If there are close relationships between Concepts and operator traits their names should express this relation as well.
My current proposal is:
plus_assign_callable or even better plus_assignable instead of has_operator_plus_assign
I'd prefer is_plus_assignable if we go that route.
+1 is_ is the "natural" prefix for (meta)predicates. At the same time a good remedy for name clashes with Boost.Operator. I am sorry if I'm bugging everyone with yet another naming debate, but I think that naming is very important in library development in general and in the field of language operators in particular. Operators are at the heart of a programming language. Invariant pieces of syntax that tend to "attract" archetypal semantics. Since we are influencing and even creating standards in boost we should be choosing names in the operator area very carefully. My criteria for name selection here are roughly these: (1) Consistency with general math and scientific knowledge (2) Consistency with standards (2.1) Consistency with c++ standards (2.2) Consistency with boost (2.3) Consistency with other standards, if they exist (3) Conciseness (3.1) Precise and descriptive (3.2) Adequate level of abstraction (3.3) Reduced for unnecessary redundancies (3.4) Relatedness to other names with similar meanings. Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
I'd like to elaborate more on my ideas on naming, but today I won't have time. Therefore I'd like to ask for extension of the review until Monday 03-21. If a general extension is not possible I request an extension for the submission for my review.
I have no issue with that. Frédéric
2011/3/18 Joachim Faulhaber <afojgo@googlemail.com>
2011/3/17 Joel Falcou <joel.falcou@lri.fr>:
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow.
... but today I won't have time. Therefore I'd like to ask for extension of the review until Monday 03-21. If a general extension is not possible I request an extension for the submission for my review.
Dear Joel, Frédéric, list, this in my review Frédéric Bron's extensions to the Type Traits library. The type_traits extensions by Frederic Bron seem to be a useful and welcome tool for meta programming purposes that is particularly handy in the context of generic library programming. I vote for ACCEPTANCE of the extension into boost. There is only on issue (1) that I consider a conditional (kind'a cosmetic though): (1) Template parameter Identifiers are lower case except for the first letter. This is official boost policy. Only BOOST_MACROS are completely upper case. So: template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;) All other points (2-6) are proposals, ordered by my personal priorities: (2) Concise and consistent naming. (2.1) I have started a wiki page with a list of names for operators and their functors in the wiki, that tries to focus on consistency and convergence of names across the standard and boost. https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators It contains a few modifications of the names proposed by Frédéric. (2.2) While xxx_is_callable or is_xxxable might be slightly more precise names, I think I can also live with has_xxx. (2.3) I'd prefer has_xxx over has_operator_xxx because I think that operator names xxx can stand for themselves without an "operator_ reminder" prefix. The has_operator_ prefix is lengthy and introduces unnecessary redundancy. (3) Motivation and examples. One of the most important tasks for boost authors and boost as a whole is the communication of the motivation, purpose and usefulness of their innovations. I am repeatedly amazed how many developers find boost kind of freaked out and beyond the needs of "daily" software development. Part of the problem is that boost authors tend to take the beauty of their inventions as self-evident and do not see the need to communicate the key ideas and benefits of their work. So IMO the documentations lacks a concise and convincing motivation of why we want operator trait meta functions and some good examples that demonstrate important use cases. (4) For the include file that includes all has_operator meta functions I propose to use type_traits/has_operator.hpp instead of type_traits/operators.hpp That would be more consistent with the has_xxx.hpp file names and also more precise. I'd leave operators.hpp free for usage on -- well -- operators. (5) Since the arguments of has_xxx<T1, T2, R> are not matched exactly but in their "convertible form", there should be a chapter in the docs explaining these rules and the consequences for practical use, similar to the nice and clear explanations given on the list. (6) I'd be nicer if we had quickbook docs, but as Frédéric has pointed out he integrates into the the prevailing style of the "mother library". Still it may be nice to take the opporunity to update the whole type traits docs to quickbook style. But this is a lot of work of course and goes beyond the scope of the extension. Thanks again, Frédéric, for a smart piece of boost software. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On 21.03.2011 13:43, Joachim Faulhaber wrote:
(1) Template parameter Identifiers are lower case except for the first letter. This is official boost policy. Only BOOST_MACROS are completely upper case. So:
template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;)
agree. I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :)) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
On 21.03.2011 13:43, Joachim Faulhaber wrote:
(1) Template parameter Identifiers are lower case except for the first letter. This is official boost policy. Only BOOST_MACROS are completely upper case. So:
template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;)
agree.
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :))
Is that because they're initialisms rather than actual words, or because the vestigial term 'hand' carries no information? Josh
On 21.03.2011 15:16, Joshua Juran wrote:
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :) )
Is that because they're initialisms rather than actual words, or because the vestigial term 'hand' carries no information?
all these reasons, but yet lhs/rhs are too indistinguishable letter sets. (They differ in one letter only) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :) )
Personally, I like it very much as it describes very well the arguments. And yes it comes from the books of Scott Meyers which I found outstanding... Frédéric
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
On 21.03.2011 13:43, Joachim Faulhaber wrote:
(1) Template parameter Identifiers are lower case except for the first
letter. This is official boost policy. Only BOOST_MACROS are
completely upper case. So:
template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;)
agree.
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :))
How curious... despite all their demonstrable short comings (similarity, redundancy, etc), I think that pair of identifiers are some of the best, most instantly recognisable and understandable identifiers ever coined! Each to their own I guess. - Rob.
On Mon, Mar 21, 2011 at 6:10 AM, Robert Jones <robertgbjones@gmail.com> wrote:
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
On 21.03.2011 13:43, Joachim Faulhaber wrote:
(1) Template parameter Identifiers are lower case except for the first
letter. This is official boost policy. Only BOOST_MACROS are
completely upper case. So:
template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;)
agree.
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :))
How curious... despite all their demonstrable short comings (similarity, redundancy, etc), I think that pair of identifiers are some of the best, most instantly recognisable and understandable identifiers ever coined!
+1.
Each to their own I guess.
I would go further: it's a mistake to break with a well-established convention that works just on principle. The chance that your alternative will work better in practice is extremely low. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2011/3/21 Dave Abrahams <dave@boostpro.com>:
On Mon, Mar 21, 2011 at 6:10 AM, Robert Jones <robertgbjones@gmail.com> wrote:
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
On 21.03.2011 13:43, Joachim Faulhaber wrote:
(1) Template parameter Identifiers are lower case except for the first
letter. This is official boost policy. Only BOOST_MACROS are
completely upper case. So:
template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;)
agree.
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :))
How curious... despite all their demonstrable short comings (similarity, redundancy, etc), I think that pair of identifiers are some of the best, most instantly recognisable and understandable identifiers ever coined!
+1.
Each to their own I guess.
I would go further: it's a mistake to break with a well-established convention that works just on principle. The chance that your alternative will work better in practice is extremely low.
My original point was not about lhs/rhs love or hate but about boost naming conventions on template parameters, which I think are well established in boost libraries. This from http://www.boost.org/development/requirements.html#Naming_consistency Use the naming conventions of the C++ Standard Library (See Naming conventions rationale): * Names (except as noted below) should be all lowercase, with words separated by underscores. * Template parameter names begin with an uppercase letter. * Macro (gasp!) names all uppercase and begin with BOOST_. As for LHS/RHS usage as template parameters in current boost libraries a grep on trunk/boost shows 'LHS' is used on 5 lines 'Lhs' is used on 10 lines 'Left' is used on 297 lines The boost web page says in addition: * Once a library settles on a particular convention, a vast majority of stakeholders want that style to be consistently used. that's what I hope for ;) Regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
On 22.03.2011 2:36, Joachim Faulhaber wrote:
My original point was not about lhs/rhs love or hate but about boost naming conventions on template parameters, which I think are well established in boost libraries.
i am aware that your motives differ from mine ;) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On 21.03.2011 21:06, Dave Abrahams wrote:
it's a mistake to break with a well-established convention that works just on principle. The chance that your alternative will work better in practice is extremely low.
I think that preference in /*hs/ names is some sort of (old) harmful habit, we must go away from this naming style. 50 years ago GOTO statement also were considered as excellent programming instrument. (progress isn't stayed) Even if my naming convention isn't sufficient, this is not means that yours is good enough :) to use it (In general, we must formulate a new naming convention for binary operator arguments.) -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
Max Sobolev wrote:
On 21.03.2011 21:06, Dave Abrahams wrote:
it's a mistake to break with a well-established convention that works just on principle. The chance that your alternative will work better in practice is extremely low.
I think that preference in /*hs/ names is some sort of (old) harmful habit, we must go away from this naming style. 50 years ago GOTO statement also were considered as excellent programming instrument. (progress isn't stayed)
There is nothing remotely harmful in "lhs" or "rhs."
Even if my naming convention isn't sufficient, this is not means that yours is good enough :) to use it (In general, we must formulate a new naming convention for binary operator arguments.)
No, we mustn't. You may prefer to see it happen, but there's no "must" here. This may well be a language barrier, but I find "left hand side" and "right hand side" to be precisely the right names for the expressions surrounding a binary operator and "lhs" and "rhs" to be perfectly recognizable and readable abbreviations for those names. Other names, like "left" and "right" are not sufficiently descriptive; they don't quite connote the idea of things to the left and right side of a third thing. However, "left" and "right" could supplant "lhs" and "rhs" if they were used often enough. _____ Rob Stewart robert.stewart@sig.com 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.
Stewart, Robert wrote:
Max Sobolev wrote:
it's a mistake to break with a well-established convention that works just on principle. The chance that your alternative will work better in practice is extremely low. I think that preference in /*hs/ names is some sort of (old) harmful habit, we must go away from this naming style. 50 years ago GOTO statement also were considered as excellent
On 21.03.2011 21:06, Dave Abrahams wrote: programming instrument. (progress isn't stayed)
There is nothing remotely harmful in "lhs" or "rhs."
Even if my naming convention isn't sufficient, this is not means that yours is good enough :) to use it (In general, we must formulate a new naming convention for binary operator arguments.)
No, we mustn't. You may prefer to see it happen, but there's no "must" here.
This may well be a language barrier, but I find "left hand side" and "right hand side" to be precisely the right names for the expressions surrounding a binary operator and "lhs" and "rhs" to be perfectly recognizable and readable abbreviations for those names.
+1 IIRC, these terms were well defined and used in basic linear algebra and numerical methods college courses. Jeff
On 21.03.2011 16:10, Robert Jones wrote:
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :))
How curious... despite all their demonstrable short comings (similarity, redundancy, etc), I think that pair of identifiers are some of the best, most instantly recognisable and understandable identifiers ever coined! Each to their own I guess.
it's fine for asm, ........but in C++ we probably should write: Type operator + (Type const& left_hand_side, Type const& right_hand_side) { . . . } (So far I don't confide that "left hand side" is a right decryption for /lhs/) These argument names are too verbose and /_hand_side/ prefixes are redundant here. We've got: Type operator + (Type const& left, Type const& right) { . . . } left/right are too simple :( but not horrible names. Articulation of /lhs/ and /rhs/ is much longer then /left/ and /right/ words, because former consists of 3 syllables (l - h - s), and later consists of 1 only. i use left/right argument names for binary operators as free functions, and /other/ for unary member functions (+ cctor) with an argument of class type (This later is a boost convention). -- - Do you speak English? Мужик с глубоким вздохом: - Yes I do. А хули толку?
On Mar 22, 2011, at 7:15 AM, Max Sobolev wrote:
On 21.03.2011 16:10, Robert Jones wrote:
On Mar 21, 2011, at 4:52 AM, Max Sobolev wrote:
I /hate/ lhs/rhs identifiers :( (despite my respect to people that use it (Scott Meyers etc.) :))
How curious... despite all their demonstrable short comings (similarity, redundancy, etc), I think that pair of identifiers are some of the best, most instantly recognisable and understandable identifiers ever coined! Each to their own I guess.
it's fine for asm, ........but in C++ we probably should write:
I don't see why asm needs shorter identifiers. On the contrary, assembly instructions tend to be very brief, in contrast to C++ statements whose readability sometimes improves with shorter identifier names.
Type operator + (Type const& left_hand_side, Type const& right_hand_side) { . . . }
No, this is worse than 'lhs' and 'rhs'. The two abbreviations are easily recognized for what they are (even if distinguishing one from the other takes some thought) but the spelled-out terms one must read and interpret, only to realize they mean nothing (other than to state what position they appear in). For the same reason, I always write loop indices as 'i', not 'index', and especially not 'widget_index' -- any information provided only serves to distract.
(So far I don't confide that "left hand side" is a right decryption for /lhs/)
I'm quite certain that's the phrase which 'lhs' abbreviates. I suppose children have an easier time learning left from right if they use their body parts as cognitive training wheels instead of dealing directly with abstract concepts. Adults don't need such devices, but 'ls' and 'rs' would be worse identifiers (with the 's' still being redundant). I think of 'r' as meaning 'radius', and 'l' is just asking for trouble because it's so similar to '1'.
Type operator + (Type const& left, Type const& right) { . . . }
I associate left and right with graphics systems.
left/right are too simple :( but not horrible names. Articulation of /lhs/ and /rhs/ is much longer then /left/ and /right/ words, because former consists of 3 syllables (l - h - s), and later consists of 1 only.
I use 'a' and 'b'. They're each one character and one syllable, and it's obvious without thinking which order they go in. And they don't look like they might mean something more than they actually do. inline bool operator<=( const Foo& a, const Foo& b ) { return !(b < a); } This is similar to Perl's use of $a and $b as the parameters to sort callbacks.
i use left/right argument names for binary operators as free functions, and /other/ for unary member functions (+ cctor) with an argument of class type (This later is a boost convention).
I use 'other' in the same way. Josh
Joshua Juran wrote:
On Mar 22, 2011, at 7:15 AM, Max Sobolev wrote:
(...)
I don't see why asm needs shorter identifiers. On the contrary, assembly instructions tend to be very brief, in contrast to C++ statements whose readability sometimes improves with shorter identifier names.
+1
Type operator + (Type const& left_hand_side, Type const& right_hand_side) { . . . }
No, this is worse than 'lhs' and 'rhs'. The two abbreviations are easily recognized for what they are (even if distinguishing one from the other takes some thought) but the spelled-out terms one must read and interpret, only to realize they mean nothing (other than to state what position they appear in). For the same reason, I always write loop indices as 'i', not 'index', and especially not 'widget_index' -- any information provided only serves to distract.
+1
left/right are too simple :( but not horrible names. Articulation of /lhs/ and /rhs/ is much longer then /left/ and /right/ words, because former consists of 3 syllables (l - h - s), and later consists of 1 only.
I use 'a' and 'b'. They're each one character and one syllable, and it's obvious without thinking which order they go in. And they don't look like they might mean something more than they actually do.
inline bool operator<=( const Foo& a, const Foo& b ) { return !(b < a); }
-1 ;-) I think the words "left" and "right" are short enough in this case, and they do mean something because operators like <= treat their operands asymmetrically. You distinguish these words for the same reason that you distinguish "first" and "last" in the parameter list of a function that works on sequences. This discussion has drifted quite far, hasn't it? -Julian
(2.3) I'd prefer has_xxx over has_operator_xxx because I think that operator names xxx can stand for themselves without an "operator_ reminder" prefix. The has_operator_ prefix is lengthy and introduces unnecessary redundancy.
Hmm, I'm not sure it is completely redundant - I prefer long_descriptive_names to short_cute_ones because it makes the code easier to understand - even though it result in a touch more typing.
(6) I'd be nicer if we had quickbook docs, but as Frédéric has pointed out he integrates into the the prevailing style of the "mother library". Still it may be nice to take the opporunity to update the whole type traits docs to quickbook style. But this is a lot of work of course and goes beyond the scope of the extension.
FYI All the type_traits docs are in quickbook format already, it may not be obvious though if the sandbox versions aren't picking up the usual stylesheets. John.
2011/3/21 John Maddock <boost.regex@virgin.net>:
(2.3) I'd prefer has_xxx over has_operator_xxx because I think that operator names xxx can stand for themselves without an "operator_ reminder" prefix. The has_operator_ prefix is lengthy and introduces unnecessary redundancy.
Hmm, I'm not sure it is completely redundant - I prefer long_descriptive_names to short_cute_ones because it makes the code easier to understand - even though it result in a touch more typing.
There may be conflicting principles e.g. descriptiveness, ease of perception versus conciseness, simplicity and naming decisions may vary between them. (2.3.1) In my view a naming style of systematic pre or postfixes may lead to reduced readability, due to induced redundancy that clutters code. My favorite example is the use of pre/suffix "type" both in c++ language design as well as in well known naming conventions (std/boost). I think (1) is less readable than (2): // "type" is used 5 times as pre or suffix (1) typedef typename foo_type::key_type mykey_type; // instead of (2) type mykey = foo::key; (2.3.2) In addition, if say 'plus' is a functor that wraps operator '+' in the standard's <functional> header, would we want to name it template<class T> struct functor_for_operator_plus; //? Many aspects about a name in a program are given by its context. I think it is an unnecessary introduction of verbosity and redundancy often, to repeat information as part of a name that is already clear by its context. This is what I mean when I talk about a reminder prefix. string x_str; // suffix str redundant. Clear from the context. The context for std::plus is: * There is a set of very important function symbols called operators. * For those core symbols there are uniformly usable functors that wrap the operators. * From this it is clear that all those functor classes are functor_for_operator_xxx So functor_for_operator_ does not have to repeated as component of all those names. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
participants (16)
-
Christopher Jefferson -
Dave Abrahams -
Edward Diener -
Frédéric Bron -
Jeff Flinn -
Joachim Faulhaber -
Joel Falcou -
John Maddock -
Joshua Juran -
Julian Gonggrijp -
Mathias Gaunard -
Max Sobolev -
Paul A. Bristow -
Robert Jones -
Stewart, Robert -
Vicente Botet