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

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

boost::regex_search upgrade from 1_36 to 1_45
by EricB 15 Dec '10

15 Dec '10

Hi I have upgraded my boost to 1_45 (it was 1_36) and since then I have an error on boost::regex_search here is the code std::string regexp = "\\^:\\([^;^]*\\);\\([^;^]*\\);\\([^^]*\\)\\^:"; boost::regex expression( regexp.c_str() , boost::regex::basic|boost::regex::icase ); std::string::const_iterator it_prev = str.begin(); std::string::const_iterator it_end = str.end(); std::string tmp; while (boost::regex_search(it_prev, what, expression)) { res = true; tmp.assign(it_prev,what[0].first); ... tmp.assign(what[2].first, what[2].second); ... reading the html doc I can not find how to rewrite this while loop. I'm not a boost expert, any help would be appreciated. Thank you

2 2

metaprogramming help
by John Dlugosz 14 Dec '10

14 Dec '10

A couple of times I've run into the situation where a "new" C++ class is written to exactly match "legacy" C structures. At the edges where old code meets new code, you can cast one to the other in-place. For example, given a huge mess of data that includes oldstruct s1; you could write the line newclass& s2= reinterpret_cast<newclass&>(s1); because s2 is designed to exactly overlay s1. It might even derive from it, and just add member functions and friendlier accessors. Another example I've seen is a class that contains nothing but a char* pointer member, that contains overloaded operators to replace the ancient str* functions. In particular, it has an operator==, so casting an array of char* to an array of that class allowed std::find to be used! I don't like the wild and unchecked use of reinterpret_cast, but I can see the point for these and think the idiom can be tamed. Basically, I want to write a cisam_cast that behaves like a reinterpret_cast but only for those conversions I've explicitly nominated as being cisam's. CISAM is "compatible in structure and meaning", and I avoid calling it "upgrade" because it works in either direction or sideways between different code bases' definitions of the same wire data. I'm thinking that I should be able to declare something like template<> cisam<xxx,yyy> : std::tr1::true_type {}; to enable cisam_cast<xxx>(a_yyy) to have the same meaning as reinterpret_cast<xxx&>(a_yyy), etc. (foreshadowing hard question...) Since it would be common to make a new class to wrap a primitive type or old struct, a shortcut would be to include a typedef yyy cisam; as a member of xxx. Now I get around to my actual question: the "etc." part above. Given that xxx and yyy are cisam-mates, I want to enable not only xxx to yyy and vice versa, but handle const and volatile qualified forms with correct cv-modifier carry-through, and handle pointers to them to any depth, which is complicated by the fact that there could be cv-qualifiers at any level. In the earlier example, the original code was something like: char* A[7]; char* val; //... Str* SA= reinterpret_cast<Str*>((char**)A); and I would want Str* SA= cisam_cast<Str*>(A); to be accepted. Note that the cisam-ness is between (char*) and (Str), so there are a different number of stars on the before and the after. So, how might I write the cisam_cast machinery to elaborate the basic cisam definitions into the full set of allowed casts? Thanks, --John =====Begin Corporate Footer That I Can't Do Anything About===== TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

5 10

[mpl, enable_if] "Failed to specialize function template"
by Igor R 14 Dec '10

14 Dec '10

Hello, The following code fails to compile (MSVC10, Boost 1.45) with "error C2893: Failed to specialize function template..." It seems that the compiler tries to evaluate mpl::apply, doesn't it? #include <boost/mpl/apply.hpp> #include <boost/mpl/bool.hpp> #include <boost/mpl/or.hpp> #include <boost/mpl/and.hpp> #include <boost/mpl/always.hpp> #include <boost/type_traits/is_same.hpp> #include <boost/utility/enable_if.hpp> using namespace boost::mpl; using boost::is_same; template<typename Type> void test(Type, typename boost::enable_if < and_ < not_<boost::is_same<Type, int> >, apply<always<true_>, typename Type::my_type> > >::type* dummy = 0) { } template<typename Type> void test(Type, typename boost::disable_if < and_ < not_<boost::is_same<Type, int> >, apply<always<true_>, typename Type::my_type> > >::type* dummy = 0) { } int main(int argc, char* argv[]) { test(int()); return 0; }

2 6

Re: [Boost-users] [Units] derived units of SI system (newbie)
by André Berthe 14 Dec '10

14 Dec '10

Thank you very much, Steve! From your reply I learned: - to think twice; not in physical values but actually in units - that supplements on existing systems are not bad - errors related to conversion factors indicate that I should check my own units (formulas) The body of the main function simplifies to: bu::quantity<SI::frequency> WSR_x(100*SI::hertz); bu::quantity<SI::dynamic_viscosity> eta(4.6*(SI::kilograms/(SI::meter*SI::second))); bu::quantity<SI::stress> WSS_x(WSR_x*eta); Best regards, Andre

1 0