- Boost-users - lists.boost.org

[Boost 1.34] Unsatisfied symbol "boost::thread::~thread()
by Alexander Vinokur 23 Jan '11

23 Jan '11

Hi, I have the following problem. Boost 1.34 HP-UX B.11.23 U ia64 aCC: HP C/aC++ B3910B A.06.25.01 [May 16 2010] // ------ vvv1.cpp ------ #include <boost/thread.hpp> void tproc() {} int main() { boost::thread t(tproc); t.join(); return 0; } // ----------------------- Compilation-1. > aCC +DD64 -AA -mt -I$BOOST_HOME vvv1.cpp ld: Unsatisfied symbol "boost::thread::~thread()(complete)" in file vvv1.o ld: Unsatisfied symbol "boost::thread::thread(boost::function0<void,std::allocator<boost::function_base> > const&)(complete)" in file vvv1.o ld: Unsatisfied symbol "boost::thread::join()" in file vvv1.o 3 errors. Compilation-2. > aCC +DD64 -AA -mt -lboost_thread-mt -I$BOOST_HOME vvv1.cpp ld: Can't find library for -lboost_thread-mt Fatal error. What is wrong? Thanks Alex Vinokur This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp

2 1

serialization binary file backwards compatibility issue 1.42 -> 1.45
by Jake Brownson 23 Jan '11

23 Jan '11

