Hi Eddie, Joel, all, I apologize that this is a very short review. I believe the library should be accepted. The only interesting thing I have to add to the discussion is that a comparison with concepts should be made at least here, and perhaps in the documentation. This library provides functionality that will also be achievable using concepts, e.g. with Matt Calabrese's Generic library. I surmise that TTI presents a slightly messier low-level way of figuring out what a type is capable of than concepts and concept-based overloading. So I figure that as usual in such situations, TTI would be more powerful and more concise for checking individual things, and more confusing and verbose for checking the entire interface of a type. I think it's good to have both a low-level and an abstract way of doing things. TTI and Generic probably share some techniques and could learn from each other. A few superficial comments below. I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :). Personally I would use the placeholder expressions and not the metafunction classes, because I find it clearer, unless I really thought it would help with performance. I think I would prefer a smaller set of more clever macros as Lorenzo was suggesting, but this wouldn't affect my decision to use the library unless there were two that did the same thing. I was alarmed (yes, alarmed! frightened!) by template <class)(int> class InnerTemplate but IIUC this would only happen without variadic macros, so I don't care. Otherwise it would probably crash my emacs. Cheers, Gordon
On 7/17/2011 1:53 PM, Gordon Woodhull wrote:
Hi Eddie, Joel, all,
I apologize that this is a very short review.
I believe the library should be accepted.
Appreciated !
The only interesting thing I have to add to the discussion is that a comparison with concepts should be made at least here, and perhaps in the documentation. This library provides functionality that will also be achievable using concepts, e.g. with Matt Calabrese's Generic library.
I do not know the library in question except for a cursory glance.
I surmise that TTI presents a slightly messier low-level way of figuring out what a type is capable of than concepts and concept-based overloading. So I figure that as usual in such situations, TTI would be more powerful and more concise for checking individual things, and more confusing and verbose for checking the entire interface of a type.
I think it's good to have both a low-level and an abstract way of doing things. TTI and Generic probably share some techniques and could learn from each other.
A few superficial comments below.
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
Personally I would use the placeholder expressions and not the metafunction classes, because I find it clearer, unless I really thought it would help with performance.
I feel the same but my original intent with the MTFC macros was to offer a choice. Since then Jeffrey Hellrung has pointed out to me something I should have realized earlier, that boost::mpl::quote nicely offers the functionality of creating a metafunction class from a metafunction in a generic way, so I intend on dropping the MTFC macros as redundant.
I think I would prefer a smaller set of more clever macros as Lorenzo was suggesting, but this wouldn't affect my decision to use the library unless there were two that did the same thing.
Simpler yet equally effective is always the ideal, and I am well aware of it. At the same time I am not as bothered by a large, but sectioned off and understandable API, as many others are.
I was alarmed (yes, alarmed! frightened!) by
template<class)(int> class InnerTemplate
but IIUC this would only happen without variadic macros, so I don't care. Otherwise it would probably crash my emacs.
I am changing that so that in the non-variadic case a pp-array will be used and the sort of above syntax will no longer occur. Eddie
On 7/17/2011 4:10 PM, Edward Diener wrote:
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
As a casual Boost user, I would welcome this. I would find TTI very useful, but I do not know MPL beyond the very basics, and I'd rather not have to learn it just so that I can use TTI. I think others may be in the same position. Regards, Nate.
On 7/17/2011 5:48 PM, Nathan Ridge wrote:
On 7/17/2011 4:10 PM, Edward Diener wrote:
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
As a casual Boost user, I would welcome this. I would find TTI very useful, but I do not know MPL beyond the very basics, and I'd rather not have to learn it just so that I can use TTI. I think others may be in the same position.
I hear you ! Eddie
On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge <zeratul976@hotmail.com>wrote:
On 7/17/2011 4:10 PM, Edward Diener wrote:
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
As a casual Boost user, I would welcome this. I would find TTI very useful, but I do not know MPL beyond the very basics, and I'd rather not have to learn it just so that I can use TTI. I think others may be in the same position.
My initial response is, grab a beer and go learn about Boost.MPL lambda expressions, you'll be happy you did (at worst, you're +1 drunk beer). Okay, my secondary response: I don't think it's really that bad to write has_type_xxx< T, boost::is_same< boost::mpl::_1, U > > // my proposed query rather than has_type_xxx< T, U > // current query (a) How often do you *really* want to check that T::xxx is precisely U? I think, much more frequently, you'll just want has_type_xxx<T>. And I'm *not* proposing to get rid of *that*. (b) To me, the former states more explicitly how U ties into the query. (c) With the current has_type_xxx semantics, it's going to get onerous one metaprogramming day when boost::is_same< boost::mpl::_1, U > just isn't want what you want. You want to check if T::xxx is an object type. Or whether it's const-qualified. Or any of a number of other properties in Boost.TypeTraits. Or :: gasp :: whether T::xxx itself has a nested type yyy :) Given that TTI is a "metaprogramming library proposed for Boost", I don't really see any issues (in theory) with TTI making good use of a library called "Boost Metaprogramming Library" (aka, Boost.MPL). Honestly, though, it did take me a few reads to dissect the nuances of the Boost.MPL "Metafunctions" section, specifically the subsections "Invocation" and "Composition and Argument Binding". Fortunately, I believe only a very small part of that is necessary to effectively use my proposed change to HAS_TYPE. You can get a lot of mileage out of just knowing about and using Boost.MPL placeholder expressions like boost::is_same< boost::mpl::_1, U >. I know *I* did for a long time and I just accepted the "magic" that went on behind the scenes that made them work until I mustered up the courage to really delve into the documentation. I think if TTI just added a couple of examples showing Boost.MPL placeholder expressions in action, everything would be fine. - Jeff
On 7/17/2011 6:46 PM, Jeffrey Lee Hellrung, Jr. wrote:
On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge<zeratul976@hotmail.com>wrote:
On 7/17/2011 4:10 PM, Edward Diener wrote:
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
As a casual Boost user, I would welcome this. I would find TTI very useful, but I do not know MPL beyond the very basics, and I'd rather not have to learn it just so that I can use TTI. I think others may be in the same position.
My initial response is, grab a beer and go learn about Boost.MPL lambda expressions, you'll be happy you did (at worst, you're +1 drunk beer).
Okay, my secondary response: I don't think it's really that bad to write
has_type_xxx< T, boost::is_same< boost::mpl::_1, U> > // my proposed query
rather than
has_type_xxx< T, U> // current query
(a) How often do you *really* want to check that T::xxx is precisely U? I think, much more frequently, you'll just want has_type_xxx<T>. And I'm *not* proposing to get rid of *that*. (b) To me, the former states more explicitly how U ties into the query. (c) With the current has_type_xxx semantics, it's going to get onerous one metaprogramming day when boost::is_same< boost::mpl::_1, U> just isn't want what you want. You want to check if T::xxx is an object type. Or whether it's const-qualified. Or any of a number of other properties in Boost.TypeTraits. Or :: gasp :: whether T::xxx itself has a nested type yyy :)
I get the idea. One should be able to create one's own metafunctions for checking nested types and whatever introspected or non-introspected properties of the type one can devise as part of the library interface. Of course one can do that in discreet steps now ( just typedef the type and use TTI, type traits, or your own metafunctions against it ), but one extended interface is probably better. I just want to make sure this fits in well with everything else and think about its ramifications and how best it can be used with everything else.
Given that TTI is a "metaprogramming library proposed for Boost", I don't really see any issues (in theory) with TTI making good use of a library called "Boost Metaprogramming Library" (aka, Boost.MPL).
That is a bit of an unfair dig. Obviously I am using plenty of MPL in the library, but not enough of some parts of it which you are suggesting. Remember though, for the MPL non-expert I still want to make the library useful so simpler interfaces are still my goal while adding functionality for the experts.
Honestly, though, it did take me a few reads to dissect the nuances of the Boost.MPL "Metafunctions" section, specifically the subsections "Invocation" and "Composition and Argument Binding". Fortunately, I believe only a very small part of that is necessary to effectively use my proposed change to HAS_TYPE. You can get a lot of mileage out of just knowing about and using Boost.MPL placeholder expressions like boost::is_same< boost::mpl::_1, U>. I know *I* did for a long time and I just accepted the "magic" that went on behind the scenes that made them work until I mustered up the courage to really delve into the documentation.
I think if TTI just added a couple of examples showing Boost.MPL placeholder expressions in action, everything would be fine.
I do show placeholder expressions when using the nullary metafunctions but I did not appreciate boost::mpl::lambda enough in allowing the end-user to build metafunctions taking metadata. I will revisit it. Thanks ! Eddie
From: jeffrey.hellrung@gmail.com
On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge <zeratul976@hotmail.com>wrote:
On 7/17/2011 4:10 PM, Edward Diener wrote:
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
As a casual Boost user, I would welcome this. I would find TTI very useful, but I do not know MPL beyond the very basics, and I'd rather not have to learn it just so that I can use TTI. I think others may be in the same position.
My initial response is, grab a beer and go learn about Boost.MPL lambda expressions, you'll be happy you did (at worst, you're +1 drunk beer).
Okay, my secondary response: I don't think it's really that bad to write
has_type_xxx< T, boost::is_same< boost::mpl::_1, U > > // my proposed query
rather than
has_type_xxx< T, U > // current query
(a) How often do you *really* want to check that T::xxx is precisely U? I think, much more frequently, you'll just want has_type_xxx<T>. And I'm *not* proposing to get rid of *that*. (b) To me, the former states more explicitly how U ties into the query. (c) With the current has_type_xxx semantics, it's going to get onerous one metaprogramming day when boost::is_same< boost::mpl::_1, U > just isn't want what you want. You want to check if T::xxx is an object type. Or whether it's const-qualified. Or any of a number of other properties in Boost.TypeTraits. Or :: gasp :: whether T::xxx itself has a nested type yyy :)
I suppose, as long as the TTI docs show some clear examples of how to use the MPL lambdas in the most common cases, rather than just saying "any MPL lambda can be used here" and referring you to the MPL docs, it should be fine. I just don't think users should have to go off and learn about MPL lambdas by reading some separate documentation, just to be able to make a simple use of this TTI feature. Apart from that concern, I *do* see the value in being able to check for other things besides the types being the same, and I think it would be a useful addition. Regards, Nate.
On 7/17/2011 10:00 PM, Nathan Ridge wrote:
From: jeffrey.hellrung@gmail.com
On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge<zeratul976@hotmail.com>wrote:
On 7/17/2011 4:10 PM, Edward Diener wrote:
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
I will look further into adding this but I strongly feel that I should not drop the simple functionality currently provided, where the end-user can just pass an actual type.
As a casual Boost user, I would welcome this. I would find TTI very useful, but I do not know MPL beyond the very basics, and I'd rather not have to learn it just so that I can use TTI. I think others may be in the same position.
My initial response is, grab a beer and go learn about Boost.MPL lambda expressions, you'll be happy you did (at worst, you're +1 drunk beer).
Okay, my secondary response: I don't think it's really that bad to write
has_type_xxx< T, boost::is_same< boost::mpl::_1, U> > // my proposed query
rather than
has_type_xxx< T, U> // current query
(a) How often do you *really* want to check that T::xxx is precisely U? I think, much more frequently, you'll just want has_type_xxx<T>. And I'm *not* proposing to get rid of *that*. (b) To me, the former states more explicitly how U ties into the query. (c) With the current has_type_xxx semantics, it's going to get onerous one metaprogramming day when boost::is_same< boost::mpl::_1, U> just isn't want what you want. You want to check if T::xxx is an object type. Or whether it's const-qualified. Or any of a number of other properties in Boost.TypeTraits. Or :: gasp :: whether T::xxx itself has a nested type yyy :)
I suppose, as long as the TTI docs show some clear examples of how to use the MPL lambdas in the most common cases, rather than just saying "any MPL lambda can be used here" and referring you to the MPL docs, it should be fine. I just don't think users should have to go off and learn about MPL lambdas by reading some separate documentation, just to be able to make a simple use of this TTI feature.
Apart from that concern, I *do* see the value in being able to check for other things besides the types being the same, and I think it would be a useful addition.
I will probably be adding Jeffrey Hellrung's suggestion to TTI. If I do I will give examples which show how to use boost::mpl::lambda to pass a metafunction which depends on placeholders as an argument to the HAS_TYPE generated metafunction. For further knowledge of what lambda can do, the metaprogrammer should read the MPL documentation.
On Jul 18, 2011, at 6:51 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
I will probably be adding Jeffrey Hellrung's suggestion to TTI. If I do I will give examples which show how to use boost::mpl::lambda to pass a metafunction which depends on placeholders as an argument to the HAS_TYPE generated metafunction. For further knowledge of what lambda can do, the metaprogrammer should read the MPL documentation.
Nice, it's kind of like find_if, except that a type is not a conventional metadata container (and the metafunction doesn't return an iterator ;).
On Sun, Jul 17, 2011 at 10:53 AM, Gordon Woodhull <gordon@woodhull.com>wrote: [...]
I agree with Jeff's suggestion that the matching metafunction should take a metafunction that defaults to is_same rather than always testing for type equality (and now I see why he was also suggesting that in the Type Traits Extension review :).
Well, at least I convinced someone...eventually :) Maybe I should give another shoutout to Frederic to reconsider this! [also, small correction, it should default to boost::mpl::always< boost::mpl::true_ >] - Jeff
participants (4)
-
Edward Diener -
Gordon Woodhull -
Jeffrey Lee Hellrung, Jr. -
Nathan Ridge