Boost logo

Boost :

Subject: Re: [boost] [fusion] segmented fusion 2.0
From: Eric Niebler (eric_at_[hidden])
Date: 2011-08-18 19:19:21


On 8/15/2011 7:38 PM, Joel de Guzman wrote:
> On 8/12/2011 9:46 AM, Eric Niebler wrote:
>>
>> Here's my thinking:
>>
>> 1)
>> support/ext_/is_segmented.hpp => support/
>> sequence/intrinsic/ext_/segments.hpp => sequence/intrinsic/
>> sequence/intrinsic/ext_/size_s.hpp => sequence/intrinsic/detail/
>> view/ext_/segmented_iterator.hpp => iterator/
>> view/ext_/segmented_iterator_range.hpp => view/iterator_range/detail/
>> view/ext_/segmented_begin.hpp => sequence/intrinsic/detail/
>> view/ext_/segmented_end.hpp => sequence/intrinsic/detail/
>> view/ext_/segmented_fold_until.hpp => support/
>>
>> Various supporting implementation details make corresponding moves.
>>
>> container/ext_/tree.hpp becomes part of the test suite. It is poorly
>> designed and doesn't deserve to be part of Fusion proper.
>>
>> 2) begin, end, size and empty dispatch to their segmented
>> implementations by default.
>>
>> 3) The existing segmented algorithms (find_s, find_if_s, fold_s,
>> for_each_s) just get merged with their non-segmented equivalents.

These are now done. Sorry for the lag. It was harder than I thought.

>> 4) Wait for the dust to settle. Assuming all is looking good, try making
>> joint_view segmented.
>>
>> 5) Use segmented_fold_until to write segmented flavors of as many
>> algorithms as possible.
>>
>> I can do 1-3. 5 can be a team effort and can begin as soon as everything
>> has found its rightful place.
>>
>> A word about segmented_fold_until.
<snip>

I've changed the interface to segmented_fold_until to make it more
straightforward to customize its behavior. See
algorithm/query/detail/segmented_find_if.hpp for an example.

> Thanks, Eric. If I haven't said so already, I think this is a
> very nice plan. I can definitely help out with 4 & 5.
>
> One thing to note though is that the fusion-0x code will fall out
> of sync once we go through this. I'm CC'ing Christopher.
>
> It would be foolish to merge fusion-0x now, in the middle of
> development, but I think that the 0x code should finally be
> merged to main as soon as the dust settles (after 3). Then,
> we can move to 4 and 5 with fusion-0x code in place.

OK, everything is ready. I'll wait until fusion-0x is in place before
spending any more time on this.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk