- Boost - lists.preview.boost.org

[release] scope_exit, local_function, utility/identity_type, and functional/overloaded_function
by lcaminiti 02 May '12

02 May '12

Hello release managers, I've been working in the trunk on a few libraries which are almost ready to be released: a) When is the release date? b) What do I have to do to merge into release? (This will be my 1st release merge :) ). 1) ScopeExit (improved) I'm waiting on MVSC 9 and 10 tests to cycle to make sure they all pass. Other compilers OK. 2) Utility/IdentityType (new) Should be ready to be merged into release. 3) Functional/OverloadedFunction (new) Should be ready to be merged into release. 4) LocalFunction (new) I'm making final fixes for some tests on some of compilers. Hopefully, I'll be done in 2 weeks max. For all of those, I've followed the checklist so I've run the code inspection tool, updated all docs, librariers.htm, and maintainers.txt. Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-release-scope-exit-local-function-… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 9

Trac Default Version
by Olaf van der Spek 02 May '12

02 May '12

Hi, Why's the default version when submitting a ticket still 1.48? -- Olaf

2 1

[uuids] On boost::uuids::uuid operator == performance.
by Michael Kochetkov 02 May '12

02 May '12

Hello. I would like to discuss a performance issue with boost::uuids::uuid operator ==. Let us consider the following program: --------------------------------------------------- #include <boost/uuid/uuid.hpp> #include <boost/uuid/uuid_generators.hpp> int main() { boost::uuids::uuid id1((boost::uuids::random_generator()())), id2((boost::uuids::random_generator()())); return id1 == id2; // we will consider this line } --------------------------------------------------- That is compiled with maximum optimizations the following way with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86: cl -EHsc -Ox -GL -Ob2 -Oi -Fa -I..\3dparty\boost_1_48_0 m051.cpp boost uses the following comparison operator: inline bool operator==(uuid const& lhs, uuid const& rhs) /* throw() */ { return std::equal(lhs.begin(), lhs.end(), rhs.begin()); } which end up with the following code: lea edx, DWORD PTR _id2$[esp+92] lea ecx, DWORD PTR _id1$[esp+108] lea eax, DWORD PTR _id1$[esp+92] call ?_Equal@std@@YA_NPBE00@Z ; std::_Equal The whole story looks the following way (the code above plus std::_Equal call expansion): 0117C6AB lea edx,[esp+24h] 0117C6AF lea ecx,[esp+48h] 0117C6B3 lea eax,[esp+38h] 0117C6B7 call 01171000 01171000 push esi 01171001 mov esi,eax 01171003 sub ecx,esi 01171005 push edi 01171006 cmp ecx,4 01171009 jb 01171024 0117100B jmp 01171010 0117100D lea ecx,[ecx] 01171010 mov eax,dword ptr [esi] 01171012 cmp eax,dword ptr [edx] 01171014 jne 01171028 01171016 sub ecx,4 01171019 add edx,4 0117101C add esi,4 0117101F cmp ecx,4 01171022 jae 01171010 01171024 test ecx,ecx 01171026 je 01171073 01171028 movzx eax,byte ptr [esi] 0117102B movzx edi,byte ptr [edx] 0117102E sub eax,edi 01171030 jne 01171063 01171032 cmp ecx,1 01171035 jbe 01171073 01171037 movzx eax,byte ptr [esi+1] 0117103B movzx edi,byte ptr [edx+1] 0117103F sub eax,edi 01171041 jne 01171063 01171043 cmp ecx,2 01171046 jbe 01171073 01171048 movzx eax,byte ptr [esi+2] 0117104C movzx edi,byte ptr [edx+2] 01171050 sub eax,edi 01171052 jne 01171063 01171054 cmp ecx,3 01171057 jbe 01171073 01171059 movzx eax,byte ptr [esi+3] 0117105D movzx ecx,byte ptr [edx+3] 01171061 sub eax,ecx 01171063 sar eax,1Fh 01171066 or eax,1 01171069 xor edx,edx 0117106B test eax,eax 0117106D pop edi 0117106E sete al 01171071 pop esi 01171072 ret 01171073 xor eax,eax 01171075 xor edx,edx 01171077 test eax,eax 01171079 pop edi 0117107A sete al 0117107D pop esi 0117107E ret I do understand that the boost::uuids::uuid implementation is conceptually correct and inoculate the best programming practices. But the following equivalent is too much faster (you may probably want to ensure a proper alignment for some processor architectures or even get even faster 64-bit version): inline bool comp(const boost::uuids::uuid& l, const boost::uuids::uuid& r) { return *reinterpret_cast<const uint32_t*>(l.data) == *reinterpret_cast<const uint32_t*>(r.data) && *reinterpret_cast<const uint32_t*>(l.data+4) == *reinterpret_cast<const uint32_t*>(r.data+4) && *reinterpret_cast<const uint32_t*>(l.data+8) == *reinterpret_cast<const uint32_t*>(r.data+8) && *reinterpret_cast<const uint32_t*>(l.data+12) == *reinterpret_cast<const uint32_t*>(r.data+12); } the assembler output is: mov ecx, DWORD PTR _id1$[esp+92] cmp ecx, DWORD PTR _id2$[esp+92] jne SHORT $LN37@main mov edx, DWORD PTR _id1$[esp+96] cmp edx, DWORD PTR _id2$[esp+96] jne SHORT $LN37@main mov eax, DWORD PTR _id1$[esp+100] cmp eax, DWORD PTR _id2$[esp+100] jne SHORT $LN37@main mov ecx, DWORD PTR _id1$[esp+104] cmp ecx, DWORD PTR _id2$[esp+104] jne SHORT $LN37@main mov eax, 1 jmp SHORT $LN40@main $LN37@main: xor eax, eax $LN40@main: movzx eax, al that the question comes: is boost supposed to be used in commercial applications or it is just a testing area for some concepts? You have probably never thought of the fact that Debug (unoptimized configurations) are sometimes just unusable with such approach on real (big) data. If you are interested you may want to compile the program above this way and see the resulting code: cl -EHsc -Zi -Fa -I..\3dparty\boost_1_48_0 m051.cpp Thank you in advance for your considerations. -- Michael Kochetkov

