On 2/3/13 11:24 PM, TONGARI wrote:
2013/2/3 Joel de Guzman <djowel@gmail.com>
On 2/3/13 9:59 PM, TONGARI wrote:
Just uploaded to:
https://github.com/jamboree/**Boost.FusionEx<https://github.com/jamboree/Boost.FusionEx>
There are: + mapping + left_mapping + full_mapping
Simple tests contained. Comments/improvements are welcome :^)
By looking at the sample code, it seems I misunderstood your original post by a long shot.
How did you understand it then?
I guess it's irrelevant how I understood it then. What's important is how I can understand it now and I really want to understand what it is exactly you are trying to achieve.
There's a bit different than what I originally wrote.
The first thought was to map-assign the data:
mapping(dst, src)
And now it's more general:
result = mapping(a, b, binary_op_on_data)
Good idea. But it's better if you can provide both versions. Something similar to filter and filter_if.
returns a view which is also associative
FWIW, "mapping/left_mapping/full_mapping" are analog to "inner join/left join/full join" in relational DB.
Perhaps mapping is not a good name? Then of course, we already have "join".
Could you please provide some rough text about
these algorithms/views by presenting some real world use cases and how these are solved by your additions?
I intend to do it for mapping between different pixel formats.
e.g.
gil::rgba8_pixel_t dst; gil::bgra8_pixel_t src;
eval(left_mapping(view(dst), src, alpha_blend));
I still don't understand "view" and "eval" enough. Pardon me for being slow. It would be best to collect all your thoughts in a single, complete explanation of all these new additions so that we don't have any misunderstandings. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com