- Boost-users - lists.boost.org

Re: [Boost-users] [lambda] if-then-else construct gets broken bylambda-lib
by Nat Goodspeed 07 Nov '06

07 Nov '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Sebastian Weber > Sent: Tuesday, November 07, 2006 12:41 PM > To: boost-users(a)lists.boost.org > Subject: [Boost-users] [lambda] if-then-else construct gets broken > bylambda-lib > > I'm trying to store a reference to a function depending upon a condition > within a function object like this: > > boost::function< double (std::size_t) > wf = (sIndex < m_maxIndex+1) ? > ( boost::lambda::bind(boost::ref(m_cf), sDeg, boost::lambda::_1) ) : > ( boost::ref(*m_wf) ); [Nat] Does it work better if the 'else' clause is something more like: ( boost::lambda::bind(boost::ref(*m_wf)) ) ? This is a wild guess, but boost::ref() isn't by itself a lambda bind expression -- is it? Both halves of the ternary operator are convertible to boost::function -- but they're not the same type. I don't know whether two different boost::lambda::bind expressions are going to be compatible either. You may have to explicitly instantiate boost::function objects on both sides of the : -- which would end up being less terse than writing the if/else statement. But it seems worth a try.

2 1

Serialization with polymorphic_*_archive and BOOST_CLASS_EXPORT
by Anders Wang Kristensen 07 Nov '06

07 Nov '06

Hi, I'm having trouble serializing through the a pointer to the base as shown below. If I manually register class B with template register_type<B>() it works, but I would rather use the BOOST_CLASS_EXPORT macros since that is more convenient. Unfortunately BOOST_CLASS_EXPORT assumes you are using the templated version of serialize, and not polymorphic_iarchive/oarchive, that I'm using. Anyone know how to get around that problem? Thanks! -- wang Example: #include <boost/archive/polymorphic_text_iarchive.hpp> #include <boost/archive/polymorphic_text_oarchive.hpp> #include <boost/archive/polymorphic_xml_iarchive.hpp> #include <boost/archive/polymorphic_xml_oarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/export.hpp> struct A { void serialize(boost::archive::polymorphic_iarchive & ar, const unsigned int file_version); void serialize(boost::archive::polymorphic_oarchive & ar, const unsigned int file_version); int data; bool operator==(const A & rhs) const { return data == rhs.data; } A() : data(0) {} virtual ~A() = 0 {} }; void A::serialize( boost::archive::polymorphic_iarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_NVP(data); } void A::serialize( boost::archive::polymorphic_oarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_NVP(data); } struct B : public A { void serialize(boost::archive::polymorphic_iarchive & ar, const unsigned int file_version); void serialize(boost::archive::polymorphic_oarchive & ar, const unsigned int file_version); int foo; bool operator==(const B & rhs) const { return data==rhs.data && foo==rhs.foo; } B() : foo(2) {} }; void B::serialize( boost::archive::polymorphic_iarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(A); ar & BOOST_SERIALIZATION_NVP(foo); } void B::serialize( boost::archive::polymorphic_oarchive & ar, const unsigned int file_version ){ ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(A); ar & BOOST_SERIALIZATION_NVP(foo); } BOOST_CLASS_EXPORT(B) int main(int argc, const char* argv[]) { boost::shared_ptr<A> a(new B); boost::shared_ptr<A> b; { std::stringstream ss; { boost::archive::polymorphic_text_oarchive oa(ss); //oa.template register_type<B>(); oa << BOOST_SERIALIZATION_NVP(a); } { boost::archive::polymorphic_text_iarchive ia(ss); //ia.template register_type<B>(); ia >> BOOST_SERIALIZATION_NVP(b); } } B* x = dynamic_cast<B*>(a.get()); B* y = dynamic_cast<B*>(b.get()); assert(*x == *y); return 0; }

2 4

Re: [Boost-users] Serialization problem on 64-bit Windows release
by Сергей Филиппов 07 Nov '06

07 Nov '06

Robert Ramey <ramey <at> rrsd.com> writes: > > Is it possible that this might be related to the recently discovered fact > (at least by me) versions of the serialization library are, contrary to > intention, not thread safe? That is, conflict occurs when multiple threads > are using serilization even with different archive instances due to the fact > that they share the same gobal extended_type_info table. This has been > addressed - and hopefully remedied in 1.35. > > Robert Ramey What does it mean that the serialization library is "not thread safe"? Does it mean that the serialization must be used in one thread only or the serialization can be used in different, non-concurrent threads? I'm not familiar with the serialization library internals so it's hard to me to make a guess where it is related to my case. My application is an RPC server that supports only one client connection. The client establishes connection, makes some calls to the server and exits. Each call can generate "events" that are stored on the server in a vector. After a call the client may call the server's function SerializeEvents which serializes the vector into buffer and transmits the buffer to the client. Actual serialization code is straightforward. void CEventLogger::Serialize(std::vector<BYTE>* pBuffer) { std::stringstream stream; boost::archive::text_oarchive ar(stream); ar & m_Events; std::string str(stream.rdbuf()->str()); if(str.length()) { BYTE *pBuf = reinterpret_cast<BYTE*>(const_cast<char*>(str.c_str())); pBuffer->assign(pBuf, pBuf + str.length()); } else pBuffer->clear(); } The client communicates with the server in one thread only. So the functions that are populating m_Events and CEventLogger::Serialize are called in different threads, but these calls are serialized. What you think? Can "not thread safety" be a reason in my case? Thanks, Sergey (Sorry, I forget to mention I'm using boost 1.33.0.)

