- Boost-users - lists.boost.org

boost::algorithm::join
by Maxim Volkov 21 Dec '06

21 Dec '06

Hi, all. Why there is no boost::algorithm::join in boost_1_33_1. There's no join.hppfile at all. But it is decribed in the documentation. So what's wrong? And where can I get a version with this algorithm?

2 2

Re: [Boost-users] [Threads-devel] Idea for a boost::barrier::scoped_wait class
by Tim Day 20 Dec '06

20 Dec '06

On Tue, 2006-12-19 at 10:40 -0500, Stuart A. Malone wrote: > However, I don't think that join_all() is an option in this case, > because I need to be inside a Mac event loop in order to receive the > messages that will launch the additional threads. Since join_all() > would block until the existing threads had completed, I would never > receive the events telling me that I needed to launch additional > threads. [Diverting to boost-users because this regards boost-threads usage, not development]. You might find the attached code interesting as an example of how things could be structured. The loop in main() spends most of it's time blocked on a getc call (which would presumably correspond to some sort of event pump in your app), but a separate thread (the "master") manages a pool of worker threads (initially 1; another one is added each time you hit return on the console). Each thread runs for 10s printing '.' every second then terminates; if the worker count reaches zero the master terminates too. To be concise the code uses volatile bools to communicate state between threads; in any sort of real code these would probably be mutex-protected structures or std::deques. The real key to the whole thing is the boost::condition, which allows the master thread to notice both keypresses from main() and completing workers. Note there's no boost::barriers to be seen. [Attached code compiles with gcc threadmaster.cpp -o threadmaster \ -g -pthread -lboost_thread -lpthread on Debian Sarge with appropriate boost packages installed]. Tim

1 0

[Graph] Python BGL memory leak (or not...)
by Hugo Ferreira 20 Dec '06

20 Dec '06

Hi, It seems I'm having a memory leak after calling dijkstra_shortest_paths several times. Either I'm wrong, or the predecessor_map is not being deleted. The call I have is something like this: p = self.graph.vertex_property_map('vertex') boost.dijkstra_shortest_paths(self.graph, self.vertexes[src], predecessor_map = p, weight_map = self.weights) Then I manipulate p to get the shortest_path between two points, and exit the function. Still, even after a gc.collect(), the memory keeps getting bigger (and because my graph has about 1 million vertexes, it gets REALLY bigger). Any thoughts on how to force the memory allocation for the predecessor_map? Thanks in advance, Hugo Ferreira -- GPG Fingerprint: B0D7 1249 447D F5BB 22C5 5B9B 078C 2615 504B 7B85

2 1

Re: [Boost-users] BOOST_ASSERT and others
by Maarten Nieber 20 Dec '06

20 Dec '06

Sorry, I should have checked! It should be: assert( 2 + 2 == 4 && "Adding numbers failed!" ) Maarten ----- Original Message ---- From: David Abrahams <dave(a)boost-consulting.com> To: boost-users(a)lists.boost.org Sent: Friday, December 15, 2006 5:19:05 PM Subject: Re: [Boost-users] BOOST_ASSERT and others Maarten Nieber <hallomaarten(a)yahoo.com> writes: > I use the trick > > assert( 2 + 2 == 4 || "Adding numbers failed!" ) > > This will probably work for BOOST_ASSERT as well. Are you sure about that || ? Looks to me like it would never fire. -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

5 5

Re: [Boost-users] Problem with multi_index and shared_ptr
by johneddy101＠comcast.net 20 Dec '06

20 Dec '06