7 27

[uuid] Unused variable warnings
by Andrey Semashev 02 May '12

02 May '12

Hi, With recent versions of boost I get lots of warnings like the following: /.../boost/uuid/seed_rng.hpp: In member function ‘void boost::uuids::detail::seed_rng::sha1_random_digest_()’: /.../boost/uuid/seed_rng.hpp:157:24: warning: variable ‘not_used’ set but not used [-Wunused-but-set-variable] I'm using GCC 4.6 with -Wall. It's trivial to mask this warning out by attaching __attribute__((unused)) to the variable, which I've done locally. Ok to commit?

2 2

Recommended way of dealing with windows.h in headers?
by Mathias Gaunard 02 May '12

02 May '12

What's the recommended way to deal with windows.h in Boost? I see a lot of libraries doing stuff like #if defined( BOOST_USE_WINDOWS_H ) # include <windows.h> #endif namespace boost { namespace detail { #if !defined( BOOST_USE_WINDOWS_H ) extern "C" void __stdcall Sleep( unsigned long ms ); #endif So should libraries just declare all symbols themselves? But here the declaration is wrong, it misses __declspec(dllimport) for example when the runtime CRT is used, unnecessarily requiring import libraries. WINBASEAPI/WINADVAPI macros could be used to fix that. There is also the file <boost/detail/win/basic_types.hpp> that contains a few of the types, but it doesn't seem to be used that much except by other files in detail/win, and then again they don't re-use WINAPI and other macros. It also seems to be lacking the WINBASEAPI/WINADVAPI macros. Also, why couldn't headers simply include <windef.h> then <winbase.h>? Does that cause problems too?

3 2

[Smart Ptr] make_shared slower than shared_ptr(new) on VC++9 (and 10) with fix
by Ivan Erceg 02 May '12

02 May '12

Hi all, Before I switch to using boost::make_shared<> I wanted to test its purported performance advantage. I created a simple benchmark for measuing raw allocation throughput for 3 classes of different sizes with a common base class (constructors and destructors trivial). The number of allocations was set to 40,000,000 as it was roughly giving me 10 seconds running time per test. Unfortunatelly it turns out that on VC++9 (release target with default optimizations) boost::make_shared is significantly slower than simply doing boost::shared_ptr(new). Here's the benchmark output: TestBoostMakeShared 10.577s 3.78179e+006 allocs/s TestBoostSharedPtrNew 8.907s 4.49085e+006 allocs/s As you can see boost::make_shared is over 15% slower than boost::shared_ptr(new) idiom. Having available VC++10 compiler as well I then compared these results with std::shared_ptr and std::make_shared implementations that come with that compiler (but not VC++9). Here are the results: TestBoostMakeShared 9.688s 4.12882e+006 allocs/s TestBoostSharedPtrNew 8.252s 4.84731e+006 allocs/s TestStdMakeShared 5.07s 7.88955e+006 allocs/s TestStdSharedPtrNew 8.159s 4.90256e+006 allocs/s While std::shared_ptr(new) performs about the same as boost::shared_ptr(new), std::make_shared really blows away boost::make_shared and both shared_ptr(new) tests, being almost twice as fast as boost::make_shared. I then profiled the boost::make_shared test to see what's the biggest performance bottleneck when compared to boost::shared_ptr(new) profiler run. The culprit was immediately obvious: boost::make_shared test was spending above 25% of its time in "type_info::operator==(class type_info const &) const" function. This function was being called indirectly from boost::make_shared through boost::get_deleter. After digging some more through the implementation I came to the conclusion that, in this particular case, we are guaranteed to always be requesting deleter for the right class (namely T from boost::make_shared<T>). Since boost::shared_ptr doesn't have a way to retrieve the deleter without using RTTI I decided to add one and use it from an alternative boost::make_shared. So I did the following: 1. I added a virtual function to detail::sp_counted_base (detail\sp_counted_base_w32.hpp): virtual void * get_raw_deleter( ) = 0; 2. I implemented get_raw_deleter() function in sp_counted_impl_p (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return 0; } 3. I implemented get_raw_deleter() function in sp_counted_impl_pd (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return &reinterpret_cast<char&>( del ); } 4. I implemented get_raw_deleter() function in sp_counted_impl_pda (detail\sp_counted_impl.hpp): virtual void * get_raw_deleter( ) { return &reinterpret_cast<char&>( d_ ); } 5. I added the following function to detail::shared_count: void * get_raw_deleter( ) const { return pi_? pi_->get_raw_deleter( ): 0; } 6. I added the following function to shared_ptr<>: void * _internal_get_raw_deleter( ) const { return pn.get_raw_deleter( ); } 7. I made a separate copy of boost::make_shared function and replaced a single line from: boost::detail::sp_ms_deleter< T > * pd = boost::get_deleter< boost::detail::sp_ms_deleter< T > >( pt ); to: boost::detail::sp_ms_deleter< T > * pd = static_cast<boost::detail::sp_ms_deleter< T > *>(pt._internal_get_raw_deleter()); Benchmarking the results afterwards gave me the following results on VC++9: TestBoostSharedPtrNew 9.204s 4.34594e+006 allocs/s TestBoostMakeShared 10.499s 3.80989e+006 allocs/s TestBoostMakeSharedAlt 7.831s 5.1079e+006 allocs/s My changes translated into almost 35% improvement in allocation speed over the current implementation of boost::make_shared. Or to put it differently, they amount to 25+% decrease in running time as we could have supposed from the profiling results. Results on VC++10 are similar: TestBoostSharedPtrNew 8.487s 4.71309e+006 allocs/s TestBoostMakeShared 9.609s 4.16276e+006 allocs/s TestStdSharedPtrNew 8.283s 4.82917e+006 allocs/s TestStdMakeShared 5.039s 7.93808e+006 allocs/s TestBoostMakeSharedAlt 6.802s 5.88062e+006 allocs/s VC++10's std::make_shared is still much faster (almost 35% faster than boost::shared_ptr) and we will be switching to it once we switch to VC++10. But in the meantime it seems to me that boost::make_shared should be fixed to improve the performance. Again, this is only one compiler and other compilers might not have such a severe RTTI performance issue but I still think it would be well worth avoiding unnecessary calls to RTTI during performance-relevant operations such as heap allocations. The testing and changes were done on Boost 1.48.0 but I compared Smart Ptr library sources with Boost 1.49.0 and the above changes should work there equally well. Thanks, Ivan

