Hi Steven! I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set? Markus
AMDG On 07/22/2012 07:21 AM, Markus Werle wrote:
Hi Steven!
I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set?
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
[*slightly* off-topic: Does that mean Ad maiorem Dei gloriam?]
On 07/22/2012 07:21 AM, Markus Werle wrote:
Hi Steven!
I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set?
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/... I disagree with this decision. You write:
An earlier version of the library used the names _1, _2, etc. instead of _a, _b, etc. This caused a certain amount of confusion because the numbered placeholders are already used by several other libraries including Boost/Std Bind, Boost.Phoenix, and Boost.MPL.
IMHO the introduction of another set of placeholders is more confusing. If we are to discriminate here, we can do it via namespaces - and of course one day it is std::_1 for all of us. Just because your library is the first to use _a, _b, _c what does that mean for future (boost) libraries that use some kind of placeholders? Do they have to use _aa, _bb, etc.? To me placeholders are such a natural concept I do not care about having some kind of "deja vu" here. To the contrary: The meaning (placeholder) is identical so we should use identical names.
I eventually decided that since the placeholders represented named parameters instead of positional parameters, letters were more appropriate than numbers.
Indeed the naming is arbitrary. Starting from the same observation (_1 is already available in boost::*) I draw the opposite conclusion: Use these names for the sake of symmetry and hope for convergence of concepts over the years. @Review Master: Should I miss the end date for reviews, take this as my mini subset of a review: I'd prefer _1, _2 instead of _a, _b. Markus
AMDG On 07/23/2012 11:17 AM, Markus Werle wrote:
Steven Watanabe wrote:
AMDG
[*slightly* off-topic: Does that mean Ad maiorem Dei gloriam?]
Yes.
On 07/22/2012 07:21 AM, Markus Werle wrote:
Hi Steven!
I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set?
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/...
I disagree with this decision. You write:
An earlier version of the library used the names _1, _2, etc. instead of _a, _b, etc. This caused a certain amount of confusion because the numbered placeholders are already used by several other libraries including Boost/Std Bind, Boost.Phoenix, and Boost.MPL.
IMHO the introduction of another set of placeholders is more confusing. If we are to discriminate here, we can do it via namespaces - and of course one day it is std::_1 for all of us.
Just because your library is the first to use _a, _b, _c
It isn't. Boost.Phoenix uses _a, _b, etc for local variables.
what does that mean for future (boost) libraries that use some kind of placeholders? Do they have to use _aa, _bb, etc.? To me placeholders are such a natural concept I do not care about having some kind of "deja vu" here. To the contrary: The meaning (placeholder) is identical so we should use identical names.
It isn't exactly identical. The names _1, _2 carry extra meaning about how they are substituted which doesn't make sense for my library.
I eventually decided that since the placeholders represented named parameters instead of positional parameters, letters were more appropriate than numbers.
Indeed the naming is arbitrary. Starting from the same observation (_1 is already available in boost::*) I draw the opposite conclusion: Use these names for the sake of symmetry and hope for convergence of concepts over the years.
@Review Master: Should I miss the end date for reviews, take this as my mini subset of a review: I'd prefer _1, _2 instead of _a, _b.
You are of course free to disagree with my decision, but I'm not going to change it. In Christ, Steven Watanabe
On Mon, Jul 23, 2012 at 3:30 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
On 07/23/2012 11:17 AM, Markus Werle wrote:
Steven Watanabe wrote:
On 07/22/2012 07:21 AM, Markus Werle wrote:
I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set?
http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/...
I disagree with this decision. You write:
An earlier version of the library used the names _1, _2, etc. instead of _a, _b, etc. This caused a certain amount of confusion because the numbered placeholders are already used by several other libraries including Boost/Std Bind, Boost.Phoenix, and Boost.MPL.
IMHO the introduction of another set of placeholders is more confusing. If we are to discriminate here, we can do it via namespaces - and of course one day it is std::_1 for all of us.
Just because your library is the first to use _a, _b, _c
It isn't. Boost.Phoenix uses _a, _b, etc for local variables.
what does that mean for future (boost) libraries that use some kind of placeholders? Do they have to use _aa, _bb, etc.? To me placeholders are such a natural concept I do not care about having some kind of "deja vu" here. To the contrary: The meaning (placeholder) is identical so we should use identical names.
It isn't exactly identical. The names _1, _2 carry extra meaning about how they are substituted which doesn't make sense for my library.
I eventually decided that since the placeholders represented named parameters instead of positional parameters, letters were more appropriate than numbers.
I've asked the same question "why _a, _b, etc instead of _1, _2, etc" a while back. Steven replied, it's because _a, _b, etc are placeholders for named parameters and not for positional parameters (I'm not sure if this is explicitly stated in the documentation). That makes sense to me -- _1, _2, etc are placeholders for positional parameters in all other libs mpl, bind, phoenix, etc so they should not be used for named parameters.
Indeed the naming is arbitrary. Starting from the same observation (_1 is already available in boost::*) I draw the opposite conclusion: Use these names for the sake of symmetry and hope for convergence of concepts over the years.
@Review Master: Should I miss the end date for reviews, take this as my mini subset of a review: I'd prefer _1, _2 instead of _a, _b.
You are of course free to disagree with my decision, but I'm not going to change it.
--Lorenzo
On 07/23/12 14:42, Lorenzo Caminiti wrote:
On Mon, Jul 23, 2012 at 3:30 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
On 07/23/2012 11:17 AM, Markus Werle wrote:
Steven Watanabe wrote:
On 07/22/2012 07:21 AM, Markus Werle wrote:
I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set?
[snip] It isn't exactly identical. The names _1, _2 carry extra meaning about how they are substituted which doesn't make sense for my library.
I eventually decided that since the placeholders represented named parameters instead of positional parameters, letters were more appropriate than numbers.
I've asked the same question "why _a, _b, etc instead of _1, _2, etc" a while back. Steven replied, it's because _a, _b, etc are placeholders for named parameters and not for positional parameters
Hmm... seems like they're names for types, not parameters. I'm thinking they're somewhat like: template<typename _a, typename _b, ...> struct te { te(_a a_val, _b b_val, ... ) : my_a(a_val), my_b(b_val) {} _a my_a; _b my_b; ... //operations }; I haven't thought it through that well, but the above analogy may be some help in justifying the use of names instead of types. In addition, just as shown in the construction_map_tuple.cpp code attached to: http://article.gmane.org/gmane.comp.lib.boost.devel/232953 the order is only implied if you use tuple. If you use any to create the parameter, there's no order imposed. For example, the following snippet of code from the .cpp file: //Something similar using bindings and just any's. te::static_binding<bindings_map_t> bindings_made=te::make_binding<bindings_map_t>(); te::any<requirements, _a> bnd_value_ptr_v(stk_value_ptr_v,bindings_made); te::any<requirements, _b> bnd_displacement_v(stk_displacement_v,bindings_made); te::any<requirements, _a> bnd_displaced_value_ptr_v(bnd_value_ptr_v + bnd_displacement_v); Shows an a_ created, then a _b createe, then another _a created. [snip]
On Jul 24, 2012 9:35 AM, "Larry Evans" <cppljevans@suddenlink.net> wrote:
On 07/23/12 14:42, Lorenzo Caminiti wrote:
On Mon, Jul 23, 2012 at 3:30 PM, Steven Watanabe <watanabesj@gmail.com>
wrote:
On 07/23/2012 11:17 AM, Markus Werle wrote:
Steven Watanabe wrote:
On 07/22/2012 07:21 AM, Markus Werle wrote:
I have one question: proto and spirit use _1, _2, etc. TypeErasure uses _a, _b, _c ... What was your reason to introduce yet another placeholder set?
[snip] It isn't exactly identical. The names _1, _2 carry extra meaning about how they are substituted which doesn't make sense for my library.
I eventually decided that since the placeholders represented named parameters instead of positional parameters, letters were more appropriate than numbers.
I've asked the same question "why _a, _b, etc instead of _1, _2, etc" a while back. Steven replied, it's because _a, _b, etc are placeholders for named parameters and not for positional parameters
Hmm... seems like they're names for types, not parameters. I'm thinking they're somewhat like:
Parameters as in either function or template paramters, template paramters can be types.
template<typename _a, typename _b, ...> struct te { te(_a a_val, _b b_val, ... ) : my_a(a_val), my_b(b_val) {} _a my_a; _b my_b; ... //operations };
I haven't thought it through that well, but the above analogy may be some help in justifying the use of names instead of types. In addition, just as shown in the construction_map_tuple.cpp code attached to:
http://article.gmane.org/gmane.comp.lib.boost.devel/232953
the order is only implied if you use tuple. If you use any to create the parameter, there's no order imposed.
No order means the parameters are not positional so _1, etc would be misleading.
For example, the following snippet of code from the .cpp file:
//Something similar using bindings and just any's. te::static_binding<bindings_map_t> bindings_made=te::make_binding<bindings_map_t>(); te::any<requirements, _a> bnd_value_ptr_v(stk_value_ptr_v,bindings_made); te::any<requirements, _b> bnd_displacement_v(stk_displacement_v,bindings_made); te::any<requirements, _a> bnd_displaced_value_ptr_v(bnd_value_ptr_v + bnd_displacement_v);
Shows an a_ created, then a _b createe, then another _a created.
[snip]
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
HTH, --Lorenzo
participants (4)
-
Larry Evans -
Lorenzo Caminiti -
Markus Werle -
Steven Watanabe