Joaquin, Thanks for the quick response and the quick fix. I inserted your new code and everything seems to be fine. Prior to inserting the code, I was doing 150,000 insertions and subsequent erasures from a container. It would always fault at some point during the erasures but exactly where was unreliable. It does not seem to fault now even if I bump it up to 1,500,000 which is very strong evidence that your solution has worked. Thanks again for the great lib, John Joaquín Mª López Muñoz ha escrito: Hello John, johneddy101 <at> comcast.net ha escrito: I'm running into a problem while using hashed indices in a container storing shared_ptr's. The problem is occuring in the hashed_index::erase(key) method in both the 1_33_1 release and the CVS head version. This is what the problem seems to be: It is possible that the call to erase (or final_erase_) occurring within the do loop causes destruction of the passed in key object. The key object (k) is then used in a comparison in the while portion of the loop (y!=x&&eq(k, key())). The default predicate uses == in this comparison but one of the items (the left hand side) will have already been destroyed. Umm... Thank you for spotting this, indeed the key passed to erase() can become invalid during the process if it physically belongs to one of the elements to be erased. Matter of fact, the problem is not specifically related to shared_ptr's. I don't know if it's too late to try to fix this on time for Boost 1.34; in case I find the time and permission to do it I'll let you know. An update on this. The following rewrite of erase(key) in hashed_index.hpp should clear the problem: size_type erase(key_param_type k) { BOOST_MULTI_INDEX_HASHED_INDEX_CHECK_INVARIANT; size_type s=0; std::size_t buc=buckets.position(hash(k)); hashed_index_node_impl* x=buckets.at(buc); hashed_index_node_impl* y=x->next(); while(y!=x){ if(eq(k,key(node_type::from_impl(y)->value()))){ bool b; do{ hashed_index_node_impl* z=y->next(); b=z!=x&&eq( key(node_type::from_impl(y)->value()), key(node_type::from_impl(z)->value())); this->final_erase_( static_cast<final_node_type*>(node_type::from_impl(y))); y=z; ++s; }while(b); break; } y=y->next(); } return s; } Would you mind pasting this into your local copy of hashed_index.hpp (CVS version) and report whether your prior problems get solved? I'm writing a testcase for the issue and running my entire regression tests, if everything goes OK I think I'll be able to commit this into the CVS before the week ends. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

lambda parse tree access
by Sascha Krissler 20 Dec '06

20 Dec '06

Hello, i am writing a multiple dispatch framework and as i am feeling scientific i am gonna try to add a predicate dispatch fearure to it. For that i need to build big nested expression template instances that represent the predicates, so that i cant evaluate them at the time of method invocation. As an additional feature i want to sort the predicates for specifity (one predicate is true at a subset of cases of another predicate and is as such more specific) and for that i need access to the parse tree of a lambda expression. Is there documentation available on this topic and does lambda have a public interface for that? Does it make sense to use lambda as a library for writing expression template algorithms? Thanks in advance

5 6

Re: [Boost-users] Problem with multi_index and shared_ptr
by Joaquín Mª López Muñoz 20 Dec '06

20 Dec '06

Hello John, johneddy101(a)comcast.net ha escrito: > I'm running into a problem while using hashed indices in a container > storing shared_ptr's. > The problem is occuring in the hashed_index::erase(key) method in both > the 1_33_1 > release and the CVS head version. This is what the problem seems to > be: > > It is possible that the call to erase (or final_erase_) occurring > within the do loop > causes destruction of the passed in key object. The key object (k) is > then used in a > comparison in the while portion of the loop (y!=x&&eq(k, key())). The > default predicate uses > == in this comparison but one of the items (the left hand side) will > have already been destroyed. Umm... Thank you for spotting this, indeed the key passed to erase() can become invalid during the process if it physically belongs to one of the elements to be erased. Matter of fact, the problem is not specifically related to shared_ptr's. I don't know if it's too late to try to fix this on time for Boost 1.34; in case I find the time and permission to do it I'll let you know. > I'm afraid that I don't know a good solution to this problem. I see > from your commit > logs on this file that there is a problem using something like is done > in the ordered_indices > (deleting equal_range items) whereby it increases the complexity. I > can see from the > implementation of equal_range on hashed indices that this is a > potentially expensive > operation for non-unique collections with many collisions. However, > since speed is a > secondary consideration for me, this is the solution I'm using for > now. > Do you mean that instead of c.erase(k); you do the following? std::pair<iterator,iterator> p=c.equal_range(k); c.erase(p.first,p.second); This is a viable solution. The potential performance problem you point out is actually present in both methods. On the other hand, the different problem I talk about in the commit logs only affects to erase(first,last), not erase(k), and is exposed here: http://open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2023.pdf An alternative solution is to do the following: c.erase(key_type(k)); i.e. doing an external copy of the key before calling erase(k). This is the solution I'd use if your keys are cheap to copy. > Thanks, > > John Thank you for reporting, good luck with your project. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 1

