Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-07-11 09:42:07

"Drazen DOTLIC" <Drazen.Dotlic_at_[hidden]> writes:

> Hello,
> I've recently discovered that mpl provides all the functionality I was
> previously using from loki, so I decided to switch.

Just a note: Loki (generic programming applied to design patterns) and
MPL (C++ template metaprogramming) preally have a different focus; you
may yet find some Loki components that are useful to you.

> There is one small thing driving me crazy, and I was wondering if I
> missed something... I was using loki's TypeAtNonStrict "algorithm"
> to give me type from type list at a specified position, or NullType
> (loki's internal "null" class) if not found. Now, I need the same
> for mpl:vector, and I tried the following 'naïve' approach:

Uh, formatting, please!

> [TypeVector is boost::mpl::vector<bool>] enum { numParams =
> boost::mpl::size<TypeVector>::type::value }; typedef typename
> boost::mpl::if_c<(numParams > 2), typename
> boost::mpl::at_c<TypeVector, 2>::type, boost::mpl::void_>::type
> Param1;

    [TypeVector is boost::mpl::vector<bool>]
    enum {
        numParams = boost::mpl::size<TypeVector>::type::value

    typedef typename
           (numParams > 2)
         , typename boost::mpl::at_c<TypeVector, 2>::type
         , boost::mpl::void_
>::type Param1;

> I was expecting to get Param1 to be boost::mpl::void_, but to my great
> surprise, my compiler (VC7.1) decided to fully evaluate "then" branch
> of if_c as well, even though the expression numParams > 2 was false,
> and failed.

You have two confusion is about the way template instantiation
works. Whenever you write something of the form:

        template_name< ... >::nested_name

The template is instantiated.

> What would be the "right" way to express my intention?

    template <class S, class N>
    struct type_at_non_strict
      : mpl::apply_if<
          , mpl::at<S,N>
          , mpl::identity<mpl::void_>

    template <class S, std::size_t N>
    struct type_at_non_strict_c
      : type_at_non_strict<S, mpl::size_t_c<N> >

> Btw, I would like to congratulate authors of mpl on the job well
> done, I am most impressed not only with the features that mpl
> provides but also with the errors I get when something goes wrong -
> they are far more readable than most of the STL errors I am used to
> seeing.


Might I suggest you get ahold of Leor Zolman's latest STLFilt package
( It contains some great features for formatting
nested templates so that they are readable.


Dave Abrahams
Boost Consulting

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