Re: [Boost-users] [proto] problem with templated recursive transform

Subject: Re: [Boost-users] [proto] problem with templated recursive transform
From: Daniel Oberhoff (daniel_at_[hidden])
Date: 2009-02-07 04:33:21

On 2009-02-07 01:06:16 +0100, Eric Niebler <eric_at_[hidden]> said:
> 
>>> proto::function< proto::terminal< CPUDataND_< T > >, index_grammar,
>>> index_grammar, index_grammar, index_grammar, index_grammar >
>>> 
>>> This requires BOOST_PROTO_MAX_ARITY to be set to 6, whereas by default
>>> it is set to 5. After deleting this line, everything compiles and runs
>>> just fine for me.
>> 
>> ok. will c++0x variadic templates help here?
> 
> I've experimented with a variadic Proto. It's not without its problems.
> Consuming variadic parameter packs requires recursive templates, so a
> completely variadic Proto actually compiles *much* slower. A good way to
> see this is to recognize that there is no way using variadic class
> templates for this:
> 
>    template<class... A>
>    struct vector { /*what goes here???*/ };
> 
> to generate a class like this:
> 
>    template<class A0, ... class An>
>    struct vector {
>      A0 a0;
>      ...
>      An an;
>    };
> 
> That is, you can't generate a flat struct from a variadic class
> template. With a variadic class template, you need to play games with
> inheritance or head and tail data members, which causes this to
> instantiate O(N) templates. So chances are, Proto will always have a
> hard-coded upper limit on the number of child nodes.

ah, ok, bummer. A friend of mine recently mused if it wasn't time for a 
new language. not like python, more like D. Not that I particularly 
like D (well, I don't really know it either), just that it seems people 
have taken c++ to it's limits, and c++0x can't really help totally, 
because it is an incremental change (even though auto will be great I 
think, as will variadic function templates and move semantics). I 
opposed him at the time, but seeing how much black magic goes into ETs 
(or DSELs in general), he might be right after all.

> 
> I've filed bugs against msvc for its mishandling of nested function
> types. In the mean time, please continue using callable transforms if
> you like them. You can always wrap them in proto::call<> (or, for object
> transforms, proto::make<>) to keep msvc happy, if that's a compiler you
> care about.

Ok, that isn't the worst of solutions, if I end up needing msvc (which 
may actually be the case soon, as we may be required to write plugins 
for windows programs with this stuff...).

Thanks again for taking the time and giving something like proto to the 
community.

Daniel