- Boost - lists.boost.org

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

[type_erasure] Review ends today Aug 3, 2012
by Lorenzo Caminiti 03 Aug '12

03 Aug '12

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

1.51.0] Beta 1 release candidate 2 available
by Marshall Clow 03 Aug '12

03 Aug '12

Release candidate files for 1.51.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: e3a51b82894a67ac438eaa08192929eb *boost_1_51_0_beta1_rc2.tar.gz 1c541236f98dcaa706e7f8eabb11ebfc *boost_1_51_0_beta1_rc2.tar.bz2 964f150ce9d7bcaba74255aba73d338a *boost_1_51_0_beta1_rc2.zip e23467c3369a53189300c76e8c848aa1 *boost_1_51_0_beta1_rc2.7z Thanks to everyone who tried out rc1, and especially Neal Becker, who helped me track down a permissions error in the build process --The release managers

3 4

[forward_declare] Interest Inquiry toward Faster Compile Times
by Daniel Larimer 02 Aug '12

02 Aug '12

I have been increasingly frustrated with how long it takes to compile c++ code. After spending some time in Java and C# I can feel the pain of compile times much sharper than I use to. After seeing that Java and C# were able to achieve some level of generics without requiring 'everything in the header' and knowing that C compiles an order of magnitude faster than c++ I set about to find a way to increase my compile times. One of the common recommendations is to 'forward declare' everything and to use the PIMPL (private implementation pattern). Unfortunately, PIMPL usually implies heap allocation and if you ever want to return-by-value you are stuck including the entire header for the types you use in your header. I started inspecting some of my code and running it through the pre-processor and noticed that almost every source file was in the 50K+ lines of code post-preprocessor and that some files were north of 250K lines of code. This was ridiculously inefficient, especially because I was already using PIMPL everywhere I could and most of these lines were stl + boost. After a little bit of work I was able to abstract vector, boost::exception, iostream, string, threading, and many of the other types that I had been including that resulted in 'code-bloat'. The resultant library was able to reduce my post-preprocessor output to just one or two thousand lines of code (assuming the .cpp itself was 500+ lines). My compile times dropped to sub-second per object file from 10+ seconds (some up to 40 seconds). There are some side effects from doing this, performance in some cases was slightly slower due to one level of indirection, but with with link-time optimization this performance loss was minimized. And any loss of performance was clearly acceptable trade for the gain in development efficiency. In situations were performance really is critical I can choose to include the raw header in individual cpp files, but in most cases that level of 'optimization' is overkill. One of the things I realized doing this work was that often the only reason you need to include a header is because the compiler needs to know the SIZE of the type that you wish to forward declare and nothing else. So our development is slowed entirely due to the lack of a SINGLE NUMBER. So I created a utility that allowed me to 'forward declare' the size of the variable. This allowed me to use return by value and member variables via forward declaration WITHOUT having to resort to heap allocation. It occurred to me that a library that allowed developers to choose a little drop in runtime performance for a dramatic improvement in compile times would be generally useful to the C++ community. I have included an example of the 'technique' and general purpose utility that would allow others to quickly and easily integrate forward declaration of 'value types'. A full up boost submission would probably include pre-wrapped versions of most of the STL and Boost types.

9 24