15 40

[ANN] ODB C++ ORM 2.0.0 released, adds support for C++11, polymorphism
by Boris Kolpackov 02 May '12

02 May '12

I am pleased to announce the release of ODB 2.0.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. ODB provides a Boost profile which allows you to seamlessly use value types (date_time), containers (optional, unordered), and smart pointers (shared_ptr, weak_ptr) from Boost in your persistent classes. Major new features in this release: * Support for C++11 which adds integration with the new C++11 standard library components, including smart pointers and containers. Now you can use std::unique_ptr and std::shared_ptr as object pointers (their lazy versions are also provided). For containers, support was added for std::array, std::forward_list, and the unordered containers. * Support for polymorphism which allows you to persist, load, update, erase, and query objects of derived classes using their base class interfaces. Persistent class hierarchies are mapped to the relational database model using the table-per-difference mapping. * Support for composite object ids which are translated to composite primary keys in the relational database. * Support for the NULL semantics for composite values. This release has also been tested with GCC 4.7 and Clang 3.0 with the ODB compiler now supporting the GCC 4.7 series plugin interface. A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2012/05/02/odb-2-0-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2012/000013.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64), Windows (x86/x86-64), Mac OS X, and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.7.x, MS Visual C++ 2008 and 2010, Sun Studio 12, and Clang 3.0. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris

1 0

Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
by Brian Wood 02 May '12

02 May '12

Paul Mensonides: > As some sort of technological preview? It is not portable enough to be > used within Boost, though perhaps a slew of regression failures will cause > that to change (unlikely). <rant>MS, in particular, is too busy taking it > upon themselves to "ensure C++ is relevant" to prioritize implementing the > language.</rant> Also, one of the principles of Chaos is to have > absolutely zero compiler workarounds, and that would have to stay if it > was ever part of Boost. Given your desire to avoid compiler workarounds, an on line code generator may be helpful. One of the happy results of going on line is kissing compiler workarounds good-bye. I've worked on the distribution of code generated by an on line code generator -- http://webEbenezer.net/build_integration.html . You're welcome to use that as a starting point if you like. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 4

Review request: extended complex number library
by Matthieu Schaller 02 May '12

02 May '12

Dear all, Following the comments from V. Escriba, I formally propose my complex number library for review. The library is an extension of the std::complex class addressing two issues: - The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. - Some calculation where pure imaginary numbers (i.e. multiples of sqrt(-1)) appear are unnecessarily slowed down due to the lack of support for these numbers. The code I submit contains two interleaved classes boost::complex and boost::imaginary which can be instantiated with any type T provided T overloads the usual arithmetic operators and some basic (real) mathematical functions depending on which complex function will be used. It is thus an extended version of Thorsten Ottosen's n1869 proposal (http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1869.html) Performance tests show some non-negligible speed-ups compared to std::complex for calculations where pure imaginary numbers are involved. A speed-up of 25% has been observed when solving the Schroedinger equation explicitly on a regular mesh and some comparable figures can be observed when computing the Mandelbrot set (the two examples snippets provided in the archive). Furthermore, the functions (sin(), exp(), log(),...) involving boost::imaginary numbers are more precise than their equivalent using a std::complex with the real part set to 0. The code and (doxygen) documentation is available in the repository http://code.google.com/p/cpp-imaginary-numbers/ A comprehensive zip archive can be found in the "download" and the code can also be checked-out via the SVN repository. The archive contains the class header, two examples, a comprehensive precision test, a brute-force performance test and the documentation. I'd be happy to answer any question from your side and to provide more detailed information if required. Regards, Matthieu -- Matthieu Schaller PhD student - Durham University

8 23

[assign] map_list_of with hash_map?
by Robert Dailey 01 May '12

01 May '12

Will map_list_of work with std::hash_map?

1 0

Array in Unordered Map
by Olaf van der Spek 01 May '12

01 May '12

