- Boost-users - lists.boost.org

boost.regex with ICU memory cleanup on windows
by Alex Perry 02 Aug '11

02 Aug '11

Hi, I recently asked this on stack overflow boost with icu u32_regex memory leak / cache on Win32<http://stackoverflow.com/questions/6867664/boost-with-icu-u32-regex-memory-…> but haven't been able to solve issue yet so thought I would ask here as well. The problem I'm having is that I can't seem to clean up the ICU data when it is loaded by boost regex using the optional icu linkage to support Unicode regex's. I'll copy the example source I posted above:- #define BOOST_TEST_MAIN //Ask boost unit test framework to create a main for us #define BOOST_ALL_DYN_LINK //Ask boost to link to dynamic library rather than purely header support where appropriate #include <boost/test/auto_unit_test.hpp> #include <boost/regex.hpp> #include <boost/regex/icu.hpp> //We use icu extensions to regex to support unicode searches on utf-8 #include <unicode/uclean.h> //We want to be able to clean up ICU cached objects BOOST_AUTO_TEST_CASE( standard_regex ) { boost::regex re( "\\d{3}"); } BOOST_AUTO_TEST_CASE( u32_regex ) { boost::u32regex re( boost::make_u32regex("\\d{3}")); u_cleanup(); //Ask the ICU library to clean up any cached memory } Which may be compiled at command prompt (cl version 16 from vs2010) with appropriate directories inserted if not pathed in on machine. cl test.cpp /I[BOOST HEADERS PATH] /I[ICU HEADERS] /EHsc /MDd -link /LIBPATH:[BOOST LIB PATH] [ICU LIB PATH]icuuc.lib The problem I have with this is that the u_cleanup() does not cleanup so the unit test framework reports memory leaks (at least that is what I think is going on) :- Just compiling the 1st test case will work perfectly - adding in the 2nd test case (with or without the u_cleanup() ) will generate a memory leak report Running 2 test cases... *** No errors detected Detected memory leaks! Dumping objects -> {778} normal block at 0x00668530, 28 bytes long. Data: < 0N W > 00 00 00 00 30 4E C2 57 00 00 00 00 01 00 00 00 {777} normal block at 0x004C5AF8, 14 bytes long. Data: <icudt46l-coll > 69 63 75 64 74 34 36 6C 2D 63 6F 6C 6C 00 {776} normal block at 0x004C5200, 5 bytes long. Data: <root > 72 6F 6F 74 00 {775} normal block at 0x004C9B30, 60 bytes long. Data: < RL ZL > 00 52 4C 00 F8 5A 4C 00 00 00 00 00 00 00 00 00 ... rest removed for clarity As it says in comment on original post icu appears to be loaded as a dynamic link so I can't see why u_cleanup() would not work - alternatively I can't find any calls in boost::regex library which would allow me to ask it to clean up icu cache. Thanks in advance for any help. Alex

2 1

program_options, parse up to first non-option
by Tow Mater 02 Aug '11

02 Aug '11

Can program_options be used to parse command line elements up to the first non-option that is not an option argument?

2 2

Boost::Tokenizer / "string iterators incompatible" error on Visual C++ 2010 Express - runs ok on gcc4.6.0
by asif saeed 02 Aug '11

02 Aug '11

Hi, The following piece of code is giving me "string iterators incompatible" error: ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// #include <iostream> #include <string> #include <boost/tokenizer.hpp> class Base { public: typedef boost::char_separator<char> sep_type_t; typedef boost::tokenizer<sep_type_t> tokenizer_t; Base(std::string s) : sep_(";"), tok_(s,sep_), i_(tok_.begin()) { } std::string nextToken() { if (i_!=tok_.end()) return *i_++; else return ""; } protected: sep_type_t sep_; tokenizer_t tok_; tokenizer_t::iterator i_; }; class Sub : public Base { public: Sub(std::string s) : Base(s) { std::string t = nextToken(); std::string u = nextToken(); std::string v = nextToken(); } void doSomething() { int x = 0; x +=1; } }; int main (int argc, char **argv) { Sub x("ASIF;Sohail;Kaleem;Maryam;Irfan;Khurram"); x.doSomething(); return 0; } ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// This code is compiling and running fine on GCC 4.6.0 / Fedora 15 / 64-bit. I hope somebody here will help me out on this. Best regards, Asif

3 4

Help with bind usage
by John M. Dlugosz 02 Aug '11

02 Aug '11

Suppose I have something that expects a general function object that takes three parameters. I have a function that takes one parameter, and I don't care about the other two. How do I get an instance func that when called as func(a,b,c) will end up calling my function foo as foo(a) and throw away the other two? If I use bind, I wind up with a functor that takes fewer arguments than the original. But here I have more.

2 1

Article on Boost.Asio in German computer magazine c't
by Boris Schaeling 01 Aug '11

01 Aug '11

I submitted today an article on Boost.Asio which will be published in the German computer magazine c't. I don't know yet in which edition but will tell on http://www.highscore.de/feed.atom. There may be more articles on Boost in c't in the future which I'll announce on my RSS feed then only (not to spam these lists). All of this hopefully helps to increase media coverage of Boost in the longterm. This again could help if for example BoostCon grows into something bigger. For now the article on Boost.Asio is a small step-stone. :) Boris

1 0

[range] range metafunctions and reference types
by Nathan Ridge 01 Aug '11

01 Aug '11

Hello, The range metafunctions currently do not work on range reference types. For example, the following: #include <vector> #include <boost/range/metafunctions.hpp> typedef boost::range_iterator<std::vector<int>&>::type iter_t; Fails with the errors: In file included from lib/boost/boost/range/iterator.hpp:23:0, from lib/boost/boost/range/metafunctions.hpp:18, from test4.cpp:2: lib/boost/boost/mpl/eval_if.hpp: In instantiation of 'boost::mpl::eval_if_c<false, boost::range_const_iterator<std::vector<int>&>, boost::range_mutable_iterator<std::vector<int>&> >': lib/boost/boost/range/iterator.hpp:72:63: instantiated from 'boost::range_iterator<std::vector<int>&>' test4.cpp:4:49: instantiated from here lib/boost/boost/mpl/eval_if.hpp:60:31: error: no type named 'type' in 'boost::mpl::eval_if_c<false, boost::range_const_iterator<std::vector<int>&>, boost::range_mutable_iterator<std::vector<int>&> >::f_ {aka struct boost::range_mutable_iterator<std::vector<int>&>}' This behaviour is OK when you are doing things like this: template <typename Range> typename range_iterator<Range>::type some_function(const Range& r) { ... } because when called with a "const vector<T>&" argument, template argument deduction will deduce "Range" to be just "vector<T>", and this is what we call the metafunction on. Likewise, if some_function has a non-const version that takes a "Range&" argument, it works fine too. But in C++0x, rvalue references allow us to kill two birds with one stone and have just one function that accepts both const and non-const references: template <typename Range> typename range_iterator<Range>::type some_function(Range&& r) { ... } However, the template argument deduction rules for rvalue references are different: if the function is called with a "const vector<T>&" parameter, "Range" will be deduced as "const vector<T>&", i.e. the reference is preserved. But now range_iterator gives an error as indicated above, so we have to do something awkward and verbose like this: template <typename Range> typename range_iterator<typename remove_reference<Range>::type>::type some_function(Range&& r) { ... } Could the range metafunctions be modified to accept range reference parameters and remove the reference themselves? Thanks, Nate.

2 3

[Serialization] Linker error on BOOST_CLASS_EXPORT upgrading from 1.44.0
by Enrico Carrara 01 Aug '11

01 Aug '11

