Re: [Boost-users] Boost range iterator pointing to wrong element

Subject: Re: [Boost-users] Boost range iterator pointing to wrong element
From: Giorgos Sermaidis (linuxfever_at_[hidden])
Date: 2013-10-09 14:12:40

Dear Nate and Gavin, 

Thank you so much for such a detailed explanation! It is very clear now.

boost-users-request_at_[hidden] wrote:

>Send Boost-users mailing list submissions to
>	boost-users_at_[hidden]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://lists.boost.org/mailman/listinfo.cgi/boost-users
>or, via email, send a message with subject or body 'help' to
>	boost-users-request_at_[hidden]
>
>You can reach the person managing the list at
>	boost-users-owner_at_[hidden]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Boost-users digest..."
>
>
>Today's Topics:
>
>   1. [thread] Test if a thread is running (Patrick Steele)
>   2. Re: [thread] Test if a thread is running (Kim Barrett)
>   3. Re: [thread] Test if a thread is running
>      (christoph.kliemt_at_[hidden])
>   4. Type Erasure: Infinite loop when accessing an element of a
>      container of any<>, where the element is another container
>      (Alexandre Pretyman)
>   5. Re: [boost] [1.55.0] Beta 1 Available (Rich E)
>   6. Re: Boost range iterator pointing to wrong element (Nathan Ridge)
>   7. Re: [thread] Test if a thread is running (Patrick Steele)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Tue, 8 Oct 2013 17:15:05 +0100
>From: Patrick Steele <steele.patrick_at_[hidden]>
>To: boost-users_at_[hidden]
>Subject: [Boost-users] [thread] Test if a thread is running
>Message-ID:
>	<CAFXDkHyrnTqijUc09otuNs7w+DwXSTue5eLh0-HZBvq+RH=HSg_at_[hidden]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>boost = 1.54
>OS = Windows 7
>compiler = Visual Studio 2005
>
>Hi,
>in order to test if a boost.thread is running I used timed_join as per
>http://stackoverflow.com/questions/1667420/how-can-i-tell-reliably-if-a-boost-thread-has-exited-its-run-method,
>which recommended that I should be able to call timed_join with a wait time
>of 0 ie
>bool isThreadRunning = ! m_Thread.timed_join( boost::get_system_time() );
>I have just upgraded to boost 1.54 to see that this no longer appears to
>work and that the timed_join function is being deprecated.
>Can you tell me how I should now check whether a thread is running please?
>Thanks,
>Patrick
>-------------- next part --------------
>HTML attachment scrubbed and removed
>
>------------------------------
>
>Message: 2
>Date: Tue, 08 Oct 2013 14:05:33 -0400
>From: Kim Barrett <kab.conundrums_at_[hidden]>
>To: boost-users_at_[hidden]
>Subject: Re: [Boost-users] [thread] Test if a thread is running
>Message-ID: <DAFACC65-BF89-424C-ABEF-AD6A49588B5C_at_[hidden]>
>Content-Type: text/plain; charset=us-ascii
>
>On Oct 8, 2013, at 12:15 PM, Patrick Steele wrote:
>> 
>> boost = 1.54
>> OS = Windows 7
>> compiler = Visual Studio 2005
>> 
>> Hi,
>> in order to test if a boost.thread is running I used timed_join as per http://stackoverflow.com/questions/1667420/how-can-i-tell-reliably-if-a-boost-thread-has-exited-its-run-method, which recommended that I should be able to call timed_join with a wait time of 0 ie
>> bool isThreadRunning = ! m_Thread.timed_join( boost::get_system_time() );
>> I have just upgraded to boost 1.54 to see that this no longer appears to work and that the timed_join function is being deprecated.
>> Can you tell me how I should now check whether a thread is running please?
>
>Use the joinable() member function.
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Tue, 08 Oct 2013 19:07:12 +0200
>From: christoph.kliemt_at_[hidden]
>To: boost-users_at_[hidden]
>Subject: Re: [Boost-users] [thread] Test if a thread is running
>Message-ID: <87hacrn133.fsf_at_[hidden]>
>Content-Type: text/plain
>
>Patrick Steele <steele.patrick_at_[hidden]> writes:
>
>> in order to test if a boost.thread is running I used timed_join as per
>> http://stackoverflow.com/questions/1667420/how-can-i-tell-reliably-if-a-boost-thread-has-exited-its-run-method,
>> which recommended that I should be able to call timed_join with a wait time
>> of 0 ie
>> bool isThreadRunning = ! m_Thread.timed_join( boost::get_system_time() );
>> I have just upgraded to boost 1.54 to see that this no longer appears to
>> work and that the timed_join function is being deprecated.
>> Can you tell me how I should now check whether a thread is running
>> please?
>
>In cases like this i use a flag that is set to "thread running" when its
>enters its run method and to "thread ended" when the thread leaves its
>run method; to signal a condition for another bookkeeper thread can be
>an option. 
>All this depends on how accurate the answer has to be... 
>
>regards Christoph
>
>
>
>
>------------------------------
>
>Message: 4
>Date: Tue, 8 Oct 2013 15:51:02 -0300
>From: Alexandre Pretyman <alexandre.pretyman_at_[hidden]>
>To: boost-users_at_[hidden]
>Subject: [Boost-users] Type Erasure: Infinite loop when accessing an
>	element of a container of any<>, where the element is another
>	container
>Message-ID:
>	<CAAXc0FUuaYzdCDtgBYVQXUwd0k=6OqiQrr5mmJ9ooZFVDfV4Yg_at_[hidden]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi Boost list!
>
>After watching Sean Parent's lightning-talk "Inheritance is the base class
>of Evil" (
>http://channel9.msdn.com/Events/GoingNative/2013/Inheritance-Is-The-Base-Class-of-Evil),
>I decided to try a similar example with Boost's Type Erasure library,
>but did not succeed.
>
>I created a vector of any<.., ostreamable<>,...>, implemented the stream
>operator to print this vector type and I can print its' elements. A problem
>arises, however, when I insert this vector as an element of a second
>vector. When I print the second vector I encounter an infinite loop ending
>with a stack overflow when accessing the vector type when it is an element
>of second vector.
>
>The example which demonstrates this behaviour follows attached on this
>message. I am using Boost 1.55 from the trunk with clang 3.2 from Apple,
>compiling it with the flags "-std=c++11 -stdlib=libc++" and linking with
>"-stdlib=libc++". I would be grateful if anyone could try this on your
>local boost version and compiler.
>
>Can anyone shed some light on why this happens?
>
>Regards,
>-- 
>Alexandre Pretyman
>-------------- next part --------------
>HTML attachment scrubbed and removed
>-------------- next part --------------
>A non-text attachment was scrubbed...
>Name: type-erasure-container-test.cpp
>Type: text/x-c++src
>Size: 2129 bytes
>Desc: not available
>URL: <http://lists.boost.org/boost-users/attachments/20131008/76e1df2b/attachment.bin>
>
>------------------------------
>
>Message: 5
>Date: Tue, 8 Oct 2013 19:12:04 -0400
>From: Rich E <reakinator_at_[hidden]>
>To: boost-users_at_[hidden]
>Cc: Boost Developers List <boost_at_[hidden]>
>Subject: Re: [Boost-users] [boost] [1.55.0] Beta 1 Available
>Message-ID:
>	<CA+vnWEgcHwzYnog+MWhkL7y-enwAu1L1W6xtrD=W4xAsiFTkTA_at_[hidden]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>I'm seeing that Fusion has not been updated with fixes for
>#5010<https://svn.boost.org/trac/boost/ticket/5010#comment:24>a
>*3* *year old(!)* bug, that is reported as fixed. Why is this? From what I
>can tell, changeset #4441
><https://svn.boost.org/trac/boost/changeset/84441>fixes the issues I
>ran into, but the 1.55beta package doesn't reflect
>this...
>
>
>
>On Tue, Oct 8, 2013 at 10:58 AM, Tom Kent <lists_at_[hidden]> wrote:
>
>> On Tue, Oct 8, 2013 at 9:11 AM, Marshall Clow <mclow.lists_at_[hidden]>wrote:
>>
>>> Boost release 1.55.0 beta 1 is now available from SourceForge
>>>
>>> See http://sourceforge.net/projects/boost/files/boost/1.55.0.beta.1/
>>>
>>> This release contains 1 new library:
>>>
>>>         * Predef:   This library defines a set of compiler, architecture,
>>> operating system, library, and other version numbers from the information
>>> it can gather of C, C++, Objective C, and Objective C++ predefined macros
>>> or those defined in generally available headers, from Rene Rivera.
>>>
>>> For details of what's in the release, see
>>> http://www.boost.org/users/history/version_1_55_0.html.
>>> Note that the links to files on this web page are for the final release -
>>> use the SourceForge link above to get the beta files.
>>>
>>> Please download the beta, give it a try, and report any problems you
>>> encounter.
>>>
>>> Thanks,
>>>
>>> -- The Boost Release Team
>>>
>>
>> The corresponding windows binaries for msvc-8.0, msvc-9.0, msvc-10.0, and
>> msvc-11.0 in 32 & 64 bit versions are now also available from sourceforge.
>>
>> https://sourceforge.net/projects/boost/files/boost-binaries/1.55.0_beta1/
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>-------------- next part --------------
>HTML attachment scrubbed and removed
>
>------------------------------
>
>Message: 6
>Date: Wed, 9 Oct 2013 06:52:24 +0000
>From: Nathan Ridge <zeratul976_at_[hidden]>
>To: Boost Mailing List <boost-users_at_[hidden]>
>Subject: Re: [Boost-users] Boost range iterator pointing to wrong
>	element
>Message-ID: <BLU180-W86DC037D4F20F360375A9C961D0_at_phx.gbl>
>Content-Type: text/plain; charset="iso-8859-1"
>
>>> struct to_include {
>>> bool operator()(const std::pair<bool,int>& x) {
>>> return x.first;
>>> }
>>> };
>> [...]
>>> /* reverse and then filter */
>>> auto rf = container_cpy | reversed | filtered(to_include());
>>> auto rf_it1 = rf.begin();
>>> auto rf_it2 = std::next(rf_it1);
>>> rf_it2->first = false;
>>
>> This is just a guess, but it strikes me as potentially dodgy to retain
>> iterators to a filtered sequence after modifying the result of the
>> filter predicate on that sequence. (This seems like something that
>> would invalidate iterators, just like certain collection modifications do.)
>
>Gavin is right. Filtered ranges assume that the value of the
>predicate on sequence elements does not change during the 
>iterator's lifetime. You are breaking that assumption, and so
>anything can happen.
>
>(I can't find any documentation about this assumption, 
>however. We should probably add some.)
>
>If you're wondering how the result that you're seeing comes
>about, it's like this:
>
>? - reverse_iterator stores an iterator of the underlying
>??? range not to the element it is pointing to, but to the
>??? next position. This is because there is a past-the-end
>??? iterator but not a before-the-begin one, so we need
>??? the begin() of the reversed range to store the end()
>??? of the underlying range, which, being the past-the-end
>??? iterator, is one position ahead of what the begin() of
>??? the reversed range is actually pointing to, which is
>??? the last actual element)
>? ? ? - so reverse_iterator's dereference operator calls
>? ?? ?? prior() on the stored underlying iterator to get the
>? ?? ?? underlying iterator we actually want to dereference.
>? - filter_iterator simply stores an iterator of the 
>??? underlying type to the element it is pointing to
>????? - so filter_iterator's dereference operator just
>??????? dereferences the underlying iterator.
>? - When the outer range is the reversed range, you
>??? dereference the reverse_iterator, which calls prior() 
>??? on the filter_iterator.
>? ? ? - prior() on a filter_iterator walks the range backwards
>? ?? ?? until an element matching the predicate is found.
>??????? since you've modified the (0, 2) element so it no
>??????? longer matches the predicate, it skips it and goes
>??????? on to the (1, 1) element, which is what you rr
>? - When the outer range is the filtered range, you
>??? dereference the filter_iterator which just derefernces
>??? the underlying reverse_iterator. No calls to the
>??? predicate are made, and (0, 2) element is returned.
>
>So to sum it up, the difference is referring to the current
>element of the filtered range in one case, and referring
>to the next element and calling prior() to get at the
>current element in the other case. The two are equivalent
>under the assumption that the predicate's value does not
>change while you're iterating.
>
>Regards,
>Nate 		 	   		  
>
>------------------------------
>
>Message: 7
>Date: Wed, 9 Oct 2013 11:15:05 +0100
>From: Patrick Steele <steele.patrick_at_[hidden]>
>To: boost-users_at_[hidden]
>Subject: Re: [Boost-users] [thread] Test if a thread is running
>Message-ID:
>	<CAFXDkHxGrupgH0+EfhzMHhLOs1SrDLEWveYy1vjDHMw34AJheA_at_[hidden]>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Thank you both for the help, joinable() seems to be exactly what I need :)
>Patrick
>
>
>On 8 October 2013 18:07, <christoph.kliemt_at_[hidden]> wrote:
>
>> Patrick Steele <steele.patrick_at_[hidden]> writes:
>>
>> > in order to test if a boost.thread is running I used timed_join as per
>> >
>> http://stackoverflow.com/questions/1667420/how-can-i-tell-reliably-if-a-boost-thread-has-exited-its-run-method
>> ,
>> > which recommended that I should be able to call timed_join with a wait
>> time
>> > of 0 ie
>> > bool isThreadRunning = ! m_Thread.timed_join( boost::get_system_time() );
>> > I have just upgraded to boost 1.54 to see that this no longer appears to
>> > work and that the timed_join function is being deprecated.
>> > Can you tell me how I should now check whether a thread is running
>> > please?
>>
>> In cases like this i use a flag that is set to "thread running" when its
>> enters its run method and to "thread ended" when the thread leaves its
>> run method; to signal a condition for another bookkeeper thread can be
>> an option.
>> All this depends on how accurate the answer has to be...
>>
>> regards Christoph
>>
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>-------------- next part --------------
>HTML attachment scrubbed and removed
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>Boost-users mailing list
>Boost-users_at_[hidden]
>http://lists.boost.org/mailman/listinfo.cgi/boost-users
>
>------------------------------
>
>End of Boost-users Digest, Vol 3590, Issue 1
>********************************************