Boost logo

Boost :

Subject: Re: [boost] [Fusion] Some ideas
From: Joel de Guzman (djowel_at_[hidden])
Date: 2013-02-03 10:42:14

On 2/3/13 11:24 PM, TONGARI wrote:
> 2013/2/3 Joel de Guzman <djowel_at_[hidden]>
>> On 2/3/13 9:59 PM, TONGARI wrote:
>>> Just uploaded to:
>>> 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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at