Boost logo

Boost :

Subject: Re: [boost] [tti] review
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-07-17 20:21:46

On 7/17/2011 6:46 PM, Jeffrey Lee Hellrung, Jr. wrote:
> On Sun, Jul 17, 2011 at 2:48 PM, Nathan Ridge<zeratul976_at_[hidden]>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 !


Boost list run by bdawes at, gregod at, cpdaniel at, john at