September 2013 - Boost-users - lists.preview.boost.org

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

[accumulators] Moving mean expiry
by Michael Powell 08 Sep '13

08 Sep '13

Hello, I am looking for a moving window mean accumulator. Could roll my own, but I know there's a pretty good one in Boost. Need to know, does it comprehend the notion of Expiration? That is, values dropping off after a predetermined window of time? Preferably depending on the boost::chrono::high_resolution_clock. Thank ye... Regards, Michael Powell

1 1

[Serialization and possibly others] Serialization library built with Clang symbol export errors on link
by Kim 07 Sep '13

07 Sep '13

Hey guys, I'm trying to link my program to the boost serialization library built using clang w/ the mingw STL headers on Windows and I get a lot of symbol not found errors. Any help is most appreciated since I really want to get this working with Clang. If I need to provide more information please let me know. C:\MinGW\bin>g++ -shared script.o libboost_serialization-clang34-mt-1_54.lib -o script.dll Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_iarchiveEEEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_13text_oarchiveEEEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonINS_7archive6detail12extra_detail3mapINS2_19naked_text_iarchiveEEEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_13typeid_system27extended_type_info_typeid_0ENS3_12type_compareESaIS6_EEE8instanceE: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE12get_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE12is_destroyedEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE18get_const_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE20get_mutable_instanceEv: symbol not found Cannot export __ZN5boost13serialization9singletonISt8multisetIPKNS0_18extended_type_infoENS0_6detail11key_compareESaIS5_EEE8instanceE: symbol not found collect2.exe: error: ld returned 1 exit status C:\MinGW\bin>

1 1

[spirit] Qi-adapted-struct light bulb
by Michael Powell 07 Sep '13

07 Sep '13

Hello, A light bulb went on for me with regard to adapting structs into Qi parser grammars. Feel free to correct me if I'm wrong. The key is adapting a struct into your grammer's parser(s) using the BOOST_FUSION_ADAPT_STRUCT, which identifies the type (struct) and fields you are synthesizing out of the grammar. It doesn't mean that there can't be other (presumably) public variables, functions, etc, in the struct. It also doesn't mean there can't be private or protected or even a hierarchy of members. It just means that those are the *adapted* fields into which values will be synthesized. Need a style feedback as well. I am finding that I define both the struct and its parser grammar in the same header/source. Is there any reason to separate the two, really? Other than perhaps not everything needs to know about the grammer, just the struct, type thing. Thank you... Regards, Michael Powell

1 0

Boost program option parsing issue.
by Vivek Anand 07 Sep '13

07 Sep '13

Hi All, I am using program option for my program. Here is my code snippet string inputFile, outputFile; /* Populate command line arguments */ po::options_description desc("Usage: KDMGenerator [OPTIONS]"); { desc.add_options() ("help", "prints this message") ( "input-file", po::value<string>(&inputFile), "input file name" ) ( "output-file", po::value<string>(&outputFile), "output file name"); } po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("help") || !vm.size()) { cout <<desc; return 0; } if(vm.count("input-file")) { cout << "Input file :" << inputFile << '\n'; } if(vm.count("output-file")) { cout << outputFile << '\n'; } The issue I am facing is that if i I call my program without passing value for input file, something like ./myapp --input-file --output-file out.txt I get Input file: --output-file i.e the value "--output-file" get stored in inputFile and vm.count("output-file") returns zero. Is this the desired behavior? Is there any workaround for this? -- Vivek,

2 4

[spirit] qi pheonix struct adaptation
by Michael Powell 06 Sep '13

06 Sep '13

Hello, Need a little guidance when it comes to adapting structs. Let's say I've got a simple struct: struct data_t { int a; int b; int c; }; When I adapt it, I need to specify the fields into which the values are being consumed and subsequently synthesized? What happens for optional consumers, in one use-case? In another use-case, what happens if one value or another value or a third value can be consumed for that field? So, something like this, pardoning the pseudo-code: using qi::int_; using qi::lit; qi::rule<Iterator, data_t()> rule_; //a is optional, followed by b is mandatory, followed by c can be 1 | 2 | 3 rule_ %= -( int_ ) >> lit(',') >> int_ >> lit('.') >> ( int_(1) | int_(2) | int_(3) ); This is applying into a GPS NMEA parser domain, so along these lines for things like geo-spacial-coordinates, latitude/longitude, time, etc. Thank you... Regards, Michael Powell

1 0

compilation error
by Николай Кинаш 06 Sep '13

06 Sep '13

Hello all! My programm: `--# cat test_boost.hpp #include <boost/graph/adjacency_list.hpp> #include <boost/graph/rmat_graph_generator.hpp> #include <boost/random/linear_congruential.hpp> typedef boost::adjacency_list<>Graph; typedef boost::unique_rmat_iterator<boost::minstd_rand, Graph> RMATGen; int main() { boost::minstd_rand gen; // Create graph with 100 nodes and 400 edges Graph g(RMATGen(gen, 100, 400, 0.57, 0.19, 0.19, 0.05), RMATGen(), 100); return 0; } `--# mpic++ test_boost.hpp -I./boost/boost/graph/ -I./boost/ -I./boost/boost/random/ -o test_boost /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' collect2: error: ld returned 1 exit status what's wrong ?

2 1