Hi, What's the right way to get an array into an unordered map? This one works on VC10, but GCC appears to look for the hash_value function in namespace std. What's the right way to do this? Olaf #include <array> #include <boost/unordered_map.hpp> namespace boost { template<class T, size_t N> size_t hash_value(const std::array<T, N>& v) { return boost::hash_range(v.begin(), v.end()); } } int main() { boost::unordered_map<std::array<char, 20>, int> c; c[std::array<char, 20>()] = 0; return 0; } -- Olaf

3 6

Re: [boost] [Boost-commit] svn:boost r78273 - in trunk: boost/filesystem libs/filesystem/test libs/filesystem/test/msvc10 libs/filesystem/test/msvc10/macro_default_test
by Steven Watanabe 01 May '12

01 May '12

AMDG This broke the regression tests: error: Unable to find file or target named error: 'macro_default_test.cpp' error: referred from project at error: '../libs/filesystem/test' In Christ, Steven Watanabe On 04/30/2012 08:00 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2012-04-30 11:00:21 EDT (Mon, 30 Apr 2012) > New Revision: 78273 > URL: http://svn.boost.org/trac/boost/changeset/78273 > > Log: > Revert to BOOST_FILESYSTEM_STATIC_LINK as the default if no linkage macros supplied. See http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/boost_config/boos… > Add test to verify correct default. > Added: > trunk/libs/filesystem/test/msvc10/macro_default_test/ > trunk/libs/filesystem/test/msvc10/macro_default_test/macro_default_test.vcxproj (contents, props changed) > Text files modified: > trunk/boost/filesystem/config.hpp | 2 +- > trunk/libs/filesystem/test/Jamfile.v2 | 1 + > trunk/libs/filesystem/test/msvc10/filesystem-v3.sln | 10 ++++++++++ > 3 files changed, 12 insertions(+), 1 deletions(-) > > Modified: trunk/boost/filesystem/config.hpp > ============================================================================== > --- trunk/boost/filesystem/config.hpp (original) > +++ trunk/boost/filesystem/config.hpp 2012-04-30 11:00:21 EDT (Mon, 30 Apr 2012) > @@ -56,7 +56,7 @@ > > #if !defined(BOOST_FILESYSTEM_DYN_LINK) && !defined(BOOST_FILESYSTEM_STATIC_LINK) \ > && !defined(BOOST_ALL_DYN_LINK) && !defined(BOOST_ALL_STATIC_LINK) > -# define BOOST_FILESYSTEM_DYN_LINK > +# define BOOST_FILESYSTEM_STATIC_LINK > #endif > > #if defined(BOOST_ALL_DYN_LINK) && !defined(BOOST_FILESYSTEM_DYN_LINK) > > Modified: trunk/libs/filesystem/test/Jamfile.v2 > ============================================================================== > --- trunk/libs/filesystem/test/Jamfile.v2 (original) > +++ trunk/libs/filesystem/test/Jamfile.v2 2012-04-30 11:00:21 EDT (Mon, 30 Apr 2012) > @@ -17,6 +17,7 @@ > > test-suite "filesystem" : > [ run convenience_test.cpp ] > + [ compile macro_default_test.cpp ] > [ run deprecated_test.cpp ] > [ run fstream_test.cpp ] > [ run large_file_support_test.cpp ] > > Modified: trunk/libs/filesystem/test/msvc10/filesystem-v3.sln > ============================================================================== > --- trunk/libs/filesystem/test/msvc10/filesystem-v3.sln (original) > +++ trunk/libs/filesystem/test/msvc10/filesystem-v3.sln 2012-04-30 11:00:21 EDT (Mon, 30 Apr 2012) > @@ -106,6 +106,12 @@ > EndProject > Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "exec_monitor_lib", "exec_monitor_lib\exec_monitor_lib.vcxproj", "{272DFC15-6292-49DF-B457-6784A183EAC3}" > EndProject > +Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "macro_default_test", "macro_default_test\macro_default_test.vcxproj", "{36E2032D-F9E6-4FBA-9630-3D4AC518DC6C}" > + ProjectSection(ProjectDependencies) = postProject > + {3640605D-6F82-493D-879F-8F30762DA554} = {3640605D-6F82-493D-879F-8F30762DA554} > + {2C1770A4-4AC3-4102-9D36-E652DBB686D8} = {2C1770A4-4AC3-4102-9D36-E652DBB686D8} > + EndProjectSection > +EndProject > Global > GlobalSection(SolutionConfigurationPlatforms) = preSolution > Debug|Win32 = Debug|Win32 > @@ -228,6 +234,10 @@ > {272DFC15-6292-49DF-B457-6784A183EAC3}.Debug|Win32.Build.0 = Debug|Win32 > {272DFC15-6292-49DF-B457-6784A183EAC3}.Release|Win32.ActiveCfg = Release|Win32 > {272DFC15-6292-49DF-B457-6784A183EAC3}.Release|Win32.Build.0 = Release|Win32 > + {36E2032D-F9E6-4FBA-9630-3D4AC518DC6C}.Debug|Win32.ActiveCfg = Debug|Win32 > + {36E2032D-F9E6-4FBA-9630-3D4AC518DC6C}.Debug|Win32.Build.0 = Debug|Win32 > + {36E2032D-F9E6-4FBA-9630-3D4AC518DC6C}.Release|Win32.ActiveCfg = Release|Win32 > + {36E2032D-F9E6-4FBA-9630-3D4AC518DC6C}.Release|Win32.Build.0 = Release|Win32 > EndGlobalSection > GlobalSection(SolutionProperties) = preSolution > HideSolutionNode = FALSE > > Added: trunk/libs/filesystem/test/msvc10/macro_default_test/macro_default_test.vcxproj > ============================================================================== > --- (empty file) > +++ trunk/libs/filesystem/test/msvc10/macro_default_test/macro_default_test.vcxproj 2012-04-30 11:00:21 EDT (Mon, 30 Apr 2012) > @@ -0,0 +1,91 @@ > +<?xml version="1.0" encoding="utf-8"?> > +<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> > + <ItemGroup Label="ProjectConfigurations"> > + <ProjectConfiguration Include="Debug|Win32"> > + <Configuration>Debug</Configuration> > + <Platform>Win32</Platform> > + </ProjectConfiguration> > + <ProjectConfiguration Include="Release|Win32"> > + <Configuration>Release</Configuration> > + <Platform>Win32</Platform> > + </ProjectConfiguration> > + </ItemGroup> > + <PropertyGroup Label="Globals"> > + <ProjectGuid>{36E2032D-F9E6-4FBA-9630-3D4AC518DC6C}</ProjectGuid> > + <Keyword>Win32Proj</Keyword> > + <RootNamespace>macro_default_test</RootNamespace> > + </PropertyGroup> > + <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" /> > + <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration"> > + <ConfigurationType>Application</ConfigurationType> > + <UseDebugLibraries>true</UseDebugLibraries> > + <CharacterSet>Unicode</CharacterSet> > + </PropertyGroup> > + <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'" Label="Configuration"> > + <ConfigurationType>Application</ConfigurationType> > + <UseDebugLibraries>false</UseDebugLibraries> > + <WholeProgramOptimization>true</WholeProgramOptimization> > + <CharacterSet>Unicode</CharacterSet> > + </PropertyGroup> > + <Import Project="$(VCTargetsPath)\Microsoft.Cpp.props" /> > + <ImportGroup Label="ExtensionSettings"> > + </ImportGroup> > + <ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"> > + <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > + </ImportGroup> > + <ImportGroup Label="PropertySheets" Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"> > + <Import Project="$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props" Condition="exists('$(UserRootDir)\Microsoft.Cpp.$(Platform).user.props')" Label="LocalAppDataPlatform" /> > + </ImportGroup> > + <PropertyGroup Label="UserMacros" /> > + <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"> > + <LinkIncremental>true</LinkIncremental> > + </PropertyGroup> > + <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"> > + <LinkIncremental>false</LinkIncremental> > + </PropertyGroup> > + <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'"> > + <ClCompile> > + <PrecompiledHeader> > + </PrecompiledHeader> > + <WarningLevel>Level3</WarningLevel> > + <Optimization>Disabled</Optimization> > + <PreprocessorDefinitions>WIN32;_DEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions> > + <AdditionalIncludeDirectories>../../../../..</AdditionalIncludeDirectories> > + </ClCompile> > + <Link> > + <SubSystem>Console</SubSystem> > + <GenerateDebugInformation>true</GenerateDebugInformation> > + </Link> > + </ItemDefinitionGroup> > + <ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'"> > + <ClCompile> > + <WarningLevel>Level3</WarningLevel> > + <PrecompiledHeader> > + </PrecompiledHeader> > + <Optimization>MaxSpeed</Optimization> > + <FunctionLevelLinking>true</FunctionLevelLinking> > + <IntrinsicFunctions>true</IntrinsicFunctions> > + <PreprocessorDefinitions>WIN32;NDEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions> > + </ClCompile> > + <Link> > + <SubSystem>Console</SubSystem> > + <GenerateDebugInformation>true</GenerateDebugInformation> > + <EnableCOMDATFolding>true</EnableCOMDATFolding> > + <OptimizeReferences>true</OptimizeReferences> > + </Link> > + </ItemDefinitionGroup> > + <ItemGroup> > + <ClCompile Include="..\..\macro_default_test.cpp" /> > + </ItemGroup> > + <ItemGroup> > + <ProjectReference Include="..\filesystem_lib\filesystem_lib.vcxproj"> > + <Project>{2c1770a4-4ac3-4102-9d36-e652dbb686d8}</Project> > + </ProjectReference> > + <ProjectReference Include="..\system_lib\system_lib.vcxproj"> > + <Project>{3640605d-6f82-493d-879f-8f30762da554}</Project> > + </ProjectReference> > + </ItemGroup> > + <Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" /> > + <ImportGroup Label="ExtensionTargets"> > + </ImportGroup> > +</Project> > \ No newline at end of file > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit

2 1

Re: [boost] [exception] warning about non-virtual destructor - resolution?
by Hite, Christopher 30 Apr '12

30 Apr '12

This is annoying me too: boost_1_49_0/boost/checked_delete.hpp:34:5: warning: deleting object of polymorphic class type 'boost::error_info<boost::tag_original_exception_type, const std::type_info*>' which has non-virtual destructor might cause undefined behaviour [-Wdelete-non-virtual-dtor] A) easy solution /boost_1_49_0/boost/exception/detail/error_info_impl.hpp It's probably easiest to just make ~error_info_base() virtual. It doesn't cost much since there's already a virtual table. B) harder solution The other cooler C++11 alternative is declare error_info final. I tried it on gcc-4.7.0 and it works wonderfully. Since the compiler knows you can not derive a class from that type it knows a that deconstructor is complete. struct base{ virtual void foo(); }; struct derived final : base { }; //struct illegal : derived {}; // error: cannot derive from 'final' base 'derived' in derived type 'illegal' void kill(derived* d){ delete d; // no complaint } I vote for A, because you'd anyway have to detect support for final. Chris

12 48

Re: [boost] [type_traits] has_equal_to< std::vector<T> > always true_
by Frédéric Bron 30 Apr '12

30 Apr '12

> We could use <boost/detail/container_fwd.hpp> here (rather like Boost.Hash > does, which has a similar issue) and get the best of both worlds? My > concern about making it a separate header, is that it runs the risk of ADL > errors if the #includes are inconsistent across translation units. I assume > that only forward declarations are needed for the containers? This looks a very good idea. It is a pity that the standard does not provide such header as it does for iostreams (iosfwd). However, I see that <boost/detail/container_fwd.hpp> has some troubles with many compilers, in particular with g++. // GNU libstdc++ 3 // Disable forwarding for all recent versions, as the library has a // versioned namespace mode, and I don't know how to detect it. This is a major drawback but maybe we can do something for it. I see also that with the new standard, this header is now not exhaustive; we have to include all of these: * <array> - <deque> * <forward_list> - <list> - <vector> - <map> - <set> * <unordered_map> * <unordered_set> - <queue> - <stack> - <string> - <bitset> *: missing headers in <boost/detail/container_fwd.hpp> Frédéric

2 1

Exception visibility and non-GCC compilers
by Mathias Gaunard 30 Apr '12

30 Apr '12

Exceptions types need to be exported so that shared libraries work correctly. Currently, the only code I see that does this is in Boost.Exception : #if defined(__GNUC__) # if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4) # pragma GCC visibility push (default) # endif #endif ... some exception type being declared or defined #if defined(__GNUC__) # if (__GNUC__ == 4 && __GNUC_MINOR__ >= 1) || (__GNUC__ > 4) # pragma GCC visibility pop # endif #endif But shouldn't we have macros to make this work with other compilers too? I'm not sure all unix-like compilers pretend to be GCC 4.1+.

2 3

[pool] Definition of a static_pool ?
by DUPUIS Etienne 30 Apr '12

30 Apr '12

Greetings, The Boost.Pool class describes a pool of buffer, pool whose size grows as needed. This is very convenient but there usage cases where the pool should not perform any dynamic memory allocation, i.e. the maximum number of simultaneously required buffers is known at initialization. I have hence defined a simple class 'static_pool' (see below), which (i) allocate all requested buffers at initialization; (ii) fails (returns null) if more buffers are being asked for at runtime. Does such a class has its place within the Boost Pool library ? Regards, Étienne #ifndef BOOST_STATIC_POOL_HPP #define BOOST_STATIC_POOL_HPP #include <boost/pool/pool.hpp> namespace boost { template<typename UserAllocator> class static_pool : protected pool<UserAllocator> { public : // Overridden functions explicit static_pool(const size_type nrequested_size) : pool<UserAllocator>(nrequested_size, nrequested_size) { free(malloc()); } void * malloc() { return store().empty() ? NULL : store().malloc(); } public : // Inherited functions void free(void * const chunk) { return pool<UserAllocator>::free(chunk); } size_type get_requested_size() const { return pool<UserAllocator>::get_requestedSize(); } bool is_from(void * const chunk) const { return pool<UserAllocator>::is_from(chunk); } }; } #endif Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Si vous avez reçu ce message par erreur, merci de nous en avertir immédiatement. ATEME décline toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié ou encore édité ou diffusé sans autorisation. This message and any attachments are confidential and intended solely for the addressees. Any unauthorized modification, edition, use or dissemination is prohibited. If you have received this message by mistake, please notify us immediately. ATEME decline all responsibility for this message if it has been altered, deformed, falsified or even edited or disseminated without authorization. Note: To protect against computer viruses, e-mail programs may prevent sending or receiving certain types of file attachments.

7 18

[filesystem] [system] Suddenly, dynamic linking by default
by Lars Viklund 30 Apr '12

30 Apr '12

Hello list. I have a habit of tracking trunk to find out if there's any strangeness or mistakes done on the platforms I target. A while ago I encountered some strange linking errors on some of my projects, which in the end turned out to be because for some reason, Boost.Filesystem and Boost.System now attempt to be dynamically linked by default, both symbol-decoration-wise and auto-link filename-wise. I happened to have some older shared libraries from an older trunk version lying around, so they were suddenly and unexpectedly picked up instead of my fresh static libraries. Even without my library hygiene deficiencies, the decision (which I have yet to see a rationale or announcement about) will cause a lot of problems. Why is it that System/Filesystem suddenly default to dynamic linking? Are there problems about linking statically? Why are there then static libraries built at all? Is this just some personal preference of the author that goes contrary to the general approach of Boost? Such choices have _massive_ impacts on consumers of the code, they should not be made lightly and if there is a really concrete need to do so, why is it not documented and thoroughly explained? Linking dynamically requires you to deploy the Boost DLLs to the end user, which prevents any plugin-like deployment, as they tend to require a single self-contained shared library with no dependencies, which implies linking to a static language runtime of choice. Dynamic linking of Boost means that you need to share a CRT between the project and Boost, which implies that the only CRT choice is the dynamic one, which prevents many deployment scenarios, as you have to deploy _that_ as well to the end user, either as a redistributable install or as a private deployment. This also has an impact on code size, as there is no dead-code elimination possible when the code resides in a DLL, you have to ship _all_ of the library even if you use a few convenience functions. For one of my projects (an extension to a popular music player), this would inflate its size many times for each and every download, as the software is deployed as a single ZIP archive through automatic update services. Additionally, the autolink macros to force symbol decoration and linking for a static link are undocumented in the Boost.Config table [1], which explicitly states that all libraries that can be statically linked will be statically linked. There is no mention of libraries that arbitrarily decide to go dynamic, just that some libraries are only available in dynamic form. For future reference for anyone finding this in archives, the undocumented, and in this case required, macros to force a static link and symbol decoration are: BOOST_<WHATEVER>_STATIC_LINK or BOOST_ALL_STATIC_LINK [1] http://www.boost.org/doc/libs/1_49_0/libs/config/doc/html/index.html#boost_… -- Lars Viklund | zao(a)acc.umu.se

