- Boost-users - lists.boost.org

passing variables into thread
by Alexander Carôt 03 Sep '16

03 Sep '16

Hello all, I have a thrad function like: void sj::eventTrigger(){ boost::mutex::scoped_lock lock(eventTriggerMutex); while (eventTriggerActive){ dFC->eventTriggerLock.wait(lock); /// do something with pointer-variable } } This function is executed by a eventTriggerLock.notify_all() – call from other objects and when I need to pass certain variables into the thread I have been unsing a global pointer variable. Now my question: I wonder if there is a way to get rid of the pointer variable and directly pass variables into the thread such as: eventTriggerLock.notify_all(data1) void sj::eventTrigger(int data1){ boost::mutex::scoped_lock lock(eventTriggerMutex); while (eventTriggerActive){ dFC->eventTriggerLock.wait(lock); /// do something with data1 } } Any hint welcome – thanks in advance Alex

3 2

Priority deque?
by Paolo Bolzoni 01 Sep '16

01 Sep '16

Dear list, I was wondering if there some kind of "priority queue", that is a data structure akin the priority queue, but where you can top and pop from both sides. My use case is that I need to quickly access the maximum, but also not push new elements if they are smaller than the minimum. I am aware I can use a std::set, but in the current implementation where I always push new elements even if they are bad, using a std::set the performance is significantly worse. Yours faithfully, Paolo

3 5

iostreams: ceased devolopment?
by Christian Meesters 01 Sep '16

01 Sep '16

Hi, I noticed that there are numerous issues in the bug list, regarding boost iostreams. However, the current doc states Copyright 2004-2007 and Tickets do not receive responses. (I even read: "(I tried e-mailing Jonathan Turkanis directly, but the e-mail address on the website seems to be not used anymore)" in ticket 7574. So, my question is: I anyone maintaining this library? If not: I doubt that there is a good alternative, because iostreams just is convenient to use and a selling point to for boost. It would be a pitty. Best regards, Christian

7 15

Re: [Boost-users] [serialization] Problem building boost 1.56 under gcc 5.3
by Nolen, Steven Douglas 01 Sep '16

01 Sep '16

This is from a previous email sent by my colleague... OS: Red Hat 6 Compiler: GCC 5.3 I installed from a source distribution and the root paths are $HOME/packages/boost/v1_61/include/1_61 for the include path and $HOME/packages/boost/v1_61/lib/gnu-5.3 for the library path. My compilation command is g++ -o demo -I. -I$HOME/packages/boost/v1_61/include/1_61 demo.cpp -L$HOME/packages/boost/v1_61/lib/gnu-5.3 -lboost_serialization-gcc53-1_61 and these are the link errors /tmp/ccFM57HA.o: In function `boost::archive::text_iarchive::text_iarchive(std::istream&, unsigned int)': demo.cpp:(.text._ZN5boost7archive13text_iarchiveC2ERSij[_ZN5boost7archive13text_iarchiveC5ERSij]+0x36): undefined reference to `boost::archive::detail::shared_ptr_helper::shared_ptr_helper()' /tmp/ccFM57HA.o: In function `boost::archive::text_iarchive::~text_iarchive()': demo.cpp:(.text._ZN5boost7archive13text_iarchiveD2Ev[_ZN5boost7archive13text_iarchiveD5Ev]+0x25): undefined reference to `boost::archive::detail::shared_ptr_helper::~shared_ptr_helper()' /tmp/ccFM57HA.o: In function `void boost::archive::detail::load_pointer_type<boost::archive::text_iarchive>::invoke<bus_route*>(boost::archive::text_iarchive&, bus_route*&)': demo.cpp:(.text._ZN5boost7archive6detail17load_pointer_typeINS0_13text_iarchiveEE6invokeIP9bus_routeEEvRS3_RT_[_ZN5boost7archive6detail17load_pointer_typeINS0_13text_iarchiveEE6invokeIP9bus_routeEEvRS3_RT_]+0x56): undefined reference to `boost::archive::detail::basic_iarchive::load_pointer(void*&, boost::archive::detail::basic_pointer_iserializer const*)' /tmp/ccFM57HA.o: In function `void boost::archive::detail::load_pointer_type<boost::archive::text_iarchive>::invoke<bus_stop*>(boost::archive::text_iarchive&, bus_stop*&)': demo.cpp:(.text._ZN5boost7archive6detail17load_pointer_typeINS0_13text_iarchiveEE6invokeIP8bus_stopEEvRS3_RT_[_ZN5boost7archive6detail17load_pointer_typeINS0_13text_iarchiveEE6invokeIP8bus_stopEEvRS3_RT_]+0x56): undefined reference to `boost::archive::detail::basic_iarchive::load_pointer(void*&, boost::archive::detail::basic_pointer_iserializer const*)' /tmp/ccFM57HA.o: In function `boost::archive::text_iarchive& boost::archive::detail::interface_iarchive<boost::archive::text_iarchive>::operator>><boost::archive::class_name_type>(boost::archive::class_name_type&)': demo.cpp:(.text._ZN5boost7archive6detail18interface_iarchiveINS0_13text_iarchiveEErsINS0_15class_name_typeEEERS3_RT_[_ZN5boost7archive6detail18interface_iarchiveINS0_13text_iarchiveEErsINS0_15class_name_typeEEERS3_RT_]+0x2f): undefined reference to `boost::archive::text_iarchive_impl<boost::archive::text_iarchive>::load_override(boost::archive::class_name_type&, int)' collect2: error: ld returned 1 exit status I am at a loss why this will not build successfully. Any help would be appreciated.

1 0

boost libs can't find each other in non-standard location
by Hugh Caley 01 Sep '16

01 Sep '16

I'm having problems getting my boost libs to find each other on certain platforms. We're distributing the boost libs in a non-standard location. I created a runtime path in my apps that finds the boost libs fine, per ldd, but when a boost lib is dynamically liked to another boost lib in the same location it can't find it. For instance, libboost_thread needs libboost_atomic, and can't find it, even though it's in the same dir. On Linux, MacOSX and AIX, they can find each other. On Solaris and HP-UX, though, they can't. Boost version is 1_59. Strangely, we had this working with a previous version of our software on Solaris linked with Boost 1_55. I don't see the difference. I tried setting a runtime path of '.' in the boost libs themselves, but it ends up being '.' wherever I am, NOT where the lib is. -- Hugh Caley Software Developer, Rocket Aldon Rocket Software 2200 Powell Street · Suite 900 · Emeryville · CA · 94608-1809 · USA · Tel: +1.510.285.8542 Email:hcaley@rocketsoftware.com<mailto:Email:hcaley@rocketsoftware.com> Web:http://aldon.rocketsoftware.com ================================ Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ +1 877.328.2932 ■ +1 781.577.4321 Unsubscribe From Commercial Email – unsubscribe(a)rocketsoftware.com Manage Your Subscription Preferences - http://info.rocketsoftware.com/GlobalSubscriptionManagementEmailFooter_Subs… Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy ================================ This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

2 1

[thread] Error checking mutex
by Paul Fee 01 Sep '16

01 Sep '16

Hi all, When using pthread mutexes a number of types are available (man pthread_mutexattr_settype). The normal and recursive types are exposed via boost as boost::mutex and boost::recursive_mutex. I'd like to use PTHREAD_MUTEX_ERRORCHECK mutexes but don't see such a mutex type within boost or C++ std namespaces. I'm wondering why this C feature is not exposed to C++ users. Are there plans to do so? Has it been omitted because this POSIX feature is not portable to other platforms? For experimentation purposes I've duplicated then modified the code from boost/thread/recursive_mutex.hpp and boost/thread/pthread/recursive_mutex.hpp to create errorcheck_mutex.hpp on my Fedora 24 system and it gives me the error checking functionality I'm after. Is this a reasonable approach to plug the gap in Boost or is there a reason not to do so? Thanks, Paul

2 1

Boost Process Sync example hanging
by Shubha Ramani 01 Sep '16

01 Sep '16

on Linux. This code hangs at getline. I replaced "test.exe" with "ls". Why doesn't it work ? https://github.com/BorisSchaeling/boost-process/blob/master/libs/process/ex… Shubha D. Ramanishubharamani(a)gmail.com shubharamani(a)yahoo.com

1 1

[serialization] Problem building boost 1.56 under gcc 5.3
by Nolen, Steven Douglas 01 Sep '16

01 Sep '16

We are trying to build on a linux platform using gcc-5.3. We already have installations for gcc-4.6.1 thru gcc-4.9 that work. When we tried moving to gcc-5.3, the build worked (apparently), but then we saw linking errors of this ilk... <blah, blah, blah> undefined reference to `boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save(std::string const&) The same linking errors happen when we build our code and when we tried just building the demo samples with the package. We have tried building a more recent version of boost and also scouring stackoverflow and others. Anyone having similar issues, or who might be aware of what's happening?

2 1

create_pipe() not working ?
by Shubha Ramani 30 Aug '16

30 Aug '16

Is this example outdated ? How come I can't create a boost pipe ? https://us-mg0.mail.yahoo.com/neo/launch?.rand=3f0ef0mo8jiih#1996284311 boost::process::pipe p = create_pipe(); file_descriptor_sink sink(p.sink, close_handle); execute( run_exe("test.exe"), bind_stdout(sink) ); file_descriptor_source source(p.source, close_handle); stream<file_descriptor_source> is(source); std::string s; std::getline(is, s); Shubha D. Ramanishubharamani(a)gmail.com shubharamani(a)yahoo.com

1 0

[type_erasure] static check of concept compliance
by Joaquin M López Muñoz 30 Aug '16

30 Aug '16

Consider: using any_t=any< boost::mpl::vector< copy_constructible<>, incrementable<> > >; struct foo{}; int main() { std::cout<<std::is_constructible<any_t,foo>::value<<"\n"; } This program outputs 1 as the ctor of boost::type_erasure::any<Concept> if not restricted to Concept-compliant args, but of course we can't use foo to construct any_t: any_t x{foo{}}; // compile error as foo is not incrementable Is there a (publicly available) way to determine if an argument of type U can be used to construct an any<Concept,T>? I'd like to have this for doing SFINAE in my any-using code. Thank you, Joaquín M López Muñoz

2 1