I see in the changelog (http://www.boost.org/doc/libs/1_45_0/libs/serialization/doc/release.html) that files serialized with 1.42's binary serialization will have problems opening in 1.45. This is exactly what I'm experiencing. Luckily we have only used 1.42 in our project up to this point when we are testing for a release including boost 1.45, so we know all of our previous files were saved using 1.42. We should be able to automatically apply the fix_six fix when loading old files (I can tell by the filename when it's an old one). However I'm confused because fix_six bumps the version from 6 to 7, but in my copy of boost 1.42 serialization is already saving files w/ a library version of 7. Did 1.42 get patched to fix this issue already, or am I misunderstanding something? I found a recent thread where Robert Ramey asked someone to try trunk. I just did this and without the fix_six fix the files seem to be loading properly. Thanks, Jake

2 2

[Fusion] Building parameter list for fusion::invoke
by Vivek 23 Jan '11

23 Jan '11

I am building a library in which users pass in function pointers of any type. I would like the library to determine the function's signature (using function_types), build a fusion vector for the function's arguments, populate the vector with data from a particular source, and then invoke the function using fusion::invoke. The kicker is that the argument types may not be default constructible. Therefore I need a way of initializing a fusion vector from a source as it is being created. For example, the following won't work namespace ft = ::boost::function_types; namespace bf = ::boost::fusion; struct non_def_type { private: non_def_type(); }; void my_func(non_def_type); template <typename FPTR> void my_invoker(FPTR f) { typedef typename ft::parameter_types<FPTR>::type parameter_types; typedef typename bf::result_of::as_vector<parameter_types>::type parameter_vector; parameter_vector params; // error if FPTR contains a parameter_type that is not default-constructible // // ... do something to populate params from data source // bf::invoke(f, params); } int main() { my_invoker(my_func); } Any idea how I might initialize the fusion vector as it is being created? I feel like there might be a way to transform parameter_types into a version in which each type is wrapped in a default-constructible wrapper, then transform that list into the final boost fusion list while at the same time populating it with data, but I can't seem to get the functors to work. E.g.: template <typename T> struct type_wrapper { type_wrapper() {} }; template <typename T> struct wrap { typedef type_wrapper<T> type; }; // Metafunction to unwrap types, and function to populate data // (data should never need to be default-constructible) struct fill { template <typename SIG> struct result; template <typename T> struct result<fill(const type_wrapper<T>&)> { typedef T type; }; // Reference type needed for bf::transform_view template <typename T> struct result<fill(type_wrapper<T>&)> { typedef T type; }; // Non-reference type needed for bf::vector template <typename T> struct result<fill(type_wrapper<T>)> { typedef T type; }; template <typename T> T operator()(const type_wrapper<T>&) const {return data_source<T>().pop();} }; template <typename FPTR> void my_invoker(FPTR f) { typedef typename ft::parameter_types<FPTR>::type parameter_types; // Conversion 1: create a fusion vector with types wrapped in a // default-constructible wrapper typedef mpl::transform<parameter_types, wrap<mpl::_1>, mpl::back_inserter<mpl::vector<> > >::type wrapped_parameter_types; typedef typename bf::result_of::as_vector<wrapped_parameter_types>::type wrapped_parameter_vector; // Conversion 2: create a fusion vector with the unwrapped types // that is also populated with the data from the data_source // (without having to ever default_construct any of the parameter_types) typedef typename bf::result_of::transform<const wrapped_params, fill>::type params_view; typedef typename bf::result_of::as_vector<const params_view>::type params_t; // Finally: invoke the function with arguments bf::invoke(f, bf::as_vector(bf::transform(params_view(), fill()))); } I can't seem to get the meta-function calls or the 'fill' metafunction itself quite right, instead getting vast reams of compiler complaints. Am I missing something? Or alternatively, is there a direct way to initialize a fusion vector? Many thanks, Vivek

3 2

[boost.thread] function call and functor in thread creation: performance
by Boost lzw 22 Jan '11

22 Jan '11

Hi, everyone, A new thread can be created using boost thread either from a function or a functor as the entry point of the new thread, as: void thread_function(); boost::thread thrd(&function); class functor { public: inline void operator()(); }; functor f; boost::thread thrd(f); Is there a performance difference between these two? In an ordinary C++ program, can I claim that calling f() 1000 times gives better performance than calling thread_function() 1000 times, because the functor is hinted "inline" even the hint is igored by my compiler? Is f() the same as a function call in term of performance? Thanks in advance. Robert

3 3

boost.iterators - iterator_facade issue with aligned types.
by Christoph Heindl 21 Jan '11

21 Jan '11

Hi, It seems to me that boost::iterator_facade cannot cope with aligned types when the 'Reference = use_default' template argument is not a reference, which can happen if transform_iterator is used to return the result of a temporay calculation (by value of course). Inside iterator_facade.hpp struct operator_arrow_result { //... static type make(Reference x) { return implicit_cast<type>(&x); } }; Reference here is passed by value. Since Reference has alignment the compiler reports an error. The issue was resolved once i changed that code to struct operator_arrow_result { //... typedef typename mpl::if_< is_reference<Reference> , Reference , typename add_reference<Reference>::type >::type input_type; static type make(input_type x) { return implicit_cast<type>(&x); } }; I wonder about any side effects this would cause? My lousy research is based boost 1.43. That part of the code seems to be unchanged for the current trunk. Best regards, Christoph

2 4

Re: [Boost-users] Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 21 Jan '11

21 Jan '11

2 1

Re: [Boost-users] Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 21 Jan '11

21 Jan '11

1 0

Re: [Boost-users] Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 21 Jan '11

21 Jan '11

1 0

Assertion `__null != bpos' failed in /inclu de/boost/archive/detail/oserializer.hpp:436
by ktomaszewski＠zunit.com 20 Jan '11

20 Jan '11

2 1

Thread-specific pointers versus MFC (Microsoft)
by Stephen Nuchia 20 Jan '11

20 Jan '11

I see a thread about this issue from 2009, with no resolution. A possible patch was mentioned but there was never a followup. We picked up the thread-specific pointer goodness with 1.35, under Visual Studio 2008. We stayed with that combination ever since, for stability. Now I'm looking at VS2010 and 1.44. To support Microsoft's thread model in DLL (dynamically linked libraries) in 1.35 required the user to intercept library unload events. Shortly after 1.35, the boost thread library was enhanced to take care of this for you. The hook it uses, however, conflicts with the use of that same hook by Microsoft's MFC library, when you are building an "MFC Extension DLL" specifically. We have a bunch of that going on. The conflict ends up being detected at link time, like this: 1>libboost_thread-vc100-mt-gd-1_44.lib(tss_pe.obj) : error LNK2005: _pRawDllMain already defined in Table.obj The archive discussion http://thread.gmane.org/gmane.comp.lib.boost.user/46509/focus=46706 What is the current thinking on this issue? I don't see any #ifdef logic in the boost headers that looks like it might be intended to address this, do I need to hack it myself or is there an established work-around? And don't dog me about MFC. Some of the code I'm dealing with is still in FORTRAN, and some is 25-year-old C. Thanks! -swn

1 0