Geometry Boost List: [ggl] pre-/post-increment op on iterators

Subject: [ggl] pre-/post-increment op on iterators
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-04-29 16:18:52

Mateusz Loskot wrote:
> Barend Gehrels wrote:
>   
>>>> A related question, I've created some iterators recently and it would
>>>> be convenient to have an interator on a vector which has a segment as
>>>> its valuetype. Didn't work it out and don't know if it is possible at
>>>> all, do you think it makes sense here?
>>>>         
>>> I'm not sure I can grasp the idea.
>>> Perhaps you could illustrate your idea with a snippet of code?
>>>
>>> I can see vector that has a segment as its value_type as
>>> simple as vector<segment>, but it is not what you're thinking of,
>>> I presume.
>>>       
>> OK, let's try, it should look like something like this:
>>
>> vector<point_2d> line;
>> // ... file this line somehow
>> // creates iterator which should iterator over the whole line
>> ggl::segment_iterator<vector<point_2d>::const_iterator> it(line);
>> // indicates the end
>> ggl::segment_iterator<vector<point_2d>::const_iterator> end(line.end());
>> while(it != end)
>> {
>>    ggl::segment<const point_2d> segment = *it;
>>    std::cout << length(segment) << std::endl;
>>    it++;
>> }
>>
>> So operator * returns a segment, valuetype should be a segment-type (can
>> be specified as template par), operator-> should work on a segment, etc.
>> It would be instead of having two iterators, I've often prev and it,
>> where prev=it++;
>>     
>
> Have you solve it? If not, I can give it a try.
>   
Not yet, didn't look at it until now

> I think it can be solved with a thin iterator adapter that
> dereferences to segment, instead of to point.
> The adapter, or a view as called in some situations, should do the job.
>
>   
It will probably be something like that. However, it'll need a local 
variable "segment" which is then dereferenced. What if the iterator goes 
next? Is the local variable copied? Didn't do such a thing before.

I'm currently busy in core, multi_core and probably some 
(multi)algorithms...

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090429/89e65f3c/attachment.html