- Boost-users - lists.boost.org

[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 10 Sep '13

10 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

[accumulators] Help with accumulator-based typedef
by Michael Powell 09 Sep '13

09 Sep '13

Hello, I am trying to setup a "simple" weighted_mean accumulator for a struct I want to accumulate. It goes something like this. Let's call it a float for sake of example. It's actually a struct with mathematical comprehension: addable, subtractable, multipliable, dividable, and so on. typedef accumulator_set<float, stats<tag::rolling_mean>, features<tag::count, tag::weighted_mean> > my_float_accumulator_set; However, I am getting obscenely long errors complaining about AccumulatorSet, etc, etc. Can someone direct me to a (somewhat) complete example of a weighted_sum accumulator in action? Am I even on the right track type-defining my accumulator ahead of time? Regards, Michael Powell

1 1

Re: [Boost-users] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 08 Sep '13

08 Sep '13

> I have exactly the same issue with MinGW-builds gcc-4.8.1-x86_64-posix-seh > building boost 1.54.0. It also crashes cxx1plus.exe as I build it (which is > probably another problem). > Did you manage to construct a workaround? Well I stopped working on that. I was expecting that somebody could help with the content of <boost/detail/interlocked.hpp> but got no answer. I imagine that extern "C" long InterlockedIncrement( long volatile * ); should be extern "C" __attribute__((dllimport)) long __attribute__((__stdcall__)) InterlockedIncrement( long volatile * ); as it is in 32 bits. I have now looked a bit further: among the preprocessor variable checked in <boost/detail/interlocked.hpp>, here are the differences when compiling with i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++: 1. in both cases, the following variables are undefined: WIN32 __CYGWIN__ MINGW64 _M_IA64 BOOST_MSVC BOOST_INTEL_WIN _WIN32_WCE _MSC_VER 2. in both cases, the following variables are defined with value 1: _WIN32 __WIN32 3. variable _M_AMD64 is undefined with i686-w64-mingw32-g++ and defined with value 100 with x86_64-w64-mingw32-g++. Does this help? In particular, is it normal that _WIN32 and __WIN32 are defined when targetting win64? Is it normal that MINGW64 is always undefined although I use a W64 compiler? Frédéric

3 6