5 6

[iostream] tests broken due to dependency on removed filesystem internals
by Jürgen Hunold 30 Apr '12

30 Apr '12

Hi, almost all Boost.Iostreams test fail with: bin.v2/libs/iostreams/test/array_test.test/gcc-4.6/debug/array_test.o In file included from ../array_test.cpp:14:0: ../detail/temp_file.hpp:16:46: fatal error: boost/filesystem/v3/operations.hpp: No such file or directory compilation terminated. The v3/ was removed recently as v2 was finally dropped. Patch to fix this attached. This gets a lot of the tests running. Okay to commit? There are some remaining failures. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu !

3 4

[multiprecision] Looking for a review manager
by John Maddock 29 Apr '12

29 Apr '12

Just a quick line to remind/hassle you all that I'm still looking for a review manager for the multiprecision library: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… All volunteers/victims gratefully accepted ;-) Many thanks in advance, John.

1 0

Re: [boost] Slow Bugs Tracker
by Olaf van der Spek 29 Apr '12

29 Apr '12

Hi, A few months ago there seemed to be plans to improve Trac. What's the status of those plans? Trac is still slow as hell. http://lists.boost.org/Archives/boost/2011/12/188639.php http://lists.boost.org/Archives/boost/2011/12/188937.php -- Olaf

7 44

[utility] convention inconsistencies
by lcaminiti 29 Apr '12

29 Apr '12

Hello all, I'm adding IdentityType to Boost.Utility and I have a couple of question about conventions: 1) Is there a reason why utility.hpp does not include all headers in boost/utility/? 2) Is there a reason why in the Documentation the utility sub-libraries are not named Boost.Utility/EnableIf bust just Boost.EnableIf? http://www.boost.org/doc/libs/1_49_0/ In boost/utility/ directory: addressof.hpp base_from_member.hpp binary.hpp compare_pointees.hpp declval.hpp enable_if.hpp identity_type.hpp in_place_factory.hpp result_of.hpp swap.hpp typed_in_place_factory.hpp value_init.hpp But boost/utility.hpp includes only some of those: #ifndef BOOST_UTILITY_HPP #define BOOST_UTILITY_HPP #include <boost/utility/addressof.hpp> #include <boost/utility/base_from_member.hpp> #include <boost/utility/binary.hpp> #include <boost/utility/enable_if.hpp> #include <boost/checked_delete.hpp> #include <boost/next_prior.hpp> #include <boost/noncopyable.hpp> #endif // BOOST_UTILITY_HPP Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-utility-convention-inconsistencies… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[function] The cost of boost::function
by Michael Kochetkov 28 Apr '12

28 Apr '12

