March 2008 - Boost-users - lists.preview.boost.org

[Boost.Test] reports incorrect memory leak
by mike 14 Apr '08

14 Apr '08

An extremely simple piece test, containing just one stack-created object, is causing boost.test to report a memory leak. I am using boost 1.34.1 compiled in windows using configure, bjam, & msvc90. I've copied my simple test case illustrating my problem below, and included the output it produces. As you can see, boost.test is being used, but the regex is part of microsoft's tr1. As a note, when I modify it to use boost's regex (with the commented-out changes seen in code), no such errors were reported. I'd like to say that obviously the SOLE problem lies in MS' beta tr1 implementation, but this code is so simple I don't get how that would be. Also, i believe the actual TR1 impl is from dinkumware and is supposed to be fully release ready (it is just the ms-CLI, etc, integration which leads to the beta designation)... Hopefully someone has more insight into this. Also, if someone has any tips on how to interpret the memory dump boost.test provides, I'd be interested in learning. Thanks in advance! //begin code// //file dumb_test.cpp //in a new, default solution w/ precompiled headers turned off, //all msvc files removed, and include_path += $(boost_root) //lib_path += $(boost_root)/stage/lib added #include <boost/test/unit_test.hpp> #include <regex> //#include <boost/tr1/tr1/regex> using boost::unit_test_framework::test_suite; using std::tr1::regex; //using boost::regex void dumb_test(){ regex rgx(""); //regex rgx("foo");//boost doesn't like empty rgx str } test_suite* init_unit_test_suite(int, char** const){ test_suite* suite = BOOST_TEST_SUITE("Core Tests"); suite->add(BOOST_TEST_CASE(&dumb_test)); return suite; } //end code// //begin output// Running 1 test case... *** No errors detected Detected memory leaks! //with boost::regex no mem leaks... Dumping objects -> {208} normal block at 0x00347DD8, 20 bytes long. Data: <p-J > 70 2D 4A 00 15 00 00 00 00 00 00 00 00 00 00 00 {207} normal block at 0x00347D90, 24 bytes long. Data: <|-J }4 > 7C 2D 4A 00 0E 00 00 00 00 00 00 00 D8 7D 34 00 {206} normal block at 0x00347D48, 24 bytes long. Data: < -J }4 > 88 2D 4A 00 0D 00 00 00 00 00 00 00 90 7D 34 00 {205} normal block at 0x00347CF8, 32 bytes long. Data: <p-J H}4 > 70 2D 4A 00 14 00 00 00 00 00 00 00 48 7D 34 00 Object dump complete. //end output//

4 3

i18n
by Olaf Peter 09 Apr '08

09 Apr '08

Hi, what would be the best approach for a new software project running on unix/win/osx regards to i18n? As may point of view there are gettext using with boost.format or gnu::autosprintf. What would be the adavantages/disadvantages of these? Any experience, other possibilities? Thanks, Olaf

4 3

Floating Point Utilities Review Result
by John Maddock 05 Apr '08

05 Apr '08

Floating Point Utilities Review Result. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ There were 6 positive reviews and no negative ones, so Johan Rade's Floating Point Utility library has been accepted into Boost. The main issues and topics that came up for discussion were: 1) A couple of minor bugs were uncovered relating to signed NaN testing when using the SSE2 registers, and deserialising NaN's: both were fixed during the review period. 2) We had a discussion about the usefulness or otherwise of signed NaN's and the changesign function: Johan agreed to drop support for these as the signbit of NaN's is not considered part of the NaN payload and need not be preserved by the compiler, this could usefully be summarised in a rationale: especially now that negative NaN's are not formatted with a "-" sign? 3) JM made a few quite fruitless suggestions about optimising away calls to memcpy: this should be documented in a rationale to prevent JM from making the same mistake again :-) 4) John Phillips raised the issue of finding these tools - making sure that they don't get lost amongst all the other special functions and "stuff" in Boost.Math. JM and Johan have agreed to work together to ensure this doesn't happen. 5) There were a couple of suggestions for a convenience function for installing the facets in a locale/iostream: Johan agreed to add this. 6) There was +1 vote for manipulators rather than flags to the facet constructors - further investigation suggested this was problematic in a header only library - so the suggestion was dropped. 7) There was one comment about the library not using quickbook for documentation: ideally it would be nice to see this fixed so that the docs integrate seamlessly with the rest of Boost.Math - but see #4 as well. Many thanks to Johan for making these utilities available. John Maddock. Review Manager for the Floating Point Utilities.

2 5

[boost::function] Getting base class pointer of functor ?
by Johannes Stallkamp 04 Apr '08

04 Apr '08

Hello there, Short version: Are there any reasons, why base class access is currently not allowed/implemented in boost::function (via target() function)? Long version/explanation/scenario: I have a class using boost::any which I use for data exchange between different modules of my program. Some modules are able to process the data if it contains "numbers" (in contrast to other arbitrary data structures), ie. basically POD. These modules do not necessarily bother what _exact_ type the provided number is (some do, some don't) and might just use it as, e.g. double, so they don't care what type was originally inserted into the boost::any as long as they get a double-converted value out of it. As boost::any only allows to get the original type out of it with any_cast<T>, the class provides a set of conversion functions like boost::function< int () > toInt; boost::function< short () > toShort; ... ... struct Converter_base { Converter_base( const boost::any* a ) : m_any(a) {}; public: const boost::any* m_any; }; template< typename Target, typename Source > struct Converter : public Converter_base{ Converter( const boost::any* a ) : Converter_base(a) {}; T operator()() const { return boost::numeric_cast<Target>( * boost::any_cast<Source>( Converter_base::m_any ) ); }; }; template< typename SourceType > void setValue ( SourceType& value ) { m_value = value // this is boost::any toInt = Converter< int, SourceType > ( &m_value ); toShort = Converter< short, SourceType > ( &m_value ); ...... } This allows me to ask for the value converted to my desired type and receiving an exception if the conversion is not possible (or produces overflows). The problem is that the functor Converter is not copy-constructible because of the pointer to boost::any. So I have to take care of setting the correct pointer in the copy constructor of my data exchange class. In order to get the pointer to the converter functor and thus to the mep_any, I need to know SourceType. But since the module that provides the data and the module that consumes the data don't know about each other, the consumer doesn't know SourceType and cannot compile the appropriate copy constructor. Since mep_any is independent from the template arguments, I moved it to a base class Converter_base and let Converter inherit from it. Now, I want to access the functor via toInt.target<Converter_base>() in order to access/update the mep_any. But target() returns 0 .... I checked function/function_base.hpp and found: // DPG TBD: Since we're only storing a pointer, it's // possible that the user could ask for a base class or // derived class. Is that okay? Are there any reasons, why base class access is currently not allowed/implemented? Sorry that the post got a bit long, but I hope at leas my intention got somehow clear... Johannes

5 5

Boost tokenizer and range support
by Florin Trofin 03 Apr '08

03 Apr '08

Hi, I've been using the boost tokenizer successfully in the past and I've been quite happy with it. I was using it with std::string as my token type, but now I need to use it differently because of performance reasons (the input string is a raw UTF8 buffer (const unsigned char*) and output is a specific UTF16 string class). So I thought: maybe I can just tokenize the unsigned char buffer in place using boost::iterator_range<const unsigned char*> as my token type. And it almost worked! With a hack: the tokenizer attempts to call assign on my TokenType but boost::iterator_range doesn't have such member function. I created a wrapper class that simply delegates to the iterator_range's assignment operator and it now works! This is great because I have no more useless string constructions: I can go directly from a raw UTF8 buffer to my output string type (UTF16 based) with only one conversion and no extra allocations! I still have the nice syntax of boost tokenizer and the maximum efficiency! I think this solution should be mentioned in the tutorial docs because it might not be obvious for everybody. Also, maybe we can eliminate the hack I did by adding an assign() to the boost range interface (this seems simpler to me than modifying the tokenizer to not call assign). Thanks for the great work you guys put into this library! Best regards, Florin.

2 3

1.35.0 - what is the correct tag in SVN?
by Andrey Tcherepanov 02 Apr '08

02 Apr '08

Hello! I am wondering by what tag or branch (besides "release") (or just version) I can retrieve exatly same snapshot that was used for 1.35.0 from Subversion? Previous releases are available by RC_* tags, so I am wondering which one is used for 1.35? As general comment - may be is a good idea to have top "branch" called "releases" and then all packaged releases under it, so it is easier to find them in one place instead of going trhough all new and old working folders under branches subtree? Thank you very much, Andrey

3 5

Need boost's help with poor design
by Robert Dailey 02 Apr '08

02 Apr '08

Hi, Currently I'm using Boost.Signals to transfer Packet objects to subscribers. Right now my Boost.Signal looks like below: boost::signal<void (Packet const& p)> Right now Packet is the base class for several other packet types, each having the specific data a subscriber needs access to. Of course, given this design, the only way to obtain the data is to perform a downcast via static_cast or dynamic_cast: WalkPacket const& wp = static_cast<WalkPacket const&>( p ); // 'p' here is a generic Packet object. This is obviously bad design since it isn't type safe at all. It's also repetitive and tedious since each subscriber must duplicate the logic to perform the downcast. I'm wondering if there's anything in Boost you guys can suggest that I use to make this a little better. I would prefer to have a common Signal object that can take differently typed Slot objects. For example, I want to pass in a slot that looks like: "void (WalkPacket& p)" and have the signal utilize implicit conversions or something. Templates aren't even being used here because I can't find a way to fit them in, since everything is being done at runtime and not compile time. Keep this important note in mind: The type of the packet that will be dispatched to subscribers can only be known at compile time via a factory method. Data is received from the network, and that data is packed into the correct packet and returned as a Packet* base class pointer, so that we can transfer the data to subscribers through a common interface.

8 55

boost::variant build crashes Visual C++
by a a 01 Apr '08

01 Apr '08

Hello, I have a simple program to test boost::variant. Under Visual C++ 2005, configuration Release (/MD), the build fails with C1060 (out of heap space). The program compiles and runs as expected under Visual C++ 2005 Debug (/MTd), and under Visual C++ 2008 Express, Release and Debug. Below is the code. Any idea what's wrong? Many Thanks, Eric #include <set> #include <string> #include <vector> #include <iostream> #include <fstream> #include <map> #include <boost/variant.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/variant.hpp> #include <boost/serialization/vector.hpp> #include <boost/serialization/map.hpp> struct empty_property_tag { template<class Archive> void serialize(Archive &ar, const unsigned int) {} }; typedef boost::make_recursive_variant<empty_property_tag, std::string, long, double, std::vector<bool>, std::vector<long>, std::vector<double>, std::vector<std::string>, std::vector<std::vector<bool> >, std::vector<std::vector<long> >, std::vector<std::vector<double> >, std::vector<std::vector<std::string> >, std::vector<boost::recursive_variant_>, std::vector<std::vector<boost::recursive_variant_> > >::type property_t; class print_visitor : public boost::static_visitor<> { std::string m_indent; public: print_visitor(const std::string& indent) : m_indent(indent) {} print_visitor(const print_visitor& p) : m_indent(p.m_indent) {} void operator()(const bool& i) const { std::cout << m_indent << "It's an bool: " << i << '\n'; } void operator()(const std::string& s) const { std::cout << m_indent << "It's a std::string: " << s << '\n'; } void operator()(const double& d) const { std::cout << m_indent << "It's a double: " << d << '\n'; } void operator()(const long& d) const { std::cout << m_indent << "It's a long: " << d << '\n'; } void operator()(const empty_property_tag& e) const { std::cout << m_indent << "It's an empty_property_tag.\n"; } void operator()(std::vector<property_t>& v) const { print_visitor p(m_indent + "\t"); std::cout << m_indent << "It is a vector of size: " << v.size() << "\n"; for(std::vector<property_t>::iterator i = v.begin(); i != v.end(); ++i) boost::apply_visitor(p, *i); } void operator()(std::vector<std::vector<property_t> >& v) const { print_visitor p(m_indent + "\t"); std::cout << m_indent << "It is a vector of of vectors size: " << v.size() << "\n"; for(std::vector<std::vector<property_t> >::iterator i = v.begin(); i != v.end(); ++i) operator()(*i); } template <typename T> void operator()(std::vector<T>& v) const { std::cout << m_indent << "It is a vector of size: " << v.size() << "\n"; for(typename std::vector<T>::iterator i = v.begin(); i != v.end(); ++i) std::cout << m_indent << '\t' << *i << '\n'; } template<typename T> void operator()(std::vector<std::vector<T> >& v) const { print_visitor p(m_indent + "\t"); std::cout << m_indent << "It is a vector of size: " << v.size() << "\n"; for(typename std::vector<std::vector<T> >::iterator i = v.begin(); i != v.end(); ++i) operator()<T>(*i); } }; void main() { property_t q = "aaa"; print_visitor p(""); boost::apply_visitor(p, q); }

3 6

Eclipse integration of bjam
by Ruediger Berlich 01 Apr '08

01 Apr '08

Dear all, I am using Eclipse/CDT under Linux as my standard IDE. So far I'm building my projects using Eclipse's own build mechanisms. Is anybody using bjam as a build mechanism in Eclipse/CDT and should I expect problems when making a switch to bjam ? Thanks and Best Regards, Ruediger

12 15

calling function objects in a fusion vector
by Sebastian Weber 01 Apr '08

01 Apr '08

Hi all! I'm starting to play with boost::fusion and I am amazed by its power - thanks for the library, its great! Nevertheless, I ran into some trouble: I have fusion vector of function objects which all have the same arity and take the same arguments. Now I want to call each function object via the fusion::invoke method, as I have the arguments also on in a fusion vector, so something like this: typedef fusion::vector< binary_function1, binary_function2, ...> funcVec; typedef fusion::vector< double, int > argType; funcVec funs; argType args(0.5, 3); Now my idea was to use boost::bind to do the trick like this: boost::transform(funcVec, bll::bind(&fusion::invoke<>, _1, args)); However, this does not work - the bind complains about unresolved overloaded function type. So, what is wrong here? Thanks a lot in advance for any help. Greetings, Sebastian Weber

2 1