[boost.multiindex] Recommended way of having a list of keys to a multi-index container
by Charles Tolman 20 Dec '06

20 Dec '06

Hi, Boost newbie question regarding indexing of multi_index_containers. First a great big thank you to Joaquín M López Muñoz for sorting this library out. Lovely job. OK I have a question about indexing. Probably one for Joaquin. I have a structure that can be indexed on the following keys: 0: identity -- unique - this is fine. 1: int position; -- non_unique - this is fine. 2: int priority; -- non_unique - this is also fine. 3: vector<MyStringType> -- non_unique - but NOT fine. So number 3 is the problem. Am I right in thinking that the multi_index_container does not handle this case? i.e. where you would want a given SINGLE element to be indexed on a variable (unknown) number of keys, in this case as many strings as are in the vector. Although strictly they are not actually separate keys, there is just one non-unique key, but a given element can have multiple instances for this one key. Of course I can workaround this by having another structure to handle this or alternatively wrap up the element a multiple number of times, as many as required by the length of the vector of strings. But I was wondering if there are any ways of handling this in the basic library. Apologies if I have missed something and it is in an FAQ somewhere, although I have done an initial search. TIA Charles Tolman

2 2

[Serialization] Boost 1.33 serialization const problem
by vermaaso 20 Dec '06

20 Dec '06

Hello list, currently I am trying to get serialization to work. It worked well when I was using boost 1.32, but since I upgraded to 1.33 I'm having some problems. In short; I have an abstract base class and a derived class. I try to serialize/deserialize the derived class through a pointer to the base class. This worked well when I was using 1.32. When I upgraded to 1.33 I got the static assert which trapped the 'saving non const error' (I hope this makes sense ..). So I fixed it by following instructions from other posts dealing with the same problem (basically just by changing 'base *b' to 'const base * const b'). The fix resolved the compile error, only now I'm getting a segfault at runtime. The segfault happens during deserialization (when trying to 'reconstruct' the original object). The funny thing is, I've tested it on a system (suse enterprise system 9, gcc 3.3.3) and it chrashes. On another system (gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)) it works fine. I reproduced the problem in a very small program located at the end of this post. Maybe someone can have a look at the code and tell me whether there are obvious problems with my code or not. If I know for sure that my code should run correctly, I'll just move on to an other linux distro .. Thanks in advance, Oscar #include<boost/archive/text_oarchive.hpp> #include<boost/archive/text_iarchive.hpp> #include<boost/serialization/base_object.hpp> #include<boost/serialization/export.hpp> #include<iostream> #include<sstream> using namespace std; class base { public: virtual void do_it() const = 0; private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int){ cout << "serializing base" << endl; } }; class derived: public base { public: derived(int field1, string field2){ _field1 = field1; _field2 = field2; } virtual void do_it() const { cout << "doing it with " << _field1 << " and " << _field2 << endl; } private: friend class boost::serialization::access; derived(){}; virtual ~derived(){}; template<class Archive> void serialize(Archive & ar, const unsigned int){ cout << "derived being serialized" << endl; ar & boost::serialization::base_object<base>(*this); ar & _field1; ar & _field2; } int _field1; string _field2; }; BOOST_IS_ABSTRACT(base); BOOST_CLASS_EXPORT(derived); string serialize(const base * const b){ stringstream str; boost::archive::text_oarchive oa(str); oa << b; return str.str(); } base *deserialize(string s){ stringstream str(s); base *b; boost::archive::text_iarchive ia(str); ia >> b; return b; } int main(){ base *d1 = new derived(52,"a string"); d1->do_it(); string serialized = serialize(d1); base *d2 = deserialize(serialized); d2->do_it(); return 0; }

2 10

signals and threads
by Noah Roberts 20 Dec '06

20 Dec '06

The boost::signals library faq says that the library is not thread safe and is in fact dangerous. Does anyone know why? What are the implications of using the signals library in a threaded environment? Would I be better off implementing an event or observer architecture with boost::function instead? thanks

1 0