On 2/3/13 4:07 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 11:50 AM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/2/13 3:52 PM, TONGARI wrote:
Hi,
Here are some ideas come up when writing some associative mapping algorithm/views. I think it'd be nice to have: * Auxiliary function 'eval' to force the evaluation of transform-like view e.g. fusion::eval(fusion::****transform(a, b, some_void_return_ftor))
How's that any different from as_vector, as_list, etc. ?
They cannot take voids.
Also, what will be the container type of the result of "eval" ?
Void. Just to trigger each transformation.
Do you have a use-case?
e.g.
eval(mapping(view(dst), src, _1 = _2))
Sorry, I do not understand that.
* Conversion function 'as_view' to make Container a view to reserve the
mutability.
You mean to make it immutable?
No, the opposite, to keep the elements mutable as they were. Algorithms in Fusion take const&, 'as_view' is mean to workaround. Not sure if Fusion will insist on functional-style.
No, the opposite. I'm thinking about allowing mutable views. Would you be willing to implement them?
OK, function: view(seq) returns: if seq is view -> seq else -> container_view // in detail or public?
Or better name suggestions?
No, I meant: I am considering allowing views to be mutable by allowing algorithms take const&. I suggest starting with a clear use case on a problem that can't be solved (currently) with Fusion and a clear proposal on a solution. It's very possible that I am missing a lot. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com