Subject: Re: [boost] Efficient tuple implementation
From: Larry Evans (cppljevans_at_[hidden])
Date: 2014-06-17 11:02:14
On 06/16/14 18:55, Louis Dionne wrote:
> Larry Evans <cppljevans <at> suddenlink.net> writes:
>> On 06/15/14 08:44, Louis Dionne wrote:
>>> Larry Evans <cppljevans <at> suddenlink.net> writes:
>>>> On 06/06/14 21:18, Louis Dionne wrote:
>>>> IIRC, list uses an evaluator and "tagged" lists where the 1st element in
>> ^^^^ should be lisp
>>>> the list is a tag for the operation to be performed and the
>>>> evaluator dispatches on this tag to do the operation with the
>>>> operands being the remaining args in the list.
>>> I don't understand which list you are talking about.
>> OOPS. Very sorry for the typo above. I'm talking about
>> the language, Lisp:
>> and the pattern I was talking about was called "Polish
>> prefix notation" in the wikipedia article.
> Ok, now I understand better. As for your question, I did not follow the
> development of Spirit X3 close enough to know for sure. However, if you
> have to store variadic arguments, using a lambda somewhere in there is
> probably the most efficient way. And as soon as you have stuff in a
> variadic representation, it's better if you keep it that way because
> most algorithms will perform better on variadic packs.
> The way I see it for Boost.Hana, your dispatching system could be used
> internally as an optimization to dispatch efficient operations on variadics,
> while keeping the more flexible type class based dispatching interface. I'll
> keep that on the back of my head for when I start optimizing seriously.
A more complete example, which uses operators || and && to create the
tagged tuples, is now here:
The use of the operators make it more like what spirit does with, for
example, operators | and >>.
However, I still don't have a good idea of how useful this will be.
Only more experimentation can tell.
Hopefully others may have some ideas on how to use this.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk