|
Boost Users : |
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-08-04 15:34:26
On 8/4/05, Eduardo Bezerra <edubez_at_[hidden]> wrote:
> I'm reading the C++ Template Metaprogramming book and I'm not
> understanding the following code from page 65-66:
>
> template <class T>
> struct param_type
> : mpl::eval_if <
> typename boost::is_scalar<T>::type
> , mpl::indentity<T>
> , boost::add_reference<T const>
> >
> {};
>
> template <class T>
> struct param_type
> : mpl::eval_if <
> boost::is_scalar<T>
> --> ^^^^^^^^^^^^^^^^^^^^^^^ <--
> , mpl::indentity<T>
> , boost::add_reference<T const>
> >
> {};
>
> After reading again and again the explanation I still don't get why we
> don't need to use typename ....::type anymore. The text explains that
> all Boost's integral metafunctions suply a nested ::value, but how it is
> used in this context ?
The eval_if is a lazy metafunction, so that mpl::identity nor
boost::add_reference is evaluated before boost::is_scalar and chosed
which to evaluate. That way even when one of the metafunctions results
in a compilation error, only the right one will be evaluated and so
wont happen in any compilation error(and will be faster if you have
two expensive metafunctions either).
And as boost::is_scalar has ::value either, then it wont be needed to
use typename xxx<T>::type, that would be used as typename
xxx<T>::type::value inside eval_if, only typename xxx<T>::value will
be used for eval_if, begin evaluted lazily either.
I think it is this... If I'm wrong, or I have missed the question,
somebody correct me, please :P.
>
> Any help would be greatly appreciated.
>
> Best regards,
> Eduardo
>
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net