- Boost-users - lists.boost.org

Using boost interprocess file_lock.timed_lock
by Bill Moo 30 Jul '11

30 Jul '11

Hello List, Could someone please give me a working example of how to use this please. I am obviously doing something wrong as depending on how much I write to the std::ofstream I either end up with a proper file or a file containing a single byte! I would really appreciate your assistance with this as it's driving me to distraction. Here is the approach I am taking. std::ofstream os ; os.open(m_FileName.c_str(), std::ios_base::out | std::ios_base::binary | std::ios_base::app) ; try { if (os.is_open()) { os.setf(std::ios::fixed, std::ios::floatfield) ; os.precision(3) ; if (fileLock.timed_lock(pt += pt::seconds(5))) { try { for (int o = 0; o < 48; o++) { os << "Write my data here....." ; for (int i = 0; i < 51) { os << i ; // But if I output this simple line and I get a 1 byte file and NO errors or exceptions! } } fileLock.unlock() ; } catch (std::ofstream::failure e) { qDebug() << e.what() ; } } else { qDebug() << "No lock on file!" ; } } else { qDebug() << "File not opened!" ; } } catch (ip::interprocess_exception& e) { qDebug() << e.what() ; } catch (std::exception& e) { qDebug() << e.what() ; } os.close(); -- Bill

4 6

vxworks and pre-built boost libraries
by Brian Vandenberg 29 Jul '11

29 Jul '11

I'm attempting to use boost in vxworks 6.5 and I'm looking for information on how to get the pre-built libraries to build (those that can be). Some amount of support for vxworks was added back in 1.38, but vxworks isn't on the list of available/supported target OSs. Are there any resources out there detailing what can be made to work/does work/doesn't work, and what needs to be done to get the workable stuff to build? Thanks for your time. -Brian

2 5

[units] runtime conversion approach
by Michael Powell 29 Jul '11

29 Jul '11

Units developers/user, I need some help understanding unit conversions using boost::units. I see there are conversions.hpp header files. Does this mean that there are built-in unit conversions for fundamental units, or even mainstream derived ones by simply including the conversions and performing the appropriate operation? Can I do something like this, for instance? quantity<si::length> test_m = 1.0 * meter; quantity<us::inch> test_in = test_m * inch / meter; What is the best way to go about setting up conversions, or for that matter, defining a unit system; for instance, the us (english) unit system does not appear to be available? I've read a couple of the old mailing list entries, but I'm not sure I fully understand the examples that I could follow them. Thank you... Regards, Michael

2 1

noncopyable and move semantics
by Nathan Ridge 29 Jul '11

29 Jul '11

Hello, The current implementation of boost::noncopyable prevents derived classes from declaring a defaulted move constructor: #include <boost/noncopyable.hpp> struct S : boost::noncopyable { S(S&&) = default; }; S f(); int main() { S s = f(); } Errors (with gcc trunk): test3.cpp: In function 'int main()': test3.cpp:12:13: error: use of deleted function 'S::S(S&&)' test3.cpp:5:5: error: 'S::S(S&&)' is implicitly deleted because the default definition would be ill-formed: /usr/include/boost/noncopyable.hpp:27:7: error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable&)' is private test3.cpp:5:5: error: within this context The problem is that the default move constructor for S tries to move the noncopyable base subobject, but noncopyable does not have a move constructor (one isn't generated implicitly because a user-defined copy constructor is present). Then it tries to fall back to the noncopyable copy constructor, but that of course is private. If we give the definition of the S move constructor explicitly, all is well because no one is trying to move or copy the noncopyable subobject: struct S : boost::noncopyable { S(S&&) {} }; However, having to define the move constructor explicitly is annoying and a maintenance hazard (e.g. if you add a data member, you have to add it to the move constructor too). If we modify noncopyable to give it a move constructor, the defaulted move constructor now works in derived classes. I think we should either give noncopyable a move constructor, or add a similar class ("noncopyable_but_movable"? - I'm bad with names) that is like noncopyable but also has a move constructor. Thoughts? Regards, Nate.

3 10

xlC 9.0 Boost 1.40 on Aix error
by Radha 29 Jul '11

29 Jul '11

