Re: [boost] Re: Problems with Named Template Parameters

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-05-24 02:07:09

From: "David Abrahams" <abrahams_at_[hidden]>
> From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
>
> >     iterator_traits_generator
> >     < make_list
> >       < iterator_traits_reference<foo>
> >       , iterator_traits_category<std::input_iterator_tag>
> >       >::RET
> >     >::RET
>
> Which is even heavier on the syntax than what we've got. I'm trying to
move
> the other direction.

After reading my own message, I almost immediately changed my libraries to
use the other approach, because it results in more compact user code, which
should greatly outnumber the amount of library code.

It should also be noted that the Named Template Parameters technique suffers
from the fact that in standard C++, you need to insert the keyword
"template" when you refer to a member template of a type that depends on the
template arguments in template code (hmn... there must be a better/more
accurate way of saying this). When that happens, the code becomes quite
involved:

template<class T>
struct // ...
{
  // ...
    iterator_traits_generator
    ::reference<T>
    ::template category<std::input_iterator_tag>
    ::template ...
  // ...
};

> > Alternatively, it would be possible to let the generator take multiple
> > parameters, and then make the list inside the generator:
> >
> >     iterator_traits_generator
> >     < iterator_traits_reference<foo>
> >     , iterator_traits_category<std::input_iterator_tag>
> >     >::RET
>
> I think that would be better, though IMO it would be best if the
parameters
> were passed directly to boost::iterator_adaptor<> instead.

That should be doable.

> > The list DSL utility primitives consist of the following (pseudo code):
>
> What does DSL stand for?

Domain Specific Language. See pages 137-142 in Generative Programming, ISBN
0-201-30977-7. In this case the DSL is implemented using template
metaprogramming.

> One problem with this approach for iterator_adaptors is that just
computing
> the default type in cases where it isn't needed can cause compilation
> errors. It shows up where the expression std::iterator_traits<Base> is
used
> and Base is not an iterator. The default type must only be computed when
no
> argument is supplied.

Assuming that both "class Base" and "template<class T> class
std::iterator_traits" are accessible from the current scope, then in
standard C++ the expression "std::iterator_traits<Base>" can not cause
compilation errors. See pages 438-444 in Generative Programming, ISBN
0-201-30977-7.