August 2012 - Boost - lists.preview.boost.org

interest in generic cyclic visitor?
by Jan Herrmann 06 Aug '12

06 Aug '12

Hello, I have an implementation of generic cyclic visitor. It is available at https://github.com/janherrmann/visitor . With my implementation it is possible to create non-member, non-friend templates which behave like virtual functions. Additionally it can be used as a base for multimethod implementation. Moreover it can be used to build a extensible type information system. All test cases compile with msvc-10.0 and gcc-mingw-4.6.2. Is there need for such a library? Jan Herrmann

3 5

[multiprecision] Some Performance gains
by John Maddock 05 Aug '12

05 Aug '12

Following the review of the multiprecision lib, I've been experimenting with some of the issues raised, currently focusing on performance improvements. Anyhow, I now have some results for improved *front end* performance, I haven't tried to seriously optimize the cpp_int backend yet (which was one of the criticisms), but for more on that see below. So... by way of measuring front end performance - the "abstraction penalty" if you like I've used a special backend type "arithmetic_backend<A>" where A can be any builtin arithmetic type. For tests I've used Boost.Math's special function test data for floating point types, and Phil Endecott's Delaunay code for integer performance. Win32 VC10 first: Delaunay test: int64_t : 9.45241 mp_number<arithmetic_backend<int64_t>, false> : 9.66815 Bessel Functions Test: Time for Bessel Functions - double = 0.015859 seconds Time for Bessel Functions - arithmetic_backend<double> - no expression templates = 0.0225565 seconds Time for Bessel Functions - arithmetic_backend<double> = 0.0376449 seconds Non Central T: Time for Non-central T - double = 0.456739 seconds Time for Non-central T - arithmetic_backend<double> - no expression templates = 0.459957 seconds Time for Non-central T - arithmetic_backend<double> = 1.08256 seconds Ubutunu Linux x64, GCC-4.6.1: Delaunay Test: int64_t 2.3969 mp_number<arithmetic_backend<int64_t>, false> 2.38334 Bessel Functions Test: Time for Bessel Functions - double = 0.0224617 seconds Time for Bessel Functions - arithmetic_backend<double> - no expression templates = 0.020384 seconds Time for Bessel Functions - arithmetic_backend<double> = 0.0220476 seconds Non central T: Time for Non-central T - double = 0.622985 seconds Time for Non-central T - arithmetic_backend<double> - no expression templates = 0.554527 seconds Time for Non-central T - arithmetic_backend<double> = 0.800129 seconds So to all intents and purposes there's now no abstraction penalty at all, except when using expression templates (which should be reserved for heavyweight backends anyway). Notice how the mp_number code is sometimes slightly faster, and sometimes slightly slower than the native type - I've observed that completely trivial changes to the test/measuring code can change this around - I suspect, but can't prove that the abstraction layer changes the decisions made by the compiler's optimizer resulting in somewhat capricious differences between results. With regard to the cpp_int backend, I still have work to do, however things do actually look pretty good on Linux x64 for the Delaunay test: Running calculations for: int64_t, int128_t (this is Phil's 128-bit special-case code) Number of flips = 23892000 Total execution time = 3.28337 Running calculations for: int64_t, mp_int128_t Number of flips = 23892000 Total execution time = 3.05434 Running calculations for: int64_t, mp_int128_t (ET) Number of flips = 23892000 Time per calculation = 3.02904e-08 Running calculations for: int64_t, cpp_int Number of flips = 23892000 Total execution time = 5.41737 On Win32, I'm still a touch behind Phil's code, however, I haven't written a dedicated NxN->2N multiplication routine (yet): Running calculations for: int64_t, int128_t Number of flips = 23892000 Total execution time = 14.2189 Running calculations for: int64_t, mp_int128_t Number of flips = 23892000 Total execution time = 24.5114 Running calculations for: int64_t, mp_int128_t (ET) Number of flips = 23892000 Total execution time = 19.741 Running calculations for: int64_t, cpp_int Number of flips = 23892000 Total execution time = 33.5 All the new code is in the sandbox, but I haven't documented any of the changes yet... Regards, John.

3 4

[typeof][implementation]why not use decltype or conditional expr?
by Larry Evans 05 Aug '12

05 Aug '12

Why couldn't the BOOST_TYPEOF macro be defined to simply use the new keyword, decltype, if it's available? I assume the macro, BOOST_HAS_DECLTYPE, indicates whether it is available. And if decltype not available, why couldn't it use the conditional expression method described here: http://www.artima.com/cppsource/foreach2.html I would think that would be simpler and more portable. -regards Larry

5 6

Formal review request: TypeIndex library
by Antony Polukhin 05 Aug '12

05 Aug '12

Hi, I'd like to ask to add Boost.TypeIndex to review queue. Introduction TypeIndex is an extended C++11 type_index library, that * works with disabled RTTI * can store const-volatile-reference info about types (if user requested it) * has all the functionality of std::type_index * has portable across compilers and platforms functionality for getting demangled type names * works across modules/shared libraries * does not require C++11 to work Docs: http://apolukhin.github.com/type_index/index.html Git: https://github.com/apolukhin/type_index Sources (zipped): https://github.com/apolukhin/type_index/zipball/master Git contains `patched` folder with TypeIndex'ed (and untested) versions of some existing boost libraries (Boost.Any, Boost.Graph, Boost.Math, Boost.MSM, Boost.PropertyMap, Boost.PropertyTree). Those libraries now do not require RTTI to compile. More libraries could be added to this list. Previous threads (checking interest): * Is there interest in typeid(TYPE).name() like function that does not require RTTI http://lists.boost.org/Archives/boost/2012/05/193491.php * [boost] Is there interest in copyable type_info that does not require RTTI (was: Is there interest in typeid(TYPE).name() like function that does not require RTTI) http://lists.boost.org/Archives/boost/2012/05/193519.php * [boost] [type_index] C++03 implementation in boost? http://lists.boost.org/Archives/boost/2012/07/194627.php P.S.: Additional thanks to Agustín K-ballo Bergé for pointing out and fixing some bugs. P.P.S.: It would be great to schedule review to the end of September. -- Best regards, Antony Polukhin

2 3

[1.51.0] Beta1 release available; release branch open for bug fixes and doc fixes
by Marshall Clow 05 Aug '12

05 Aug '12

The beta releases are available at: http://boost.cowic.de/rc/ They are identical to the rc2 releases. The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1.7z The final release is scheduled for Monday, August 20th. The release candidate is scheduled to to be built Thursday, August 16th. That gives us less than two weeks to apply post-beta bug fixes and doc updates. Until August 13th permission is not required to merge bug fixes and documentation updates. Starting August 13th permission of a release manager is required for all merges. As always, New libraries and new features are not allowed during a post-beta period. Thanks, -- The Release Managers

2 1

[type_erasure] Review ended
by Lorenzo Caminiti 04 Aug '12

04 Aug '12

Hello all, The review of Boost.TypeErasure ended on Aug 3, 2012. Stay tuned for my decision on the library. Thank you very much to Steven, everyone that submitted a review, and everyone that participated in the discussions. The review manager, --Lorenzo On Fri, Aug 3, 2012 at 11:00 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> wrote: > Hello all, > > *** The review of Boost.TypeErasure ends today Aug 3, 2012. If you are > planning to submit a review, please do so by the end of today. *** > > Thank you to all that have participated to the review so far. > > The review manager, > --Lorenzo > > On Jul 27, 2012 1:41 PM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >> >> Hello all, >> >> After consulting the review wizards and Steven, I am extending >> Boost.TypeErasure review of one week, until August 3, 2012. >> >> Thank you to all that have submitted a review already and I am looking >> forward to receiving additional submissions. >> >> The review manager, >> --Lorenzo >> >> On Jul 27, 2012 3:22 AM, "Lorenzo Caminiti" <lorcaminiti(a)gmail.com> wrote: >>> >>> Hello all, >>> >>> On Mon, Jul 23, 2012 at 9:09 AM, Lorenzo Caminiti <lorcaminiti(a)gmail.com> >>> wrote: >>> > On Wed, Jul 18, 2012 at 1:13 AM, Lorenzo Caminiti >>> > <lorcaminiti(a)gmail.com> wrote: >>> >> *** The review of Steven Watanabe's proposed Boost.TypeErasure library >>> >> begins on July 18, 2012 and ends on July 27, 2012. *** >>> > >>> > *** Boost.TypeErasure review ends in 5 days. Please submit your reviews >>> > :D *** >>> >>> *** Boost.TypeErasure review ends today July 27, 2012. If you are >>> planning to submit a review, please do so as soon as possible. *** >>> >>> Thank you to everyone who has commented on the library and submitted a >>> review so far! >>> >>> The review manager, >>> --Lorenzo >>> P.S. I am considering extending the review until end of day Sunday >>> July 29, 2012... I will keep you posted. >>> >>> > There have been interesting discussions on the library on the ML but I >>> > have not received any official review yet :( Especially if you are a >>> > user of Boost Any, Function, and Any Iterator, you definitely want to >>> > take a look at Type Erasure as it generalizes solutions provided by >>> > those other libraries. >>> > >>> > Thank you. >>> > >>> > The review manager. >>> > --Lorenzo >>> > >>> >> THE LIBRARY >>> >> >>> >> C++ provides runtime polymorphism through virtual functions. They are >>> >> a very useful feature, but they do have some limitations. >>> >> * They are intrusive. In generic programming, we can design an >>> >> interface which allows third-party types to be adapted to it. >>> >> * They require dynamic memory management. Of course, most of the >>> >> problems can be avoided by using an appropriate smart pointer type. >>> >> Even so, it still acts like a pointer rather than a value. >>> >> * Virtual functions' ability to apply multiple independent concepts to >>> >> a single object is limited. >>> >> The Boost.TypeErasure library solves these problems allowing us to >>> >> mirror static generic programming at runtime. >>> >> >>> >> Library source: >>> >> http://svn.boost.org/svn/boost/sandbox/type_erasure/ >>> >> >>> >> Pre-built documentation: >>> >> >>> >> http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ >>> >> >>> >> You can also download archives with pre-built documentation from: >>> >> http://sourceforge.net/projects/steven-watanabe.u/files/ >>> >> >>> >> YOUR REVIEW >>> >> >>> >> Please submit a review to the mailing-list by replying to this email >>> >> ("[boost] [type_erasure] Review ..." should be in the subject). >>> >> >>> >> Please state clearly whether you think this library should be accepted >>> >> as a Boost library. >>> >> >>> >> Other questions you may want to consider: >>> >> 1. What is your evaluation of the design? >>> >> 2. What is your evaluation of the implementation? >>> >> 3. What is your evaluation of the documentation? >>> >> 4. What is your evaluation of the potential usefulness of the library? >>> >> 5. Did you try to use the library? With what compiler? Did you have >>> >> any problems? >>> >> 6. How much effort did you put into your evaluation? A glance? A >>> >> quick reading? In-depth study? >>> >> 7. Are you knowledgeable about the problem domain? >>> >> >>> >> Thanks in advance to all who participate in the review discussion -- >>> >> I'm looking forward to it!

1 0

[build] guru needed: static vs dynamic lib conundrum for serialization/filesystem library
by Robert Ramey 04 Aug '12

04 Aug '12

The serialiation library uses the boost.filesystem component in it's tests. On tests which test dlls on windows I'm getting an error: test_dll_exported.cpp ..\..\..\boost\filesystem\config.hpp(69) : fatal error C1189: #error : Must not define both BOOST_FILESYSTEM_DYN_LINK and BOOST_FILESYSTEM_STATIC_LINK call "C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\vcvars32.bat" >nul cl /Zm800 -nologo @"..\..\..\bin.v2\libs\serialization\test\test_dll_exported.test\msvc-7.1\debug\link-static\threading-multi\test_dll_exported.obj.rsp" Which I've traced to the command line "test_dll_exported.cpp" -Fo"..\..\..\bin.v2\libs\serialization\test\test_dll_exported.test\msvc-7.1\debug\link-static\threading-multi\test_dll_exported.obj" -TP /Z7 /Od /Ob0 /W4 /GR /MDd /Zc:forScope /Zc:wchar_t /Wp64 /GB /Op /wd4675 /EHs -Gy -wd4996 -c -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS "-I..\..\.." which is produced by BJAM. The test application creates a DLL which is part of the test. BUT the dll created, as well as the serialization library used have been created with static linking. I'm assuming that the file system library is also created this way. I "think" this should be OK even though some C++ runtime code will be repeated between the DLL and the mainline test components and that this might create a problem so it's probably not the best practice. Never the less, users do this and I want to test it. I believe that the problem resides in some thing in the BJAM files related to filesystem libraries or test but I've been unable to track it down further than the above. Any help would be appreciated. Robert Ramey

3 3

[rational] with optional over/underflow checking
by Dan Searles 04 Aug '12

04 Aug '12

Hello, Would there be any interest in a modified "rational" class template/header that optionally allows for an exception be generated if there is under/overflow during any of the operations? I have been developing such a template, where the new defaulted bool template parameter would generate the class exactly as before to preserve the original stable implementation, and to support unlimited-precision integer where over/underflow would not be possible. Setting the new template parameter to true, however would generate code that adds the over/underflow checking. I have also generated new test driver code (BTW test code referenced by the documentation does not appear to exist, or at least the link is broken). rational.hpp has been around and stable for quite some time, so there may be a desire to keep it unchanged, but its original function (and indeed its original source code) can be maintained through the template system. If such a class were to be included in boost, what would be the best submission method?

3 4

Boost.Atomic on Windows, patch
by Václav Zeman 04 Aug '12

04 Aug '12

Hi. I have noticed that boost/atomic/detail/generic-cas.hpp is directly including Windows.h header. I consider this problematic for WinSock using applications as Windows.h automatically pulls in Winsock.h, the WinSock 1 header. This is problematic because it requires users that want to use WinSock 2 to order their include of WinSock2.h before inclusion of Boost.Atomic. At this point in time anybody serious about sockets on Windows really do not want to use WinSock 1 but version 2 instead. So I suggest the attached patch. -- VZ

4 6

[iterator] Error in documentation
by Gabriel Redner 04 Aug '12

04 Aug '12

In the boost::iterator documentation [1], the synopsis for make_function_input_iterator is missing the second 'state' argument. Specifically, this: template <class Function, class State> typename function_input_iterator<Function, State> make_function_input_iterator(Function & f); should be replaced by: template <class Function, class State> typename function_input_iterator<Function, State> make_function_input_iterator(Function & f, State state); Thanks, -Gabe [1] http://www.boost.org/doc/libs/1_50_0/libs/iterator/doc/function_input_itera…

2 2