April 2011 - Boost - lists.preview.boost.org

[accumulators] regression tests and MingW/gcc-4.5.2
by Edward Diener 28 Apr '11

28 Apr '11

Attempting to run regression tests for accumulators from Boost trunk using MingW/gcc-4.5.2 leads to Vista popping up with messages that cc1plus.exe ( gcc's compiler ) has stopped working. Any ideas why this is happening. For other versions of MingW/gcc the accumulators regression tests work normally.

4 8

[numeric] Is there interest in detecting precision loss?
by Antony Polukhin 28 Apr '11

28 Apr '11

There have been some requests for detecting precision loss during conversion from float types to integral types. But the current numeric converter just rounds the float number. This proposal provides two classes, that can be used as a Float2IntRounder in boost::numeric::converter. One of them determinates, is there any precision loss, the second class determinates is there precision loss before user supported sign in decimal part. On precision loss an exception boost::numeric::precision_loss_error is thrown. The proposal can be found at https://docs.google.com/document/d/1IsA40cq9kYF31jDM_tyIvVNnvC5-uI9-5ez52pz… Tests (and usage examples) can be found at https://docs.google.com/document/d/1cbYYDcL1t0jbZ7hUFqXODu3VKoWe4_A5IMdXHN5… Is there interest in this for Boost? If there is, shall I add documentation?

1 0

[Mutual Pointer] Docs
by Phil Bouchard 28 Apr '11

28 Apr '11

Hi, I renamed the pointer once more to mutual_ptr and I added a caveat to the documentation. It is accessible here: https://svn.boost.org/svn/boost/sandbox/mutual_ptr/libs/smart_ptr/doc/tutor… -Phil

2 3

[review] boost::convert
by Jeroen Habraken 28 Apr '11

28 Apr '11

Hi, My review: -- What is your evaluation of the design? The overall design is very flexible, there are a few points though: - Although this might be a matter of taste I find the choice of operator >> to add modifiers rather odd, it smells a bit like operator abuse. Also, it forces you to use braces in std::cout << (boost::convert<int>::from("12") >> std::hex) << "\n"; for example, maybe using a member function is an option. - In might be nice to add a way to return a default-constructed object to the non-throwing interface. This is useful in combination with boost::optional: boost::convert<boost::optional<int> >::from_default("XXX") returning an boost::optional<int>() instead of having to write boost::convert<boost::optional<int> >::from("XXX", boost::optional<int>());. -- What is your evaluation of the implementation? Had a quick read through the code, it looks fine except that names containing "__" are reserved (used in the include guards). -- What is your evaluation of the documentation? The documentation covers all aspects of the library quite nicely. This in contrast to the reference which seems mostly empty, in my opinion it doesn't add much and can simply be removed. Since the behaviour of convert seems to be different to lexical_cast (see below) it might be useful to add a section listing these differences. Lastly the documentation contains a couple of examples, it would be nice to have these as separate files in libs/convert/example. -- What is your evaluation of the potential usefulness of the library? The library is very flexible and the extra features are nice, however there is a rather large problem, in my opinion. This is the domain of boost::lexical_cast, a library that has matured over the years and is in heavy use. It can not be deprecated or worse, removed. Even though it has problems (mostly missing functionality, which boost::convert has implemented) I do not believe adding a second library is a proper solution. Instead this functionality should be added to boost::lexical_cast itself (and patches to do so have been proposed over the years). -- Did you try to use the library? With what compiler? Did you have any problems? Yes, on Mac OS X with both gcc 4.2.1 (the default shipped by Apple) and 4.5.2. Problems: - boost::convert<int>::from("-123.2") behaves differently from boost::lexical_cast<int>("-123.2"), the former returns -123 whilst the latter throws. Whilst I'm not saying one is better than the other, the differences should be documented for people switching. - boost::convert<int>::from('1') results in a rather long error message (http://codepad.org/YgoR8H2t) if the conversion from X to Y isn't possibly this should be made clear in a more user-friendly way. -- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've read the documentation, had a quick glance at the source code and tried the basic functionality of the library. -- Are you knowledgeable about the problem domain? As the author of boost::coerce I'm familiar with the conversion domain, however I'm less familiar with the locale domain. -- Do you think the library should be accepted as a Boost library? No it should not, instead the extra functionality should be added to boost::lexical_cast. Kind regards, Jeroen Habraken

3 5

[Review] Boost.Convert library is ongoing
by Edward Diener 27 Apr '11

27 Apr '11

Since there have been no reviews of this library yet, this is another reminder that formal review of the Boost.Convert library by Vladimir Batov is ongoing and ends on May 2. If you have felt that lexical_cast is not flexible enough for use, please take a look at this library and review it. *************** * Its Purpose * *************** The library builds on the past boost::lexical_cast experience, then takes those conversion-related ideas further to suit better today's applications and programing needs. It still offers simple, minimal interface, familiar conversion behavior and additionally provides: * throwing and non-throwing conversion-failure behavior; * support for the default/fallback value to be returned when conversion fails; * two types of the conversion-failure check - basic/simple and better/safe; * formatting support based on the standard std::streams and std::stream-based manipulators (like std::hex, std::scientific, etc.); * support for different locales; * support for boost::range-compliant char and wchar_t-based containers; * no DefaultConstructibility requirement for the Target/Destination type; * consistent framework to uniformly incorporate any type-to-type conversions, extensibility and additional room to grow. With its present support for string-to-type and type-to-string conversions it is an essential tool for applications making extensive use of configuration or MS-Windows-Registry-style files or having to process/prepare considerable amounts of data in, say, XML, etc. More so, it is easily extendable to accommodate, specialize and uniformly deploy new user-defined type-to-type conversions. ******************* * Where to get it * ******************* You can get the library, using Subversion, from https://svn.boost.org/svn/boost/sandbox/convert. The HTML documentation is part of the distribution and can be found at libs/convert/index.html in the distribution above. ******************** * Writing a review * ******************** The reviews and all comments should be submitted to the developers list, and the email should have "[convert] Review" at the beginning of the subject line to make sure it's not missed. Please explicitly state in your review whether the library should be accepted. The general review checklist: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Edward Diener, Review Manager

3 2

[msm] need to increase the fusion set and map size to 30
by Kim Kuen Tang 27 Apr '11

27 Apr '11

Hi all, i defined a transition table with more than 20 transitions. After that the compiler complained that a fusion set is only defined up to 10 elements. So i added the following statement in the file as indicated by the doc. #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_VECTOR_SIZE 30 //or whatever you need #define BOOST_MPL_LIMIT_MAP_SIZE 30 //or whatever you need However this does not solve the problem, since it is fusion who is complaining. So i added these two statements at the beginning, and this solved the problem. # define FUSION_MAX_SET_SIZE 30 # define FUSION_MAX_VECTOR_SIZE 30 Perhaps we can add this somewhere in the doc. Kind regards , Kim

1 0

[TR1] tr1 functional compile time looks strange
by falcou 27 Apr '11

27 Apr '11

An empty file including only boost/tr1/functional.hpp seems to compile in 3s ... Does any of the latest patches botched something here ?

3 5

[Memory Managed Pointer] Review Request
by Phil Bouchard 27 Apr '11

27 Apr '11

Greetings, I apologize for all the confusion but I renamed once more the memory manager to mm_ptr. Its documentation is accessible at: https://svn.boost.org/svn/boost/sandbox/mm_ptr/libs/smart_ptr/doc/index.html Regards, -Phil

8 21

accurate sum accumulator (kahan)
by Gaetano Mendola 27 Apr '11

27 Apr '11

Hi all, I had to implement in terms of boost accumulators the Kahan summation algorithm. I will paste at the end of this message the accumulator, the feature and the extractor source code. This accumulator reduces the numerical error obtained with standard sequential sum, as example the sum of 1e6f elements equal to 1e-6f should give 1.0f, this is the results obtained with sum and sum_kahan: tag::sum: 1.009038925 tag::sum_kahan: 1.000000000 I'm not sure if that sum_kahan is worth to be inserted in the accumulators provided with boost, I'm not an expert of boost:accumulators (I just followed the guide to make this new accumulator) so not sure if you prefer to have a fast_sum and an accurate_sum instead of sum and sum_kahan. Regards Gaetano Mendola // File kahan_sum.hpp #ifndef KAHAN_SUM #define KAHAN_SUM #include <boost/accumulators/framework/accumulator_base.hpp> #include <boost/accumulators/framework/parameters/sample.hpp> #include <boost/numeric/conversion/cast.hpp> namespace boost { namespace accumulators { namespace impl { template<typename Sample> struct sum_kahan_accumulator : accumulator_base { typedef Sample result_type; template<typename Args> sum_kahan_accumulator(Args const & args) : sum(args[sample | Sample()]), compensation(boost::numeric_cast<Sample>(0.0)) { } template<typename Args> void operator ()(Args const & args) { const Sample myTemp1 = args[sample] - this->compensation; const Sample myTemp2 = this->sum + myTemp1; this->compensation = (myTemp2 - this->sum) - myTemp1; this->sum = myTemp2; } result_type result(dont_care) const { return this->sum; } private: Sample sum; Sample compensation; }; }}} namespace boost { namespace accumulators { namespace tag { struct sum_kahan : depends_on< > { typedef impl::sum_kahan_accumulator< mpl::_1 > impl; }; }}} namespace boost { namespace accumulators { namespace extract { extractor< tag::sum_kahan > const sum_kahan = {}; } using extract::sum_kahan; }} #endif

21 68

[Config] A proposal to Boost.Config.
by Kohei Takahashi 27 Apr '11

27 Apr '11

Hi, Boost.Config provides BOOST_PLATFORM macro (it will expand to strings). However, it cannot use to switch including header like followings. #include <boost/config.hpp> #include "somedir/" BOOST_PLATFORM "/someheader.hpp" So, I propose a new macro BOOST_PLATFORM_LABEL (change to more suitable name). That provide not stringized platform name like this. #define BOOST_PLATFORM_LABEL linux By using such macro, will be able to switch including header. #include <boost/config.hpp> #include <boost/preprocessor/stringize.hpp> #include BOOST_PP_STRINGIZE( somedir/BOOST_PLATFORM_LABEL/someheader.hpp ) However, such macro has a problem. For example, it fail including when *linux* (or another label) defined to other symbol. #include <boost/config.hpp> #include <boost/preprocessor/stringize.hpp> #define linux others #include BOOST_PP_STRINGIZE( somedir/BOOST_PLATFORM_LABEL/someheader.hpp ) // Oops! Expand to somedir/others/someheader.hpp in linux. How do you feel this macro? Thanks. -- TAKAHASHI Kohei College of Information Science, University of Tsukuba private mail: flast(a)flast.jp others: flast(a)ac-room.org s0911476(a)coins.tsukuba.ac.jp

2 2