Hi, I hit on the following error when i compile a code with boost 1.46 on Aix with xlC 9. boost_1_46/boost/proto/detail/poly_function.hpp", line 164.25: 1540-0038 (S) The name "typename result::result_type" is not a type. Is this a known issue? Any known patch to make it work? Regards, Radha

1 0

[geometry] intersects bug?
by Akira Takahashi 29 Jul '11

29 Jul '11

Hi, I try boost::geometry::intersects algorithm(1 arg version) in Boost 1.47.0. Follow program result is "false". but, I hope result is "true". Is this Boost.Geometry bug? #include <iostream> #include <boost/assign/list_of.hpp> #include <boost/geometry/geometry.hpp> namespace bg = boost::geometry; int main() { typedef bg::model::d2::point_xy<double> point; const bg::model::linestring<point> line = boost::assign::list_of<point> // (0, 0) // result become "true" when comment-in (0, 4) (4, 4) (2, 2) (2, 5) ; const bool result = bg::intersects(line); std::cout << std::boolalpha << result << std::endl; } Regards, >>======================== Akira Takahashi mailto:faithandbrave@gmail.com blog: http://d.hatena.ne.jp/faith_and_brave/

2 3

Segfault when trying to deserialize std::lists in a multi_array
by Jiří Vyskočil 28 Jul '11

28 Jul '11

