Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-09 16:45:02


"David B. Held" <dheld_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:uvft780gk.fsf_at_boost-consulting.com...
>> [...]
>> Lambda "adds the type" for cases like std::vector<_1>.
>> Metafunction classes, though, are supposed to be the super-
>> efficient way to do things, so having the library perform extra
>> template instantiations to detect the nested ::type would
>> probably not be appropriate there.
>
> Ok, that's good to know. It looks like the policy adaptor is
> causing longer compile times, so converting to metafunction
> classes should actually improve that?

I don't know what "the policy adaptor" is. The Boost Iterator
library uses a design pattern we call "policy adaptor" but I think
you mean something else.

>> BTW, normally, you might:
>>
>> struct Policy
>> {
>> template <class P>
>> struct apply
>> {
>> typename some_other_class type;
>> };
>> };
>>
>> if nothing else, just to cut down on symbol size (you don't want
>> to see Policy::apply<...> in your error messages when it could
>> be some_other_class<...>).
>
> I guess I don't understand what the nested type is for when you
> aren't really doing a meta-computation, so I don't know what an
> appropriate type for "some_other_class" would be

Usually

   some_template_name<P>

> Are you saying it can be any arbitrary type at all, since I'm not
> using the "metafunction result"? And that I should make it
> descriptive so that I don't just see a bunch of references to
> ::apply (which is going to get annoying when you have problems in
> more than one policy)?

No, I'm saying that if you use metafunction classes you have to use
the metafunction result, and you might not want it to look like
Policy::apply<P> but rather Something<P>.

I think from your other message you got the picture OK.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk