- Boost - lists.boost.org

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