Hello, I am facing a problem with serialization as implemented in Boost 1.47.0 which I did not experience in version 1.44.0. The problem appears as a series of linker errors (Visual C++ 8.0 (VS2005), WinXP 32bit): 1>Compiling... 1>Model_SerializationXml.cpp 1>Model_SerializationTxt.cpp 1>Compiling manifest to resources... 1>Linking... 1>Model_SerializationXml.obj : error LNK2005: "public: static struct boost::archive::detail::extra_detail::guid_initializer<class sm::CompLoad_Test> const & const boost::archive::detail::extra_detail::init_guid<class sm::CompLoad_Test>::g" (?g@?$init_guid@VCompLoad_Test@sm@@@extra_detail@detail@archive@boost @@2ABU?$guid_initializer@VCompLoad_Test@sm@@@2345@B) already defined in Model_SerializationTxt.obj [...many more similar errors] The scenario is as follows: I have a considerable bunch of classes which must be serialized by means of both text and XML archives. To this purpose, I have two compilation units, "Model_SerializationTxt.cpp" and "Model_SerializationXml.cpp", as follows: ///////////////////////////////////////////////// // Model_SerializationTxt.cpp [...] #include <boost/archive/text_iarchive.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/archive_exception.hpp> [...] #include "SerClassExport.h" [...] ///////////////////////////////////////////////// ///////////////////////////////////////////////// // Model_SerializationXml.cpp [...] #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/archive_exception.hpp> [...] #include "SerClassExport.h" [...] ///////////////////////////////////////////////// ///////////////////////////////////////////////// // SerClassExport.h [...] // APPLICATION_DEPENDENT: Include here files // relevant to model classes to be exported // for serialization #include "Model_Root.h" #include "SM/SM_Node.h" [...Many more class definition headers] [...] #include <boost/serialization/export.hpp> // APPLICATION_DEPENDENT: Include here files // relevant to model classes to be exported // for serialization BOOST_CLASS_EXPORT(model::Root) BOOST_CLASS_EXPORT(sm::Node) [...Many more class export definitions] [...] ///////////////////////////////////////////////// The problem seems to be related to the fact that BOOST_CLASS_EXPORT is defined twice in my project. In Boost 1.44.0, struct guid_initializer was defined in "export.hpp" inside an anonymous namespace, while in Boost 1.47.0 - actually, since version 1.45.0 - the definition is inside namespace extra_detail, even if the comment above is unchanged: ///////////////////////////////////////////////// // export.hpp in Boost 1.44.0 [...] // Note INTENTIONAL usage of anonymous namespace in header. // This was made this way so that export.hpp could be included // in other headers. This is still under study. namespace { template<class T> struct guid_initializer [...] #define BOOST_CLASS_EXPORT_IMPLEMENT(T)\ namespace boost {\ namespace archive {\ namespace detail {\ namespace {\ template<>\ struct init_guid< T > {\ static guid_initializer< T > const & g;\ };\ guid_initializer< T > const & init_guid< T >::g =\ ::boost::serialization::singleton<\ guid_initializer< T >\ >::get_mutable_instance().export_guid();\ }}}}\ [...] ///////////////////////////////////////////////// ///////////////////////////////////////////////// // export.hpp in Boost 1.47.0 [...] // Note INTENTIONAL usage of anonymous namespace in header. // This was made this way so that export.hpp could be included // in other headers. This is still under study. namespace extra_detail { template<class T> struct guid_initializer [...] #define BOOST_CLASS_EXPORT_IMPLEMENT(T)\ namespace boost {\ namespace archive {\ namespace detail {\ namespace extra_detail {\ template<>\ struct init_guid< T > {\ static guid_initializer< T > const & g;\ };\ guid_initializer< T > const & init_guid< T >::g =\ ::boost::serialization::singleton<\ guid_initializer< T >\ >::get_mutable_instance().export_guid();\ }}}}\ [...] ///////////////////////////////////////////////// I guess that this might have a role in originating the linker problem. How can I avoid this error? I already tried including the list of BOOST_CLASS_EXPORT only once, i.e in Model_SerializationTxt.cpp only. This solved the linker problem, but serialization of data in XML was then impossible (runtime error). Unfortunately, merging the two compilation units in one is not possible, because the compiler (Visual C++ 8.0) goes out of memory while compiling the big unit (process memory grows beyond 2GB). Is there, in your opinion, a solution or a workaround to this situation? Let me apologize for the very long mail, I did not succeed in shortening it further. Looking forward to any possible advice, thank you in advance for your attention. Enrico