2 1

fpclassify
by Johan Råde 07 Nov '06

07 Nov '06

Ignore my last message. It was sent by mistake. --Johan

1 0

fpclassify
by Johan Råde 07 Nov '06

07 Nov '06

Olivier, Håkan, Kan ni testa den här? Fungerar den här, så får den bli den slutgiltiga versionen. --Johan

1 0

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Goroll, Torsten 07 Nov '06

07 Nov '06

Hi, thank you all for your help. It was a basically missunderstanding of join() on my side. The message of Nat Goodspeed helped me to discover that. So, lets close this thread. Torsten -----Ursprüngliche Nachricht----- Von: Ovanes Markarian [mailto:om_boost@keywallet.com] Gesendet: Dienstag, 7. November 2006 00:29 An: boost-users(a)lists.boost.org Betreff: Re: [Boost-users] [Threads] Problem with starting a sub thread An additional approach could be a thread group, which can create a bunch of threads. Than you can call join on entire group, where the caller thread blocks until all threads are finished. -----Original Message----- From: Nat Goodspeed [mailto:ngoodspeed@solidworks.com] Sent: Monday, November 06, 2006 5:57 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

[Serialization] Need help resolving problem putting serialization code into static library
by Mark Melton 07 Nov '06

07 Nov '06

All, I am hoping someone can help me resolve a problem I am having putting serialization code into a static library. If I am lucky, it will be simple user error. Here is a quick synopsis of the code: a.hpp class A { virtual ~A() { } ...} b.hpp class B : public A { virtual ~B() { } ... } with classes A and B both having the standard serialization functions defined in a.cpp and b.cpp respectively along with the necessary BOOST_CLASS_EXPORT statements. Now, compiling a single program like this works fine and the program is able to serialize objects of types A and B through pointers of type A without any problems. Life is good. g++ -o my_prog my_prog.cpp a.cpp b.cpp -lboost_serialization However, compiling a static library and then linking the same program like this produces a my_prog that gets an unregistered_class exception when trying to serialize an object of type B through a pointer of type A. Not what I expected because the only difference is in the linking phase where code is now coming from the library instead of the object files. g++ -o a.o -c a.cpp g++ -o b.o -c b.cpp ar cru a.o b.o libmine.a ranlib libmine.a g++ -o my_prog my_prog.cpp libmine.a -lboost_serialization Now, combining a.cpp and b.cpp and building the library produces a working program. Confusion reigns. g++ -o ab.o -c a.cpp b.cpp ar cru ab.o libmine.a ranlib libmine.a g++ -o my_prog my_prog.cpp libmine.a -lboost_serialization Any ideas would be greatly appreciated. I have tried several incantations, but I cannot make any headway. I am working under the assumptions that it has something do to with the initialization code difference between using the object files and the library. I am using boost 1.33.1 on intel OS X 10.4.8 with g++ in 64 bit mode. If it would be useful, I can run experiments in 32 bit mode or on Ubuntu, but I have yet to find any differences with this issue. Thanks, mark

2 1

Global Mutex
by Daher 07 Nov '06

07 Nov '06

Hi, How do I create a global mutex in boost.threads ? Dee

3 3

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Ovanes Markarian 06 Nov '06

06 Nov '06

An additional approach could be a thread group, which can create a bunch of threads. Than you can call join on entire group, where the caller thread blocks until all threads are finished. -----Original Message----- From: Nat Goodspeed [mailto:ngoodspeed@solidworks.com] Sent: Monday, November 06, 2006 5:57 PM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of Goroll, Torsten > Sent: Monday, November 06, 2006 11:46 AM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Threads] Problem with starting a sub thread > > I understood and experienced that the main thread blocks. But how can it > join > other threads, if it is blocked? That doesn't seem consistent to me. [Nat] Usually one wouldn't create a thread and then immediately join() it. The net effect of that would seem to be an expensive function call. Usually if you want a new thread to run in parallel with the thread that created it, you let both threads run for a while before one thread attempts to join() the other. _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

1 0

Re: [Boost-users] [Threads] Problem with starting a sub thread
by Goroll, Torsten 06 Nov '06

06 Nov '06

Thanks for the quick answers. I understood and experienced that the main thread blocks. But how can it join other threads, if it is blocked? That doesn't seem consistent to me. Torsten > > > Hi! > > join cause a calling thread to block until the second one is finished. This is also stated in the > docs: > 1.void join(); > Requires: *this is joinable. > !!!!!Effects: The current thread of execution blocks until the initial function of the thread of > execution represented by *this finishes and all resources are reclaimed. > Notes: If *this == thread() the result is implementation-defined. If the implementation > doesn't detect this the result will be deadlock.

2 1