Hello, I'm working on a parallel physical simulation involving particles in a 3D grid. In addition to Boost libraries, I use the Eigen3 template library for holding numerical data in small 3-vectors. I'm trying to send a 3D boost::multi_array containing std::list of pointers to particle structs via boost::mpi and keep getting a segfault on receive. Sending and receiving boost::multi_array of V3D Eigen3 vectors works fine. Serialization functions for multi_array are from http://tinyurl.com/3koafmr (edited for 3 dimensions, seems to work) Serializing Eigen Vector3d type (seems to work): friend class boost::serialization::access; template<class Archive> inline void serialize(Archive & ar, const unsigned int file_version) { ar & m_coeffs.x(); ar & m_coeffs.y(); ar & m_coeffs.z(); } typedef Vector3d V3D; //Convenience typedef for Eigen3 vector struct Particle { V3D r, u; double m, q; unsigned number; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int file_version) { ar & r; ar & u; ar & m; ar & q; ar & number; } }; Sending point: typedef boost::multi_array<std::list<Particle*>, 3> ParticleArray; ParticleArray part_array(boost::extents[x][y][z]); ...fill the array with particles, some cells might be empty... world->isend(recnum, pack_type, part_array); Receiving point: ParticleArray part_array(boost::extents[slice->shape()[0]][slice->shape()[1]][slice->shape()[2]]); world->recv(sendnum, pack_type, part_array); When I get here, it segfaults: terminate called after throwing an instance of 'boost::archive::archive_exception' what(): class version # 0 0 Program received signal SIGABRT, Aborted. 0x00007ffff5a29a25 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff5a29a25 in raise () from /lib64/libc.so.6 #1 0x00007ffff5a2b0af in abort () from /lib64/libc.so.6 #2 0x00007ffff64fb695 in __gnu_cxx::__verbose_terminate_handler () at /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:93 #3 0x00007ffff64f9ac6 in __cxxabiv1::__terminate (handler=0x70d) at /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:38 #4 0x00007ffff64f9af3 in std::terminate () at /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/libstdc++-v3/libsupc++/eh_terminate.cc:48 #5 0x00007ffff64f9bee in __cxxabiv1::__cxa_throw (obj=<value optimized out>, tinfo=<value optimized out>, dest=<value optimized out>) at /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/libstdc++-v3/libsupc++/eh_throw.cc:83 #6 0x000000000044f7d5 in boost::archive::detail::iserializer<boost::mpi::packed_iarchive, Particle>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const () #7 0x00007ffff794173b in load_object (this=0x7fffffffcae0, t=<value optimized out>, bis=...) at libs/serialization/src/basic_iarchive.cpp:367 #8 boost::archive::detail::basic_iarchive::load_object (this=0x7fffffffcae0, t=<value optimized out>, bis=...) at libs/serialization/src/basic_iarchive.cpp:547 #9 0x000000000044f662 in boost::archive::detail::pointer_iserializer<boost::mpi::packed_iarchive, Particle>::load_object_ptr(boost::archive::detail::basic_iarchive&, void*&, unsigned int) const () #10 0x00007ffff7941c50 in load_pointer (this=0x7fffffffcae0, t=@0x7fffffffc880, bpis_ptr=0x668060, finder=<value optimized out>) at libs/serialization/src/basic_iarchive.cpp:494 #11 boost::archive::detail::basic_iarchive::load_pointer (this=0x7fffffffcae0, t=@0x7fffffffc880, bpis_ptr=0x668060, finder=<value optimized out>) at libs/serialization/src/basic_iarchive.cpp:560 #12 0x000000000044ed6f in boost::archive::detail::iserializer<boost::mpi::packed_iarchive, std::list<Particle*, std::allocator<Particle*> > >::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const () #13 0x00007ffff79416fa in load_object (this=0x7fffffffcae0, t=<value optimized out>, bis=...) at libs/serialization/src/basic_iarchive.cpp:399 #14 boost::archive::detail::basic_iarchive::load_object (this=0x7fffffffcae0, t=<value optimized out>, bis=...) at libs/serialization/src/basic_iarchive.cpp:547 #15 0x000000000044ffb4 in boost::archive::detail::iserializer<boost::mpi::packed_iarchive, boost::multi_array<std::list<Particle*, std::allocator<Particle*> >, 3ul, std::allocator<std::list<Particle*, std::allocator<Particle*> > > > >::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const () #16 0x00007ffff79416fa in load_object (this=0x7fffffffcae0, t=<value optimized out>, bis=...) at libs/serialization/src/basic_iarchive.cpp:399 #17 boost::archive::detail::basic_iarchive::load_object (this=0x7fffffffcae0, t=<value optimized out>, bis=...) at libs/serialization/src/basic_iarchive.cpp:547 #18 0x00000000004516f9 in boost::mpi::status boost::mpi::communicator::recv_impl<boost::multi_array<std::list<Particle*, std::allocator<Particle*> >, 3ul, std::allocator<std::list<Particle*, std::allocator<Particle*> > > > >(int, int, boost::multi_array<std::list<Particle*, std::allocator<Particle*> >, 3ul, std::allocator<std::list<Particle*, std::allocator<Particle*> > > >&, mpl_::bool_<false>) const () #19 0x000000000044982d in recv<ParticleArray> (this=0x66b150, slice=0x8779e0, pack_type=<value optimized out>, sendnum=1) at /usr/include/boost/mpi/communicator.hpp:1201 #20 Communicator::receive (this=0x66b150, slice=0x8779e0, pack_type=<value optimized out>, sendnum=1) at /home/strazce/prog/opice/opice/src/communicator.cpp:62 #21 0x000000000043d512 in Experiment::run (this=0x66b0c0) at /home/strazce/prog/opice/opice/src/experiment.cpp:96 #22 0x000000000042c13c in main (argc=1, argv=0x7fffffffd158) at /home/strazce/prog/opice/opice/src/opice.cpp:29 (gdb) Again, this error only shows when receiving the multi_array of std::list<Particle*>. multi_array of V3D is received fine. Thanks for any help, Jiri Vyskocil

3 5

Multiple Inheritance and enable_shared_from_this
by Travis Gockel 28 Jul '11

28 Jul '11

