December 2010 - Boost-users - lists.preview.boost.org

[Interprocess] Strange behaviour on erase in a b::i::vector of b::i::weak_ptr
by Gaetan Gaumer 17 Dec '10

17 Dec '10

Hello Ion and others, I currently work with b::i::vectors storing b::i::managed_weak_ptr on objects created in a fixed_managed_shared_memory. I add shared_ptr whith push_back, but when I want to remove a weak_ptr using erase, the last item is erase instead of the one I want to remove. In the sample code below I add 3 objects and try to remove the middle one in both a vector of shared_ptr and a vector of weak_ptr : interprocessWeakVectorTest.cc http://pastebin.com/yDCngGw4 The result is the expected one for vector of shared_ptr, but not for a vector of weak_ptr : foo_shared_vector: 1 3 foo_weak_vector: 1 2 A tried the same with std::vectors of boost::shared_ptr and boost::weak_ptr (sample code below) : weakVectorTest.cc http://pastebin.com/fMEi0iaA The result is the expected one for both : foo_shared_vector: 1 3 foo_weak_vector: 1 3 I don't understand the behaviour of erase on b::i::vector of b::i::weak_ptr. Is this some kind of bug or am I doing something wrong ? For information I'm doing the same kind of thing with b::i::maps of b::i::shared_ptr and b::i::weak_ptr and the behaviour is correct. I compile this with : g++44 (GCC) 4.4.0 20090514 (Red Hat 4.4.0-6), and the 1.44 release of boost (but nothing in the 1.45 release note seems related to this), using options : -std=c++0x -lrt I don't know why but when I remove -std=c++0x this do not compile anymore even if I don't think I use any c++0x feature (am I ?). Can you check this or explain me my error ? Thank you. Gaëtan

1 1

Re: [Boost-users] mpi/serialization: broadcast function and the value argument
by Hicham Mouline 17 Dec '10

17 Dec '10

>-----Original Message----- >From: "Matthias Troyer" [troyer(a)phys.ethz.ch] >Date: 16/12/2010 03:20 PM >To: "Hicham Mouline" >Subject: Re: [Boost-users] mpi/serialization: broadcast function and the value argument >On Dec 16, 2010, at 10:54 PM, Hicham Mouline wrote: >> 1.44 >> As I wrote, I am able to debug deep into boost mpi and archive. >> Please let me know if I should send any more stacks or other data, >> >Please try with 1.45. Pointer serialization in Boost.MPI has been broken in 1.44 due to changes in Boost.Serialization. >Matthias This is fantastic. It does indeed work. I don't need the clobbered variant solution anymore. regards,

2 1

multivariate random variables
by Stefano Gallo 17 Dec '10

17 Dec '10

Hi Folks, I am new here. I would like to ask whether exist or not something which could help me. My problem is the following. I have a vector of mean values (size N) and a covariance matrix (size NxN). I would like to generate a vector of normal random variables. Thanks for your help. Stefano Gallo

2 1

(boost serialization) wstring portability issue
by Arash Abghari 16 Dec '10

16 Dec '10

Hi, I wonder if there is a way to have wstring portable between Windows and Linux. To be more elaborative consider the following code: wstring s(L"abcd"); std::ofstream ofs("./my_archive",std::iostream::binary); boost::archive::text_oarchive oa(ofs); oa << s; the file my_archive under Linux looks like this: $ xxd my_archive 0000000: 3232 2073 6572 6961 6c69 7a61 7469 6f6e 22 serialization 0000010: 3a3a 6172 6368 6976 6520 3520 3420 6100 ::archive 5 4 a. 0000020: 0000 6200 0000 6300 0000 6400 0000 ..b...c...d... while under Windows it looks like: $ xxd my_archive 0000000: 3232 2073 6572 6961 6c69 7a61 7469 6f6e 22 serialization 0000010: 3a3a 6172 6368 6976 6520 3520 3420 6100 ::archive 5 4 a. 0000020: 6200 6300 6400 b.c.d. as expected it reserved 4 bytes for each character under Linux while 2 bytes under Windows. Thus the archive file created under Linux is not loadable under Windows and vice versa. So my question is if there is a workaround or solution to this problem? By the way I am using boost 1.40 , gcc 4.3.4 and VC 9.0. Thanks, Arash

2 2

weak_ptr::lock is not thread safe
by Dmytro Ovdiienko 16 Dec '10

16 Dec '10

Hi All, I've just realized weak_ptr::lock is not thread safe. Is it expected behavior? Following sample reproduced this conclusion. #include <iostream> #include <boost/shared_ptr.hpp> #include <boost/thread.hpp> #include <boost/weak_ptr.hpp> #include <boost/interprocess/detail/atomic.hpp> #include <boost/interprocess/sync/interprocess_semaphore.hpp> static volatile int v = 0; boost::interprocess::interprocess_semaphore s1(0); boost::interprocess::interprocess_semaphore s2(0); boost::interprocess::interprocess_semaphore s3(0); class SomeClass{ public: boost::shared_ptr<SomeClass> s_this_; boost::weak_ptr<SomeClass> w_this_; SomeClass() { s_this_.reset( this ); w_this_ = s_this_; v = 1; } void release() { s_this_.reset(); } ~SomeClass() { v = 0; } }; SomeClass *c; void worker() { int counter = 0; for( ;; ) { s1.wait(); // wait for created object boost::weak_ptr<SomeClass> w = c->w_this_; // make weak ptr s2.post(); // let main thread go ahead boost::shared_ptr<SomeClass> s = w.lock(); // create shared_ptr from weak_ptr if( s ) // test for valid shared_ptr { if( 0 == v ) // if 0, object is destroyed { std::cout << "!!!!!!!! : " << counter << std::endl; exit(1); } } s3.post(); // notify main thread about test completion ++counter; } } int main() { boost::thread t = boost::thread( &worker ); for( ;; ) { c = new SomeClass(); // create object s1.post(); // notify thread about new object s2.wait(); // wait for thread to make weak_ptr c->release(); // destroy object s3.wait(); // wait for thread complete } return 0; } Best regards. Dima -- Dmytro Ovdiienko

