- Boost - lists.boost.org

[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

bjam bug? Strange permission
by Neal Becker 02 Aug '12

02 Aug '12

While tracking down strange directory permissions, I noticed this: find . -name .hg -prune -o -type d \( \! -perm 755 -and \! -perm 775 \) -ls 17315044 4 drwxrw-r-- 3 nbecker nbecker 4096 Aug 2 08:41 ./bin.v2 I assume that dir was created by bjam during the test build, for some reason with strange mode.

3 4

Announce: Boost 1.50 installer for 32-bit Windows now available
by John Wiegley 01 Aug '12

01 Aug '12

With apologies to the community for not finding the time to release Windows installers for 1.48 and 1.49, we now have an installer for 1.50 available for immediate download: http://www.boostpro.com/download The version installs 32-bit libraries and/or DLLs for the following compilers: Visual C++ 8.0 (Visual Studio 2005) Visual C++ 9.0 (Visual Studio 2008) Visual C++ 10.0 (Visual Studio 2010) We are dropping support for Visual C++ 7.1 as of this time, unless someone wishes to contract us to bring it back. Also, although I have prepared a 64-bit installer, I have not yet found a solution for integrating it with the existing installer. If anyone with NSIS scripting experience would be willing to assist me, we'd be happy to provide a free installer which installs both 32-bit and 64-bit Boost libraries for applicable Windows platforms. Enjoy! -- John Wiegley BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 4

Re: [boost] [Boost-commit] svn:boost r79832 - trunk/tools/build/v2
by Vladimir Prus 01 Aug '12

01 Aug '12

On 01.08.2012 19:26, jurko.gospodnetic(a)docte.hr wrote: > Author: jurko > Date: 2012-08-01 11:26:26 EDT (Wed, 01 Aug 2012) > New Revision: 79832 > URL: http://svn.boost.org/trac/boost/changeset/79832 > > Log: > Boost Build cleanup - minor stylistic comment changes + better commented the project-config.jam configuration file usage. Jurko, are these reformatting changes really necessary? It sounds like it will just make it harder to update Python port when we get back to it when semester starts in September. Thanks,

1 1