In my code base, we use the wonderful enable_shared_from_this template quite frequently. However, I came across an *interesting* problem while mocking some classes for unit tests. I compiled the following code with g++ 4.4.3 and Boost 1.46.1 (the same as the attached code): #include <boost/enable_shared_from_this.hpp> #include <boost/make_shared.hpp> #include <boost/smart_ptr.hpp> #include <iostream> class base : public boost::enable_shared_from_this<base> { public: boost::shared_ptr<base> get_shared_from_base() { return shared_from_this(); } }; class derived : public base, public boost::enable_shared_from_this<derived> { public: boost::shared_ptr<derived> get_shared_from_derived() { return boost::enable_shared_from_this<derived>::shared_from_this(); } }; int main() { boost::shared_ptr<derived> thing = boost::make_shared<derived>(); boost::shared_ptr<derived> derived_thing = thing->get_shared_from_derived(); boost::shared_ptr<base> base_thing = thing->get_shared_from_base(); return 0; } This is what I expect: I expect the get_shared_from_derived call to work, since the _internal_accept_owner would visit it. I would also expect the call to get_shared_from_base to fail with a bad_weak_ptr, since it looks like there is only one call in shared_ptr's constructor. I expect that the actual behavior is probably undefined, since it would depend on which association the compiler feels more strongly about: the enable_shared_from_this<derived> from derived or the enable_shared_from_this<base> from base. What I expect is, of course, not happening, which is why I turn to the Boost gurus. *Neither* of the calls work: they both fail with a bad_weak_ptr. Why would this happen? -- - Travis Gockel

2 1

Cufflinks building with problems in boost
by aquleaf 28 Jul '11

28 Jul '11

I'm trying to install Cufflinks but I failed. It read: make all-recursive make[1]: Entering directory `/usr/local/src/cufflinks-1.0.3' Making all in src make[2]: Entering directory `/usr/local/src/cufflinks-1.0.3/src' g++ -Wall -Wno-strict-aliasing -g -gdwarf-2 -Wuninitialized -march=i686 -O3 -DNDEBUG -pthread -I/usr/local/boost/include -I/usr/local/samtools-0.1.17/include -o cufflinks -L/usr/local/boost/lib -L/usr/local/samtools-0.1.17/lib cufflinks.o libcufflinks.a libgc.a -lboost_thread -lbam -lz /usr/local/boost/lib/libboost_thread.a(thread.o): In function `_ZN5boost2CV23simple_exception_policyItLt1ELt31ENS_9gregorian16bad_day_of_monthEE8on_errorEttNS0_14violation_enumE.clone.79': thread.cpp:(.text+0x5d3): undefined reference to `__sync_fetch_and_add_4' /usr/local/boost/lib/libboost_thread.a(thread.o): In function `_ZN5boost2CV23simple_exception_policyItLt1400ELt10000ENS_9gregorian8bad_yearEE8on_errorEttNS0_14violation_enumE.clone.96': thread.cpp:(.text+0x107b): undefined reference to `__sync_fetch_and_add_4' /usr/local/boost/lib/libboost_thread.a(thread.o): In function `_ZN5boost2CV23simple_exception_policyItLt1ELt12ENS_9gregorian9bad_monthEE8on_errorEttNS0_14violation_enumE.clone.97': thread.cpp:(.text+0x13df): undefined reference to `__sync_fetch_and_add_4' /usr/local/boost/lib/libboost_thread.a(thread.o): In function `_ZN5boost9date_time14microsec_clockINS_10posix_time5ptimeEE11create_timeEPFP2tmPKlS6_E.clone.111': thread.cpp:(.text+0x1e3d): undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status make[2]: *** [cufflinks] Error 1 make[2]:Leaving directory `/usr/local/src/cufflinks-1.0.3/src' make[1]: *** [all-recursive] Error 1 make[1]:Leaving directory `/usr/local/src/cufflinks-1.0.3' make: *** [all] Error 2 I guess there may be some problems with boost. What should I do? -- View this message in context: http://boost.2283326.n4.nabble.com/Cufflinks-building-with-problems-in-boos… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

[iostreams] building with zlib
by Daniel Bradburn 28 Jul '11

28 Jul '11

Dear boost-users, I am trying to use the compression filters with boost.iostreams. I'm following the instructions here http://www.boost.org/doc/libs/1_47_0/libs/iostreams/doc/index.html?path=7 for building, this is my command line (from libs/iostreams/build): "../../../bjam" -sZLIB_SOURCE="C:/Documents and Settings/bradburnd/My Documents/Development/SDK/zlib/1.2.5" I get the following error: ..\..\..\libs\iostreams\src\zlib.cpp(20) : fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory I checked my zlib install location and the zlib.h is at the correct location. Based on what I see in the documentation I don't see why this shouldn't be working. Is there something I'm missing? I am using Windows XP, msvc-9.0 boost 1.45 Best Regards Daniel Bradburn

4 4