- Boost-users - lists.boost.org

[BOOST]BOOST_AUTO_TEST_CASE_TEMPLATE usage
by Hemanth Choudary M V (RBEI/ETA1) 10 Sep '13

10 Sep '13

Hi, In the code snippet below, The 3rd parameter in the BOOST_AUTO_TEST_CASE_TEMPLATE is a boost::mpl::list. Is the 3rd parameter restricted only to boost::mpl::list or anything else can also be used? #define BOOST_TEST_MODULE example #include <boost/test/included/unit_test.hpp> #include <boost/test/test_case_template.hpp> #include <boost/mpl/list.hpp> //____________________________________________________________________________// typedef boost::mpl::list<long long,unsigned char> test_types; BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, test_types ) { BOOST_CHECK_EQUAL( sizeof(T), (unsigned)4 ); } //_ Mit freundlichen Grüßen / Best Regards, Hemanth Choudary MV RBEI/ETA1

2 1

shared_ptr to this
by Gonzalo Garramuno 10 Sep '13

10 Sep '13

I have an application where I need to pass "this" in a callback belonging to a class to a function using a shared_ptr in another thread In code: struct Data { Data( void* p ) : ptr( p ) { } boost::shared_ptr<void> ptr; }; void threadA( Data* d ) { boost::shared_ptr<void> ptr( d->ptr ); delete d; // use ptr } class A { void init_thread() { Data* data = new Data( this ); boost.thread t( boost::bind( threadA, data ) ); } }; The problem is obvious. Once threadA closes, the shared ptr is destroyed as its count is 0 and as it points to the this of class A this gets deleted too. However my class A is still active and should not get deleted. How can I work around this?

5 5

[wave] Wave macro expansion problem
by Edward Diener 10 Sep '13

10 Sep '13

The code: // test_macros_o.cpp #define f(a) f(x + (a)) #define x 2 #define g f #define h g(~ int main() { #pragma wave trace(enable) h 5); #pragma wave trace(disable) return 0; } In the latest C++ standard at 16.3.5 paragraph 5 the expansion of 'h 5)' is given as: f(2 * (~5)) but the wave.exe driver gives: C:\Programming\VersionControl\boost\libs\vmd\test\test_macros_o.cpp:11:3: h C:\Programming\VersionControl\boost\libs\vmd\test\test_macros_o.cpp:4:9: see macro definition: h [ g(~ rescanning [ C:\Programming\VersionControl\boost\libs\vmd\test\test_macros_o.cpp:3:9: see macro definition: g [ f rescanning [ f ] ]

2 2

[wave] Wave driver --c++0x option
by Edward Diener 10 Sep '13

10 Sep '13

After building the Wave driver tool from the latest Boost source on trunk, if I pass the --c++0x option to the Wave.exe driver I get: wave: exception caught: unrecognised option '--c++0x' Do I have to build the wave driver with some option to support the --c++0x option when running it ?

2 2

Re: [Boost-users] [BOOST.PREPROCESSOR] Use BOOST_PP_REPEAT in macros?
by Sergey Zhuravlev 10 Sep '13

10 Sep '13

I foolishly undef ARGS_AMOUNT after using. It is habit, because not wrote global macros earlier. Thanks, Edward Diener.

1 0

[BOOST.PREPROCESSOR] Use BOOST_PP_REPEAT in macros?
by Sergey Zhuravlev 09 Sep '13

09 Sep '13

Write code: ////////////////// #define ARGS_AMOUNT 9 #define INTERNAL_GENERATE_MEMBER_APPLY_CLASS(_, ARG_COUNTER, MemberName)\ template<class TClassWithMember BOOST_PP_COMMA_IF(ARG_COUNTER) BOOST_PP_ENUM_PARAMS(ARG_COUNTER, class TArg)>\ result_type operator()(\ TClassWithMember& classWithMember BOOST_PP_COMMA_IF(ARG_COUNTER)\ BOOST_PP_ENUM_BINARY_PARAMS(ARG_COUNTER, TArg, &arg)) const\ {\ classWithMember.MemberName(BOOST_PP_ENUM_PARAMS(ARG_COUNTER, arg));\ } #define DECLARE_MEMBER_APPLY_CLASS(TMemberApplyClassName, MemberName)\ template<class TResultType>\ struct TMemberApplyClassName\ {\ typedef TResultType result_type;\ BOOST_PP_REPEAT(ARGS_AMOUNT, INTERNAL_GENERATE_MEMBER_APPLY_CLASS, MemberName)\ }; #undef ARGS_AMOUNT ////////////////// DECLARE_MEMBER_APPLY_CLASS(TClassName, MemberName) declare class template closer to boost::apply, but my declared class call member MemberName: f.MemberName(args...); opposite f.operator()(args...) at boost::apply. Code not work correctly, because ARGS_AMOUNT not replaced to number 9 internally. ARGS_AMOUNT preserved after all macros substitution. If manualy replace text "ARGS_AMOUNT" at "call" for BOOST_PP_REPEAT in macros DECLARE_MEMBER_APPLY_CLASS to 9, then code generated and work correctly. Why it does? How preserve valuable name of const ARGS_AMOUNT? Now temporarily maualy replace ARGS_AMOUNT to 9 and write comment about this hardcoded const 9: BOOST_PP_REPEAT(9 /*max amount of arguments for MemberName*/, INTERNAL_GENERATE_MEMBER_APPLY_CLASS, MemberName)\

2 1

[thread] release lock before cond.var. notified?
by Thomas M 09 Sep '13

09 Sep '13

Hi, Consider a boolean variable, a mutex and a condition variable: // simplified code snippet begin bool Continue = false; boost::mutex someMutex; boost::condition_variable someCondVar; // simplified code snippet end A number of (boost-)threads check if the boolean variable is set to true in order to continue execution, or otherwise wait for this to happen: // simplified code snippet begin boost::unique_lock<boost::mutex> threadLock(someMutex); while (Continue == false) { someCondVar.wait(threadLock); } // simplified code snippet end and a single controller thread is responsible for setting Continue to true (see snippets below). Now the question: Is there a strong point pro or against releasing controllerLock before the notify_all-signal is sent? E.g. is there preference for the first or second variant as below (see placement of curly brackets!), or even a need for one to ensure correctness? // simplified code snippet begin - Variant 1 // notify_all is issued while controllerLock is still being held { boost::unique_lock<boost::mutex> controllerLock(someMutex); Continue = true; someCondVar.notify_all(); } // simplified code snippet end // simplified code snippet begin - Variant 2 // notify_all is issued when controllerLock has already been released { boost::unique_lock<boost::mutex> controllerLock(someMutex); Continue = true; } someCondVar.notify_all(); // simplified code snippet end Thanks for your input and help, Thomas

4 5

Memory Leak with flat_map.insert(Iterator,Iterator)
by Adam Baxter 09 Sep '13

09 Sep '13

Hello, I'm experiencing a memory leak using the flat_map.insert(Iterator, Iterator) function. The leak goes away if I do regular for loop and use flat_map.insert(*Iterator). Is this a known issue? If not, what would be helpful for a bug report? Adam

2 1

Regex comparision
by Prakash Reddy Bande 09 Sep '13

09 Sep '13

Hi, I would like to change a regular expression in a compatible way. Here is the use case. Initially, in the configuration I defined a reg-exp for validation of data before persisting it. Some data was created and persisted, later the reg-exp required a change, however, the change must be done is such a way that existing data should not become invalid. Example: Initial validation says "no ; (semi-colon) and : (colon) in the text". However, later we decide to relax the constraint and want to allow : (colon). By allowing this we are not invalidating any existing data and hence this change should be allowed. However, we should not be changing the configuration and add additional constraint, like now I don't want to allow _ (underscore) since there will be existing data that has _ (underscore). I am using: boost_1_46_1 Pseudo-code of APIs I am using: #include <boost/xpressive/xpressive.hpp> string regexPattern("^[^\\/?%*:|\"<>\.]+$"); boost::xpressive::sregex tmpRegex = boost::xpressive::sregex::compile(regexPattern); bool match = boost::xpressive::regex_match("value to validate", tmpRegex); Now I decide that I would start allowing . (dot) from now on. Is there a way that will allow me to validate that whatever successfully matches the old expression will also match the new expression Regards, Prakash Bande Director - Hyperworks Enterprise Software Altair Eng. Inc. Troy MI Ph: 248-614-2400 ext 489 Cell: 248-404-0292 My Secure Drop Box: https://ftam1.altair.com/dropbox/~Ursfnk

1 0

[thread] Internal compiler error when trying to make movable future
by Gavin Lambert 09 Sep '13

09 Sep '13

Am I doing something wrong in the following code? #include <boost/thread/future.hpp> template<typename T> struct test_node { BOOST_THREAD_MOVABLE_ONLY(test_node) typedef boost::unique_future<test_node> future_node; T value; future_node next; }; (In the "real code" I've defined move constructors etc as well of course, but they don't affect the result so I've omitted them for brevity.) Using boost v1.53 with BOOST_THREAD_VERSION==2 and VS2008 (non C++11 compiler), the above code produces an internal compiler error: 1>t:\boost\boost_1_53_0\boost\type_traits\is_convertible.hpp(484) : fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1411) 1> To work around this problem, try simplifying or changing the program near the locations listed above. 1>Please choose the Technical Support command on the Visual C++ 1> Help menu, or open the Technical Support help file for more information 1> t:\boost\boost_1_53_0\boost\thread\detail\is_convertible.hpp(22) : see reference to class template instantiation 'boost::is_convertible<From,To>' being compiled 1> with 1> [ 1> From=test_node<int> &, 1> To=boost::detail::thread_move_t<test_node<int>> 1> ] 1> t:\boost\boost_1_53_0\boost\mpl\if.hpp(63) : see reference to class template instantiation 'boost::thread_detail::is_convertible<T1,T2>' being compiled 1> with 1> [ 1> T1=test_node<int> &, 1> T2=boost::detail::thread_move_t<test_node<int>> 1> ] 1> t:\boost\boost_1_53_0\boost\thread\future.hpp(519) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled 1> with 1> [ 1> T1=boost::thread_detail::is_convertible<test_node<int> &,boost::detail::thread_move_t<test_node<int>>>, 1> T2=boost::detail::thread_move_t<test_node<int>>, 1> T3=const test_node<int> & 1> ] 1> t:\boost\boost_1_53_0\boost\thread\future.hpp(1398) : see reference to class template instantiation 'boost::detail::future_traits<T>' being compiled 1> with 1> [ 1> T=test_node<int> 1> ] 1> s:\tests\nodetest.cpp(26) : see reference to class template instantiation 'boost::unique_future<R>' being compiled 1> with 1> [ 1> R=test_node<int> 1> ] 1> s:\tests\nodetest.cpp(56) : see reference to class template instantiation 'test_node<T>' being compiled 1> with 1> [ 1> T=int 1> ] The internal error goes away if I remove the MOVABLE_ONLY macro or the future_node instance field. The equivalent move code (using boost::detail::thread_move_t directly) for boost 1.47 compiles and works successfully (but crashes again if I switch to boost 1.53). Is this a regression in boost or am I doing something incorrect somewhere? Does anyone know of a workaround? Note that it does not matter if I try to use Boost.Move syntax instead, as unique_future<> internally uses Boost.Thread's move implementation, which is where things seem to be failing. One possible issue is that I'm trying to declare a future to an incomplete type (because it's self-referential), which is possibly confusing some of the internal checks it wants to do. But again, this usage used to work, and I'm not sure how to fix it given the new boost version. At least not without introducing pointers and heap allocation, which I really didn't want to do.

4 6