3 3

boost::interprocess xsi_shared_memory
by Christian Hoffmann 16 Dec '10

16 Dec '10

Hi all, I try to use xsi (SysV) shared memory of boost::interprocess library, but I haven't found a way to use it through managed_shared_memory interface. Is the code in interprocess/detail/xsi_shared_memory.hpp and interprocess/detail/xsi_shared_memory_device.hpp deprecated? There's also some class declaration "managed_xsi_shared_memory" in interprocess/interprocess_fwd.hpp but I haven't found an implementation. Is this supposed to work somehow? Or can I only use it as-is? If yes, why is this then only available in detail namespace? Am I doing something wrong? Kind regards, Chris

2 1

Handling mulitiple boost versions
by Robert Jones 16 Dec '10

16 Dec '10

As I'm sure is common I write code that builds under several versions of Boost which often results in code like... #if (BOOST_VERSION < 103400) do this #else do that #endif This is specifically true for changes to Boost.Filesystem, but also in other places. Usually the difference being addressed is obvious, but not always, and in any case direct use of "103400" seems to be like a magic number to me. So, I'd like to do something like this in a global header (in one place for many versions and capabilities) #if (BOOST_VERSION < 103400) #define BOOST_PRE_FILESYSTEM_RATIONALISATION #endif and then say #ifdef BOOST_PRE_FILESYSTEM_RATIONALISATION do this #else do that #endif Is this unwise for any reason I'm not seeing, and are the tokens I'm defining already defined somewhere, so I can use those instead? Thx - Rob.

2 1

BGL: count parallel edges between vertices (u,v)
by Shaun Jackman 16 Dec '10

16 Dec '10

Hi, Is there a function to count the number of edges between two vertices (u,v)? In the case of parallel edges, this function could return values larger than one. Thanks, Shaun

2 1

Re: [Boost-users] mpi/serialization: broadcast function and the value argument
by Hicham Mouline 16 Dec '10

16 Dec '10

-----Original Message----- From: "Matthias Troyer" [troyer(a)phys.ethz.ch] Date: 13/12/2010 09:57 PM To: "Hicham Mouline" CC: boost-users(a)lists.boost.org Subject: Re: [Boost-users] mpi/serialization: broadcast function and the value argument >> mpi::broadcast() appears to be incapable of sending the argument "value" in a polymorphic way, ie: >> >> sender------------------- >> Base* base; >> If I call boost::mpi::broadcast(..., base, ...) >> >> >> receiver----------------- >> Base* base; >> boost::mpi::broadcast(..., base, ...) >> This does not construct the most derived type of base on the heap and make base point there, as serialization would do. >Did you register the most derived type? Yes I have all types. >Did you test whether pointer deserialization works with other serialization archives? >Matthias I will test. However, this code from boost\mpi\collectives\broadcast.hpp (see where I put the comment marker) // We're sending a type that does not have an associated MPI // datatype, so we'll need to serialize it. Unfortunately, this // means that we cannot use MPI_Bcast, so we'll just send from the // root to everyone else. template<typename T> void broadcast_impl(const communicator& comm, T* values, int n, int root, mpl::false_) { if (comm.rank() == root) { packed_oarchive oa(comm); for (int i = 0; i < n; ++i) oa << values[i]; broadcast(comm, oa, root); } else { packed_iarchive ia(comm); broadcast(comm, ia, root); for (int i = 0; i < n; ++i) ia >> values[i]; /////////////////////////////////////////////////////////////////// } } template<typename T> void broadcast(const communicator& comm, T& value, int root) { detail::broadcast_impl(comm, &value, 1, root, is_mpi_datatype<T>()); } template<typename T> void broadcast(const communicator& comm, T* values, int n, int root) { detail::broadcast_impl(comm, values, n, root, is_mpi_datatype<T>()); } If at the receiver process, I pass a non initialized Base*, it crashes as far as I could see. PS: I've cc'ed the email in the comments for that file as well. regards,

2 4

[units] check if quantities are convertible one into the other
by alfC 15 Dec '10

15 Dec '10

Hi, I have two (or more) default (or user defined) system units. For certain operations I assume that one quantity in one system can be converted into another quantity in some other system with the same dimension. What conversions are allowed depend on the included headers at best. What is the best way to check at compile time that one quantity can be converted into another? For example, I have this function that sums two quantities with the same dimension and returns the result of the left term. The function assumes that qright is convertible to qleft. If it is not convertible I would like to catch the error early with static_assert (or even with some enable_if to ignore the function) template<class Dimension, class LeftSystem, class RightSystem> quantity< unit<Dimension, LeftSystem> > sum_to_left( quantity< unit<Dimension, LeftSystem> > const& qleft, quantity< unit<Dimension, RightSystem> > const& qright ){ return boost::units::operator + (qleft, quantity< unit<Dimension, LeftSystem> >(qright)); } Thank you, Alfredo

3 4