|
Boost : |
Subject: Re: [boost] [fusion] segmented fusion 2.0
From: Joel de Guzman (joel_at_[hidden])
Date: 2011-08-18 19:45:10
On 8/19/2011 7:19 AM, Eric Niebler wrote:
> 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.
Wow, that was actually quicker than I thought! Awesome!
All tests pass here.
>>> 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.
I haven't heard from Christopher, yet. Christopher, thoughts?
We can probably proceed with the 0x merge later, Christopher
is not yet ready.
Regards,
-- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk