- Boost-users - lists.boost.org

[Boost.dynamic_bitset] Help on extending dynamic_bitset
by Kobi Cohen-Arazi 12 May '06

12 May '06

Hi, boost-1.32.0-6 I would like to hear your suggestions regarding the ways to extend dynamic_bitset. Let's say that I have a different way to search for the next bit in the set. It is specific to my CPU arch. How can I extend find_first/find_next ? Since there is no way to retrieve the internal vector<>, It seems very hard to do so. Nothing is protected so Inheritance is out of the question, and there is not a single accessor that expose that vector<> (its best not to do so, but I'm just counting the options here). Am I missing another way of extending it? Thanks, Kobi.

1 0

[date_time] build error
by Leif Gruenwoldt 12 May '06

12 May '06

I have implemented a class ( lets call it LC2DateTime ) that uses boost date time in it's implementation. I also have a small test for this class and it builds nicely and runs properly. However when I include LC2DateTime.h in my larger project I get this odd build error that points me to /usr/include/boost/algorithm/string/detail/finder.hpp as the source of the error. ------------------ /usr/include/boost/algorithm/string/detail/finder.hpp: In member function 'boost::iterator_range<Iterator> boost::algorithm::detail::last_finderF<SearchIteratorT, PredicateT>::findit(ForwardIteratorT, ForwardIteratorT, std::forward_iterator_tag) const': /usr/include/boost/algorithm/string/detail/finder.hpp:150: error: expected unqualified-id before numeric constant /usr/include/boost/algorithm/string/detail/util.hpp: At global scope: /usr/include/boost/algorithm/string/detail/util.hpp:71: error: expected ',' or '...' before numeric constant /usr/include/boost/algorithm/string/detail/util.hpp: In function 'OutputIteratorT boost::algorithm::detail::bounded_copy(InputIteratorT, InputIteratorT)': /usr/include/boost/algorithm/string/detail/util.hpp:76: error: 'DestFirst' was not declared in this scope /usr/include/boost/algorithm/string/detail/util.hpp:77: error: 'DestLast' was not declared in this scope ---------------------- This bug has been bothering me for a while and I actually got my project to build again juggling the placement of of the '#include "LC2DateTime.h" above the other includes in my project. However this problem has reared it's head again and this time no amount of juggling of includes is getting me out of this. Any thoughts? Is this a problem with the boost libraries or my code? -- Leif Gruenwoldt Simulation Software Developer DLCSPM 4-4-3 (c) Building A31 CFB Kingston

2 6

Mailing lists to go down Saturday
by David Abrahams 12 May '06

12 May '06

-- Dave Abrahams Boost Consulting www.boost-consulting.com

1 0

a problem on boost::asio
by 李慧霸 12 May '06

12 May '06

I'm trying asio on WindowsXPSP2 + VS2003, and I found that there are always some connections established from 127.0.0.1:xxxx to 127.0.0.1:yyyy, is it a bug?

2 1

Re: [Boost-users] [Wave] effect of allocation of data structures oncopying data structures
by Hartmut Kaiser 12 May '06

12 May '06

> Andreas Sæbjørnsen wrote: > > > I need some advice regarding how I should copy the boost data > > structures I get from 'advanced_preprocessing_hooks.h'. > > The task at hand is to copy some of the data structures > from Wave and > > store it separate form the memory Wave allocates so that after the > > Wave preprocessing step has finished all it's memory can be freed. > > > > Example: e.g making a copy of the > > 'std::vector<std::list<PreprocessingInfo::token_type,boost::fa > > st_pool_allocator<PreprocessingInfo::token_type> > >' > > representing the arguments in the expansion of a macro in > the function > > 'expanding_function_like_macro'. > > > > Syntactically it would be gre at to be able to make a copy > using the > > operator=, but as far as I can see this is only possible if > I am also > > using the fast_pool_allocator. If I use the > fast_pool_allocator I am > > afraid that my copies will be put into the memory pool allocated by > > Wave and therefore that memory cannot be safely freed. Is > this corect? > > I'm not sure here. My (unverified) guess is, that the memory > pool will be free'd only after the last item allocated from > it got free'd. This shouldn't be a problem as long as the > memory pool doesn't live in a shared library which gets > unloaded prematurely. After looking at the code and the docs again I discovered the following: the boost::fast_pool_allocator is build on top of a thread local singleton pool. This pool gets allocated before entering main and gets free'd after main exits. Same should be true for shared libraries. So yes, you're running into problems only: 1) if you have your Wave application compiled into a shared library and 2) if you use data from the allocator used by Wave in a different module after the first shared library was explicitely unloaded from memory. HTH Regards Hartmut > But anyway, doesn't using std::copy() for the embedded > list<>'s allow to change to any adequate data structure? > > Regards Hartmut >

2 3

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 11 May '06

11 May '06

Hi Kobi, I am using ACE_Mutex. Let me check ACE Guards (I know there is ACE_Guard class), Is that what you mean? Thanks Priyank ________________________________ From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Kobi Cohen-Arazi Sent: Thursday, May 11, 2006 11:09 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [multi_index] Core dump in multi-index library !! Procedure * Procedure_Pool::find_by_id(int _id) { LD_TRACE("Procedure_Pool::find_by_id"); mutex_.acquire(); Procedure_By_Id::iterator it = procedure_by_id_.find(_id); if (it != procedure_by_id_.end()) { ACE_DEBUG((LM_DEBUG, "%N:%l Found procedure for id: %d \n", _id)); mutex_.release(); return *it; } ACE_DEBUG((LM_DEBUG, "%N:%l Not able to found procedure for id: %d \n", _id)); mutex_.release(); // return null return 0; } BTW, As a side note, I highly recommend you to use ACE Guards (RAII...) for the mutex thing. Kobi

2 1

MPL/Fusion
by Sohail Somani 11 May '06

11 May '06

Hi, I am quite interested in MPL/Fusion. I have made my own toy projects using template metaprogramming to make decisions at compile time. I am interested in learning what types of software boost users create with it. Would anyone care to share? Thanks! Sohail

3 2

Re: [Boost-users] [multi_index] thread safety
by JOAQUIN LOPEZ MU?Z 11 May '06

11 May '06

----- Mensaje original ----- De: george <george13p(a)yahoo.com> Fecha: Jueves, Mayo 11, 2006 7:27 pm Asunto: Re: [Boost-users] [multi_index] thread safety > hello Joaquin Hello George, > > > You have to lockguard every access to the container; note this > > also includes, for instance, container traversal with iterators, > > i.e. iterator displacement. Strictly speaking, iterator dereference > > should also be lockguarded, although I can say unofficially that > > unguarded dereference is OK. > > can you explain a litle more? > as I konw from STL, multiple readers is ok. Correct. > reading and inserting a new object does't invalidate iterators(for > pointer-based > conteiners offcourse,list, map etc...) Correct. This also holds for multi_index_containers. > > a concurrent read and insert in multi_index are not > (safely)possible? I mean there might be an iterator > invalidation? Concurrent reading and writing is not safe, but the issue has nothing to do with iterator invalidation. ...I think I've got a hunch about what you've got in mind. When I say that you've got to lockguard iterator displacement, what I mean is: consider a concurrent write operation and an iterator increment; this concurrency is not thread safe and undefined behavior results: a possible outcome is iterator invalidation, but you could also get an app crash, a corrupted data structure, an infinite loop or whatever. Tecnhically speaking, an invalid iterator is a perfectly legal state for an iterator to be in, which has nothing to do with undefined behavior resulting from violating thread safety guarantees. I'm not sure I made myself clear :) Insist on me if I didn't. > offcourse there is a chance for a 'dirty-read' but this for the > domain of the aplication if it is a problem and not for multi_index. I don't get what you mean here, would you care to elaborate? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

Re: [Boost-users] [multi_index] thread safety
by Joaquín Mª López Muñoz 11 May '06

11 May '06

Conway Allen ha escrito: > Regarding thread safety, if threads are concurrently reading, > inserting, and erasing entries in a multi-index container do you have to > lockguard all of these operations or can you get away with just > lockguarding the inserts and the deletes? You have to lockguard every access to the container; note this also includes, for instance, container traversal with iterators, i.e. iterator displacement. Strictly speaking, iterator dereference should also be lockguarded, although I can say unofficially that unguarded dereference is OK. The kind of thread-safety provided by B.MI (and by most STL implementations) is described at SGI docs: http://www.sgi.com/tech/stl/thread_safety.html > Thanks, Allen. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Re: [Boost-users] [multi_index] Core dump in multi-index library !!
by Patel Priyank-PPATEL1 11 May '06

11 May '06

Hi Joaquin, I have put some locks in code and follows is the changed code. Also, I have removed API that takes procedure pointer. Instead it just takes id as input. Anyways, It seems to be working GREAT. Thanks for all your help. Will contact you incase of any problems. #include "../include/Procedure_Pool.h" int Procedure_Pool::add_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::add_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "ADDING %d\n", _procedure->id())); if (find_by_id(_procedure->id()) == 0) { // procedure not found mutex_.acquire(); procedure_by_id_.insert(_procedure); mutex_.release(); // debug info ACE_DEBUG((LM_DEBUG, "Added procedure : %d \n", _procedure->id())); // return success return 0; } else { // error ACE_ERROR((LD_ERROR "%N:%l Error in adding procedure : %d \n", _procedure->id())); // return failure return -1; } } int Procedure_Pool::remove_by_id(Procedure * _procedure) { LD_TRACE("Procedure_Pool::remove_by_id"); ACE_ASSERT(_procedure != 0); ACE_DEBUG((LM_DEBUG, "REMOVING: %d \n", _procedure->id())); if (find_by_id(_procedure->id()) != 0) { // procedure found mutex_.acquire(); procedure_by_id_.erase(_procedure->id()); mutex_.release(); ACE_DEBUG((LM_DEBUG, "Removed procedure : %d \n", _procedure->id())); return 0; } else { ACE_ERROR((LD_ERROR "%N:%l Error in removing procedure : %d \n", _procedure->id())); return -1; } } Procedure * Procedure_Pool::find_by_id(int _id) { LD_TRACE("Procedure_Pool::find_by_id"); mutex_.acquire(); Procedure_By_Id::iterator it = procedure_by_id_.find(_id); if (it != procedure_by_id_.end()) { ACE_DEBUG((LM_DEBUG, "%N:%l Found procedure for id: %d \n", _id)); mutex_.release(); return *it; } ACE_DEBUG((LM_DEBUG, "%N:%l Not able to found procedure for id: %d \n", _id)); mutex_.release(); // return null return 0; } Thanks, Priyank -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of JOAQUIN LOPEZ MU?Z Sent: Wednesday, May 10, 2006 4:36 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [multi_index] Core dump in multi-index library !! ----- Mensaje original ----- De: Patel Priyank-PPATEL1 <priyankpatel(a)motorola.com> Fecha: Miércoles, Mayo 10, 2006 10:49 pm Asunto: Re: [Boost-users] [multi_index] Core dump in multi-index library !! > Hi Joaquin, [...] > One other thing, addition and deletionIs done by separate threads in > my application. Oh, oh. multi_index_container is *not* thread safe, so this smells like the problem --and it is not, it certainly has the potential to crash your app sooner or later. Please take into account thread unsafety extends to every member function of multi_index_container, so you'd better lockguard *every* public method of Procedure_Pool. Looking fwd to knowing your results. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo In case you're wondering, STL implementations typically have the same level of thread safety as B.MI provides: 1. Concurrent access to different containers is safe. 2. Concurrent read-only access to the same container is safe. The rationale is that locking every public method of an STL container adds an unavoidable runtime overhead (you might not need it), and moreover it doesn't necessarily map to what constitutes *atomicity* to a given app --in your case, for instance, atomicity, and thus lockguarding, is best done at the level of Procedue_Pool interface. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

3 2