2 5

Boost::Tokenizer - "string iterators incompatible"
by asif saeed 01 Aug '11

01 Aug '11

Hi, The following piece of code is giving me "string iterators incompatible" error: ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// #include <iostream> #include <string> #include <boost/tokenizer.hpp> class Base { public: typedef boost::char_separator<char> sep_type_t; typedef boost::tokenizer<sep_type_t> tokenizer_t; Base(std::string s) : sep_(";"), tok_(s,sep_), i_(tok_.begin()) { } std::string nextToken() { if (i_!=tok_.end()) return *i_++; else return ""; } protected: sep_type_t sep_; tokenizer_t tok_; tokenizer_t::iterator i_; }; class Sub : public Base { public: Sub(std::string s) : Base(s) { std::string t = nextToken(); std::string u = nextToken(); std::string v = nextToken(); } void doSomething() { int x = 0; x +=1; } }; int main (int argc, char **argv) { Sub x("ASIF;Sohail;Kaleem;Maryam;Irfan;Khurram"); x.doSomething(); return 0; } ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// This code is compiling and running fine on GCC 4.6.0 / Fedora 15 / 64-bit. I hope somebody here will help me out on this. Best regards, Asif

1 0

[units] How to multiply a quantity with a dimensionless factor
by Marcel 01 Aug '11

01 Aug '11

Hi, I'm new to boost and units and hope this is not too trivial. If I try to multiply a quantity with a dimensionless factor like quantity<length> a; quantity<length> b = 2.0 * b; I get compiler errors due to missing operator*. So I worked around this by using quantity<length> b = quantity<dimensionless>(2.0) * b; But I'm wondering if there is a easier and better readable way to do this? Thank you in advance, Marcel

2 3

Execution problem moving libraries
by Alessandro Candini 01 Aug '11

01 Aug '11

Hi everyone. I get a very tricky error with boost.thread. I can compile and execute perfectly a C++ program with the following comand line: g++ -Wall -fPIC -pedantic -g -O3 -DDEBUG -march=native -std=c++0x -lboost_thread -o myExecutable myExecutable.cpp But I have to move this software into another machine, and I thought it was possible to take dynamic libraries with it, in order to properly link them to the executable. I have a structure like the following: package | bin |- myExecutable etc |- libboost_thread.a |- libboost_thread.so -> libbost_thread.so.1.42.0 `- libboost_thread.so.1.42.0 And performing a proper export of LD_LIBRARY_PATH, it seems I obtain a correct link: ldd myExecutable ... libboost_thread.so.1.42.0 => ../etc/libboost_thread.so.1.42.0 (0x002cd000) ... But when I try to execute my software, I obtain the following error: /home/user/myExecutable symbol lookup error: /home/user/myExecutable: undefined symbol: _ZTIN10__cxxabiv115__forced_unwindE Do you have an idea of why this occurs? Have I to compile boost libraries in an uncommon way to make this situation work? Thank you. -- Alessandro Candini MEEO S.r.l. Via Saragat 9 I-44122 Ferrara, Italy Tel: +39 0532 1861501 Fax: +39 0532 1861637 http://www.meeo.it ======================================== "ATTENZIONE:le informazioni contenute in questo messaggio sono da considerarsi confidenziali ed il loro utilizzo è riservato unicamente al destinatario sopra indicato. Chi dovesse ricevere questo messaggio per errore è tenuto ad informare il mittente ed a rimuoverlo definitivamente da ogni supporto elettronico o cartaceo." "WARNING:This message contains confidential and/or proprietary information which may be subject to privilege or immunity and which is intended for use of its addressee only. Should you receive this message in error, you are kindly requested to inform the sender and to definitively remove it from any paper or electronic format."

4 5