Hello, as far as I subscribed to boost mail list for a reason I have decided to share an interesting (at least for me) observation of boost::function facility I have encountered several years ago. The observation is about the cost of the solution and you probably may be interested if you use boost in your production. Let us consider the following code: #include <boost/bind.hpp> #include <boost/function.hpp> inline int g(int i) { return ++i; } int main() { // AAAAA boost::function< int (int) > f1 = boost::bind(&g, _1 ); f1(1); // BBBB boost::_bi::bind_t<int,int (*)(int),boost::_bi::list1<boost::arg<1> > > f2 = boost::bind(&g, _1 ); f2(1); // CCCC auto f3 = boost::bind(&g, _1 ); f3(1); } I have compiled it with Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 the following way (maximal optimization): cl -EHsc -Ox -GL -Ob2 -Oi -Fa -IE:\Work\3dparty\boost_1_48_0 m054.cpp The resulting code for AAAA is: ; Line 10 mov eax, OFFSET ?g@@YAHH@Z ; g mov DWORD PTR $T109940[esp+60], eax mov eax, DWORD PTR $T109845[esp+64] lea ecx, DWORD PTR $T109940[esp+60] push ecx mov DWORD PTR $T109940[esp+68], eax call ?has_empty_target@function@detail@boost@@YA_NZZ ; boost::detail::function::has_empty_target add esp, 4 test al, al jne SHORT $LN20@main mov edx, DWORD PTR $T109940[esp+60] mov eax, DWORD PTR $T109940[esp+64] mov ecx, OFFSET ?stored_vtable@?1???$assign_to@V?$bind_t@HP6AHH@ZV?$list1@U?$arg@$00@boost@@ @_bi@boost@@@_bi@boost@@@?$function1@HH@boost@@AAEXV?$bind_t@HP6AHH@ZV?$list 1@U?$arg@$00@boost@@@_bi@boost@@@_bi@2@@Z@4U?$basic_vtable1@HH@function@deta il@2@B ; `boost::function1<int,int>::assign_to<boost::_bi::bind_t<int,int (__cdecl*)(int),boost::_bi::list1<boost::arg<1> > > >'::`2'::stored_vtable or ecx, 1 mov DWORD PTR _f1$[esp+68], edx mov DWORD PTR _f1$[esp+72], eax mov DWORD PTR _f1$[esp+60], ecx jmp SHORT $LN18@main $LN20@main: mov DWORD PTR _f1$[esp+60], 0 $LN18@main: ; Line 11 lea ecx, DWORD PTR _f1$[esp+60] mov DWORD PTR __$EHRec$[esp+68], 0 call ??R?$function1@HH@boost@@QBEHH@Z ; boost::function1<int,int>::operator() The resulting code for BBBB is: ; Line 15 push 1 call ?g@@YAHH@Z ; g add esp, 4 The resulting code for CCCC is: ; Line 19 push 1 call ?g@@YAHH@Z ; g add esp, 4 I have learned that personally I shall never use boost::function. You probably may want to investigate such a code bloat. Though it is probably the known and expected behavior. And I do agree that CCCC is not quite relevant here. Just for information. -- Michael Kochetkov P.S. The traditional full story for AAAA, that includes intermediate calls. Though it is not really full -- I have given up for three more calls inside the boost::function1<int,int>::operator() function. ; // AAAAA ; boost::function< int (int) > f1 = boost::bind(&g, _1 ); ; f1(1); 002661B9 mov eax,261170h 002661BE mov dword ptr [esp+4],eax 002661C2 mov eax,dword ptr [esp+8] 002661C6 lea ecx,[esp+4] 002661CA push ecx 002661CB mov dword ptr [esp+0Ch],eax 002661CF call 00261160 002661D4 add esp,4 002661D7 test al,al 002661D9 jne 002661F9 002661DB mov edx,dword ptr [esp+4] 002661DF mov eax,dword ptr [esp+8] 002661E3 mov ecx,26A028h 002661E8 or ecx,1 002661EB mov dword ptr [esp+14h],edx 002661EF mov dword ptr [esp+18h],eax 002661F3 mov dword ptr [esp+0Ch],ecx 002661F7 jmp 00266201 002661F9 mov dword ptr [esp+0Ch],0 00266201 lea ecx,[esp+0Ch] 00266205 mov dword ptr [esp+38h],0 0026620D call 002611D0 ; ?has_empty_target@function@detail@boost@@YA_NZZ ; boost::detail::function::has_empty_target 00DD1160 xor al,al 00DD1162 ret ; ??R?$function1@HH@boost@@QBEHH@Z ; boost::function1<int,int>::operator() 00DD11D0 push 0FFFFFFFFh 00DD11D2 push 0DD7810h 00DD11D7 mov eax,dword ptr fs:[00000000h] 00DD11DD push eax 00DD11DE sub esp,58h 00DD11E1 push esi 00DD11E2 mov eax,dword ptr ds:[00DDB038h] 00DD11E7 xor eax,esp 00DD11E9 push eax 00DD11EA lea eax,[esp+60h] 00DD11EE mov dword ptr fs:[00000000h],eax 00DD11F4 mov eax,dword ptr [ecx] 00DD11F6 test eax,eax 00DD11F8 jne 00DD1248 00DD11FA lea eax,[esp+0Ch] 00DD11FE push eax 00DD11FF lea ecx,[esp+14h] 00DD1203 mov dword ptr [esp+10h],0DDA008h 00DD120B call 00DD187F 00DD1210 mov dword ptr [esp+10h],0DDA058h 00DD1218 lea eax,[esp+10h] 00DD121C lea esi,[esp+1Ch] 00DD1220 mov dword ptr [esp+68h],0 00DD1228 call 00DD1600 00DD122D lea esi,[esp+3Ch] 00DD1231 mov byte ptr [esp+68h],1 00DD1236 call 00DD1640 00DD123B push 0DDA7A8h 00DD1240 mov ecx,esi 00DD1242 push ecx 00DD1243 call 00DD23CA 00DD1248 and eax,0FFFFFFFEh 00DD124B mov edx,dword ptr [eax+4] 00DD124E add ecx,8 00DD1251 push 1 00DD1253 push ecx 00DD1254 call edx 00DD1256 add esp,8 00DD1259 mov ecx,dword ptr [esp+60h] 00DD125D mov dword ptr fs:[0],ecx 00DD1264 pop ecx 00DD1265 pop esi 00DD1266 add esp,64h 00DD1269 ret

6 8

[1.50] Is there a schedule?
by John Maddock 27 Apr '12

27 Apr '12

OK, so it's too soon at present anyway, but should there be some sort of schedule on the calendar so we all know where we are? Cheers, John.

2 1

Boost.Variant known_get
by David Sankel 27 Apr '12

27 Apr '12

I noticed the detail::known_get function in boost variant. Is there any reason this function, which would be useful in high performance scenarios, is not exposed as part of the rest of the interface? David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

1 0

Boost.units autoscaling doesn't seem to work with the measurement type.
by Paul A. Bristow 27 Apr '12

27 Apr '12

I have previously used Boost.Units and autoscaled using << engineering_prefix nicely, and this works as expected for quantity of type double. but it seems that code that I believe worked previously does not autoscale when using a *user-defined type*, like the measurement example in kitchen_sink.cpp. To confirm this, I have added after //[kitchen_sink_snippet_8 in kitchen_sink.cpp at line 445 a measurement quantity where the length is long enough to trigger conversion to km, thus quantity<length,measurement<double> > biglen(measurement<double>(12345.0,123.0)*meters); std::cout << "Biglen autoscaled "<< engineering_prefix << biglen << std::endl; but I get a *unscaled* value :-( Biglen autoscaled 12345(+/-123) m rather than the expected conversion to kilometers 12.345(+/- 0.123) km Am I doing something wrong, or has something changed? Thanks Paul PS Using Microsoft Visual Studio 2010 Version 10.0.40219.1 SP1Rel Microsoft .NET Framework Version 4.0.30319 SP1Rel Boost-trunk (Boost.1.49) --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

1 1