- Boost - lists.preview.boost.org

Running the regression tests
by Sergey Cheban 12 Jul '12

12 Jul '12

On 09.07.2012 10:26, Tim Blechmann wrote: > .... there are still some test failures on win32, but i think i found > the reason and fixed the tests (btw it is rather time consuming to > work with the test farm as the win32 tests are only run about once a > week). I'm trying to setup the regression tests on our build server and I have some problems with specifying the toolset(s). The command line is: C:\Python27\python.exe run.py --runner=MSVC9_x64_DoctorWeb --toolsets=msvc-9.0 --bjam-options=architecture=x86 --bjam-options=address-model=64 --tag=branches/release --force-update --bjam-options="-j 10" In the bjam.log, I see: warning: No toolsets are configured. warning: Configuring default toolset "msvc". warning: If the default is wrong, your build may not work correctly. warning: Use the "toolset=xxxxx" option to override our guess. warning: For more configuration options, please consult warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.html notice: [msvc-cfg] msvc-10.0 detected, command: 'C:\program files (x86)\microsoft visual studio 10.0\VC\bin\cl.exe' notice: [msvc-cfg] msvc-9.0 detected, command: 'C:\program files (x86)\microsoft visual studio 9.0\VC\bin\cl.exe' notice: will use 'C:\program files (x86)\microsoft visual studio 10.0\VC\bin\cl.exe' for msvc, condition <toolset>msvc-10.0 notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>/<address-model>', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>/<address-model>32', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>x86/<address-model>', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>x86/<address-model>32', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>/<address-model>64', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_amd64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>x86/<address-model>64', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_amd64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>ia64/<address-model>', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_ia64 >nul ' notice: [msvc-cfg] condition: '<toolset>msvc-10.0/<architecture>ia64/<address-model>64', setup: 'call "C:\program files (x86)\microsoft visual studio 10.0\VC\vcvarsall.bat" x86_ia64 >nul ' C:/Users/BoostTest/Release/tools_bb/build\feature.jam:308: in implied-subfeature from module feature error: "9.0" is not a known subfeature value of <toolset>msvc C:/Users/BoostTest/Release/tools_bb/build\feature.jam:491: in validate-value-string from module feature C:/Users/BoostTest/Release/tools_bb/build\feature.jam:358: in expand-subfeatures-aux from module feature C:/Users/BoostTest/Release/tools_bb/build\feature.jam:419: in feature.expand-subfeatures from module feature C:/Users/BoostTest/Release/tools_bb/build\build-request.jam:20: in apply-to-property-set from module build-request C:/Users/BoostTest/Release/tools_bb/kernel\modules.jam:103: in modules.call-in from module build-request C:/Users/BoostTest/Release/tools_bb/util\sequence.jam:48: in sequence.transform from module sequence C:/Users/BoostTest/Release/tools_bb/build\build-request.jam:32: in build-request.expand-no-defaults from module build-request C:/Users/BoostTest/Release/tools_bb\build-system.jam:630: in load from module build-system C:\Users\BoostTest\Release\tools_bb/kernel\modules.jam:283: in import from module modules C:\Users\BoostTest\Release\tools_bb/kernel/bootstrap.jam:142: in boost-build from module C:\Users\BoostTest\Release\boost\boost-build.jam:17: in module scope from module What am I doing wrong? -- Sergey Cheban

3 3

[trac] Version defaults to 1.51
by Daniel James 12 Jul '12

12 Jul '12

Hi, When you create a new ticket, the version is set to 1.51 by default, which hasn't been released yet. It should be set to 1.50, can someone change it please? thanks, Daniel

1 0

[Algorithm] Incorrect behavior of is_sorted_until (predicate version)
by Michel Morin 12 Jul '12

12 Jul '12

Hi Marshall, Suppose we have an array int ar[5] = {1, 2, 2, 2, 2}; Then, `is_sorted_until(ar, ar + 5, std::less<int>())` should return `ar`'s end pointer. But it gives `ar + 2`. To fix this, change line 49 of is_sorted.hpp if ( !p ( *first, *next )) return next; to if ( p ( *next, *first )) return next; After fixing it, don't forget to change the predicate used in non-predicate version of is_sorted_until ;) Spotted by "clang-cxx11-r159746" test runner. Regards, Michel

2 1

[lockfree] include into 1.51?
by Tim Blechmann 11 Jul '12

11 Jul '12

hi all, especially release managers, boost.lockfree is now in trunk and it passes the tests on most supported platforms. atm it includes a private copy of boost.atomic, which will be removed once boost.atomic is merged (helge wanted to do it quite soon) ... there are still some test failures on win32, but i think i found the reason and fixed the tests (btw it is rather time consuming to work with the test farm as the win32 tests are only run about once a week). iac, the deadline for new libraries in 1.51 is today, but from my side, boost.lockfree could be included as it is now. however if the release managers consider it as too late, i'm don't have a problem with waiting for another release cycle ... thoughts? tim

5 29

Who runs the Cray test runner?
by Paul A. Bristow 11 Jul '12

11 Jul '12

I note that the Cray tests are all failing. Concerned that this is possibly (though I think not entirely from look of error messages) due to changes I have made to Boost.Test recently, I'd like to contact whoever manages the Sandia Cray test runner. Does anyone know who to contact? Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 2

[container] Forward declarations for scoped allocator traits
by Daniel James 11 Jul '12

11 Jul '12

Hi Ion, I was just looking at the scoped allocator support. A container currently needs to include all of scoped_allocator.hpp just to customize the appropriate traits which seems a bit much. Could you declare (not define) constructible_with_allocator_suffix and constructible_with_allocator_prefix in a separate header so that they can be specialised without including all the other things? I've also attached a patch that fixes a couple of typos that I noticed. Daniel

2 2

[config] Add BOOST_NO_RANGE_BASED_FOR macro?
by Beman Dawes 10 Jul '12

10 Jul '12

I'm about to add Boost.Filesystem support for C ++11 range-based for statements, and would like to include direct test cases for compilers that have the feature. Is it OK to add a BOOST_NO_RANGE_BASED_FOR macro to trunk? --Beman

7 19

[xpressive] Compiler error on VC7.1
by Robert Dailey 10 Jul '12

10 Jul '12

Hi, I'm using Boost 1.49 Xpressive on VC7.1. When I compile the following code, I get compiler errors (these do not appear on VC9): sregex const& rex = bos >> _serverName >> !as_xpr("_GWDomino") >> ".diagnostics" >> *(as_xpr(".base")|".renamed"); 'rex' is really a function parameter in my real world use case. I'm passing the entire static regex into a function that takes a 'sregex const&'. I get the compiler error below. Anyone know why this is happening? C:\Code\work\cmake-decomp\build-vc7\third_party\boost\1.49.0-stlport-5.2.1\include\boost\proto\traits.hpp(691) : error C2664: 'boost::proto::exprns_::expr<Tag,Args,Arity>::expr(const boost::proto::exprns_::expr<Tag,Args,Arity> &)' : cannot convert parameter 1 from 'boost::proto::detail::as_expr<T,Generator,WantsBasicExpr>::result_type' to 'const boost::proto::exprns_::expr<Tag,Args,Arity> &' with [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] and [ T=const char [10], Generator=boost::proto::detail::base_generator<boost::proto::default_generator>::type, WantsBasicExpr=false ] and [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] Reason: cannot convert from 'boost::proto::detail::as_expr<T,Generator,WantsBasicExpr>::result_type' to 'const boost::proto::exprns_::expr<Tag,Args,Arity>' with [ T=const char [10], Generator=boost::proto::detail::base_generator<boost::proto::default_generator>::type, WantsBasicExpr=false ] and [ Tag=boost::proto::tagns_::tag::terminal, Args=boost::proto::argsns_::term<boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::value_type>, Arity=0 ] No constructor could take the source type, or constructor overload resolution was ambiguous \Code\work\cmake-decomp\server\exchange\tools\uploadlog\uploader.cpp(1372) : see reference to function template instantiation 'const boost::add_const<T>::type boost::proto::functional::as_expr<>::operator ()<char,10>(const char (&)[10]) const' being compiled with [ T=boost::proto::detail::as_expr<const char [10],boost::proto::detail::base_generator<boost::proto::default_generator>::type,false>::result_type ]

3 18

[thread][chrono][system] fails to compile with -fno-exceptions
by Vicente J. Botet Escriba 10 Jul '12

10 Jul '12

Hi, I'm trying to make Boost.Thread work when -fno-exceptions is defined and I getting a lot of errors on Boost.System cd libs/system/build bjam toolset=darwin-4.7.0 -j4 cxxflags="-fno-exceptions" define=BOOST_NO_EXCEPTION darwin.compile.c++ ../../../bin.v2/libs/system/build/darwin-4.7.0/debug/error_code.o ../../../libs/system/src/error_code.cpp: In member function ‘virtual std::string {anonymous}::generic_error_category::message(int) const’: ../../../libs/system/src/error_code.cpp:149:10: error: expected ‘catch’ before ‘(’ token ../../../libs/system/src/error_code.cpp:149:12: error: expected type-specifier before ‘sz’ ../../../libs/system/src/error_code.cpp:149:12: error: exception handling disabled, use -fexceptions to enable ../../../libs/system/src/error_code.cpp:149:15: error: expected ‘)’ before ‘>’ token ../../../libs/system/src/error_code.cpp:149:15: error: expected ‘{’ before ‘>’ token ../../../libs/system/src/error_code.cpp:149:15: error: expected primary-expression before ‘>’ token ../../../libs/system/src/error_code.cpp:149:29: error: expected ‘;’ before ‘)’ token In file included from ../../../libs/system/src/error_code.cpp:19:0: ../../../boost/system/error_code.hpp: At global scope: ../../../boost/system/error_code.hpp:214:36: warning: ‘boost::system::posix_category’ defined but not used [-Wunused-variable] ../../../boost/system/error_code.hpp:215:36: warning: ‘boost::system::errno_ecat’ defined but not used [-Wunused-variable] ../../../boost/system/error_code.hpp:216:36: warning: ‘boost::system::native_ecat’ defined but not used [-Wunused-variable] "/usr/local/gcc-4-7-svn/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -gdwarf-2 -fexceptions -fPIC -fno-exceptions -DBOOST_ALL_NO_LIB=1 -DBOOST_NO_EXCEPTION -DBOOST_SYSTEM_DYN_LINK=1 -I"../../.." -c -o "../../../bin.v2/libs/system/build/darwin-4.7.0/debug/error_code.o" "../../../libs/system/src/error_code.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/system/build/darwin-4.7.0/debug/error_code.o... ...skipped <p../../../bin.v2/libs/system/build/darwin-4.7.0/debug>libboost_system.dylib for lack of <p../../../bin.v2/libs/system/build/darwin-4.7.0/debug>error_code.o... ...failed updating 1 target... After applying this patch the library builds Index: ../../../libs/system/src/error_code.cpp =================================================================== --- ../../../libs/system/src/error_code.cpp (revision 79245) +++ ../../../libs/system/src/error_code.cpp (working copy) @@ -133,7 +133,9 @@ } } std::string msg; +# ifndef BOOST_NO_EXCEPTIONS try +# endif { msg = ( ( result == invalid_argument ) ? "Unknown error" : bp ); } cd libs/chrono/build bjam toolset=darwin-4.7.0 -j4 cxxflags="-fno-exceptions" define=BOOST_NO_EXCEPTION darwin.compile.c++ ../../../bin.v2/libs/chrono/build/darwin-4.7.0/debug/threading-multi/process_cpu_clocks.o In file included from ../../../boost/chrono/detail/inlined/process_cpu_clocks.hpp:21:0, from ../../../libs/chrono/src/process_cpu_clocks.cpp:17: ../../../boost/system/system_error.hpp: In member function ‘virtual const char* boost::system::system_error::what() const’: ../../../boost/system/system_error.hpp:73:16: error: exception handling disabled, use -fexceptions to enable After applying this patch Index: ../../../boost/system/system_error.hpp =================================================================== --- ../../../boost/system/system_error.hpp (revision 79245) +++ ../../../boost/system/system_error.hpp (working copy) @@ -21,7 +21,7 @@ class BOOST_SYMBOL_VISIBLE system_error : public std::runtime_error // BOOST_SYMBOL_VISIBLE is needed by GCC to ensure system_error thrown from a shared - // library can be caught. See svn.boost.org/trac/boost/ticket/3697 + // library can be caught. See svn.boost.org/trac/boost/ticket/3697 { public: system_error( error_code ec ) @@ -61,13 +61,17 @@ { if ( m_what.empty() ) { +#ifndef BOOST_NO_EXCEPTIONS try +#endif { m_what = this->std::runtime_error::what(); if ( !m_what.empty() ) m_what += ": "; m_what += m_error_code.message(); } +#ifndef BOOST_NO_EXCEPTIONS catch (...) { return std::runtime_error::what(); } +#endif } return m_what.c_str(); } I get darwin.link.dll ../../../bin.v2/libs/chrono/build/darwin-4.7.0/debug/threading-multi/libboost_chrono.dylib Undefined symbols for architecture x86_64: "boost::throw_exception(std::exception const&)", referenced from: boost::chrono::chrono_detail::steady_full_ec(boost::system::error_code&) in chrono.o boost::chrono::steady_clock::now(boost::system::error_code&) in chrono.o boost::chrono::process_real_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o boost::chrono::process_user_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o boost::chrono::process_system_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o boost::chrono::process_cpu_clock::now(boost::system::error_code&) in process_cpu_clocks.o Does this mean that the user needs to link with a static library? Is there a way to provide a dynamic library for Boost.Chrono if it is up to the user to define boost::throw_exception? Is there a possibility that Boost.System support this mode? BTW, an alternative to redefine the the what function is to pass the string at the construction of the exception. Best, Vicente

1 1

date_time fixes.
by GAURAV GUPTA 10 Jul '12

10 Jul '12

Hi Marshall, I have raised 3 tickets 7111,7112,7113 for some issues in date_time. As the owner of date_time is not active and my earlier bug in date_time was verified by you. So Please verify and commit these bugs also. Thanks. -- Regards, Gaurav

1 0

Trac Errro
by Olaf van der Spek 10 Jul '12

10 Jul '12

Hi, https://svn.boost.org/trac/boost/browser/trunk/boost/algorithm/wrappers.hpp… says "No handler matched request to /browser/trunk/boost/algorithm/wrappers.hpp" https://svn.boost.org/trac/boost/changeset/79385 What went wrong? -- Olaf

3 5

[chrono] time_point.hpp depends on Boost.System; should it?
by Krzysztof Czainski 09 Jul '12

09 Jul '12

Hello, I want to create my own clock class, and in it among other things I would like to typedef a time_point<...>. struct MyClock { typedef int64_t rep; typedef boost::milli period; typedef boost::chrono::duration<rep,period> duration; typedef date_chrono::time_point<SystemClock,duration> time_point; static bool const is_monotonic = false; static time_point now(); }; Now, for this to work I obviously need to #include <boost/chrono/time_point.hpp>. Including it causes a dependency on Boost.System, making me have to link with it. But since I don't use any clocks provided by Boost.Chrono, I think the dependency on Boost.System is unnecessary. In fact, I was able to get rid of the dependency, and everything seems to work. I commented out 1 line from <boost/chrono/time_point.hpp>: //#include <boost/chrono/detail/system.hpp> Could this #include be removed from time_point.hpp, or is it needed for something I am not using ATM? Regards, Kris

2 5

[interprocess]
by Joseph Van Riper 09 Jul '12

09 Jul '12

I am either having some problems with the documentation, or I've stumbled into a bug in Boost.Interprocess's named_condition. I'm compiling on VC++ 2010, 32 or 64 bit, with the following test code: #include "stdafx.h" #include <boost/interprocess/sync/named_condition.hpp> #include <boost/interprocess/sync/named_mutex.hpp> int _tmain(int argc, _TCHAR* argv[]) { boost::interprocess::named_mutex mutex( boost::interprocess::open_or_create, "test" ); boost::interprocess::named_condition condition( boost::interprocess::open_or_create, "test" ); condition.wait( mutex ); return 0; } I get the following compiler errors: 1>------ Build started: Project: TestInterprocess, Configuration: Debug Win32 ------ 1>Build started 09-Jul-12 11:45:22 AM. 1>InitializeBuildStatus: 1> Touching "Debug\TestInterprocess.unsuccessfulbuild". 1>ClCompile: 1> All outputs are up-to-date. 1> TestInterprocess.cpp 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2248: 'boost::interprocess::interprocess_mutex::mutex' : cannot access private member declared in class 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(117) : see declaration of 'boost::interprocess::interprocess_mutex::mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\interprocess_mutex.hpp(67) : see declaration of 'boost::interprocess::interprocess_mutex' 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204) : while compiling class template member function 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex_type *boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>::mutex(void) const' 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(342) : see reference to class template instantiation 'boost::interprocess::ipcdetail::shm_named_condition::lock_wrapper<Lock>' being compiled 1> with 1> [ 1> Lock=boost::interprocess::named_mutex 1> ] 1> c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\named_condition.hpp(156) : see reference to function template instantiation 'void boost::interprocess::ipcdetail::shm_named_condition::wait<L>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1> c:\code\projects\testinterprocess\testinterprocess\testinterprocess.cpp(10) : see reference to function template instantiation 'void boost::interprocess::named_condition::wait<boost::interprocess::named_mutex>(L &)' being compiled 1> with 1> [ 1> L=boost::interprocess::named_mutex 1> ] 1>c:\code\sdks\boost\include\boost-1_50\boost\interprocess\sync\shm\named_condition.hpp(204): error C2064: term does not evaluate to a function taking 0 arguments 1> 1>Build FAILED. 1> 1>Time Elapsed 00:00:05.97 ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== I am lead to believe that I should used a named_mutex by the documentation here: http://www.boost.org/doc/libs/1_50_0/doc/html/boost/interprocess/named_cond… which states in the description that "This condition variable is designed to work with named_mutex and can't be placed in shared memory

1 0

[1.51][Release] Short release cycle
by Daniel James 08 Jul '12

08 Jul '12

Hello everyone, Just a quick warning that due to the delay releasing 1.50, the 1.51 release cycle is going to be a lot shorter than normal. It's a little under 2 months until the scheduled 1.51 release date. This means that the deadlines are pretty soon. If you haven't checked it yet, please take a look at the calendar at: http://www.boost.org/community/ The current deadline for new libraries and breaking changes is 9th July, which is less than two weeks. If you do have a new library that want to release in 1.51, you should probably let us know very soon. thanks, Daniel

21 54

[trunk] bootstrap failure
by Tim Blechmann 08 Jul '12

08 Jul '12

hi, just moved my boost source tree from one hd to another. trying to bootstrap leads to: Building Boost.Build engine with toolset gcc... Failed to build Boost.Build build engine Consult 'bootstrap.log' for more details the bootstrap.log contains: rm -rf bootstrap mkdir bootstrap gcc -o bootstrap/jam0 command.c compile.c constants.c debug.c execcmd.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathunix.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c function.c: In function ‘argument_list_print’: function.c:3126:17: warning: format ‘%s’ expects argument of type ‘char *’, but argument 2 has type ‘struct OBJECT *’ [-Wformat] ./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean Segmentation fault (core dumped) any idea? tim

2 2

[lockfree/win32] looking for help
by Tim Blechmann 08 Jul '12

08 Jul '12

hi all, i've been trying to sort out some compile problems of boost.lockfree, but now i find myself in a position that for some reasons, the tests on on the windows platform fail ... not only with msvc, but also with gcc/mingw. the main problem that i have is that two test cases compile, but fail at runtime ... unfortunately the error messages are not necessarily expressive: mingw: -- Run [2012-07-04 16:08:25 UTC]: fail EXIT STATUS: -1073741819 -- msvc: -- Running 8 test cases... unknown location(0): fatal error in "spsc_queue_test_buffering": stack overflow ..\libs\lockfree\test\spsc_queue_test.cpp(435): last checkpoint: "spsc_queue_test_buffering" entry. *** 1 failure detected in test suite "Master Test Suite" EXIT STATUS: 201 -- i am pretty clueless, what is happening there ... would it be possible that someone who has a win32 machine can send me a backtrace of this crash? thanks, tim

2 3

[Lockfree] examples with clang
by Rich E 08 Jul '12

08 Jul '12

Hi all, I've been attempting to test Lockfree (while at the same time learning to work with boost from trunk, so bare with me I'm a bit new) using Clang 4.0, the version that will ship with Xcode 4.5. It appears that the preprocessor check is only for gcc. If I change: #if __cplusplus < 201103L to #if __cplusplus < 201103L && ( defined( __clang__ ) && ! __has_include(<atomic>) ) and compile the examples with (from libs/lockfree/examples): ../../../bjam toolset=clang cxxflags="-std=c++0x -stdlib=libc++" linkflags="-stdlib=libc++" Then the examples work correctly (queue output: "produced 40000000 objects. consumed 40000000 objects."). I'm sure there is a more elegant way to check for libc++ existence when compiling with clang, possibly with boost/config.hpp? Also, I think a message in the dummy main would be nice to inform the user that lockfree won't work with their current setup / compile method. Cheers, Rich

2 1

[context] a couple of build fixes for Solaris (10)
by Luke Elliott 07 Jul '12

07 Jul '12

First is to get the definition of mprotect() that takes void * rather than char * by defining _XPG4_2, which causes a compilation failure with Solaris Studio 12.3. Second is a workaround for a bug in their csignal header which uses the same include guard that signal.h uses, which csignal includes (leaving SIGSTKSZ undefined). Attached if of any help. Regards Luke Elliott.

3 3

memory leak in fileiter.cpp
by GAURAV GUPTA 07 Jul '12

07 Jul '12

There is a possible memory leak in fileiter.cpp in Regex component. I have raised a ticket https://svn.boost.org/trac/boost/ticket/7084 along with the patch. Please verify and commit it. -- Regards, Gaurav

1 0

[gil::io_new] Help with gcc compiler
by Christian Henning 07 Jul '12

07 Jul '12

Hi there, I'm in the process of making my gil extension ready for inclusion. The code is now stable and I'm trying to get gcc/clang to work. Since I'm no expert with gcc I would like to ask for some help with various compiler errors. Could someone get the latest from here: http://gil-contributions.googlecode.com/svn/trunk/gil_2 and try to compile the following code: ------------------- #include <boost/gil/extension/io_new/bmp_all.hpp> using namespace std; using namespace boost::gil; int main() { { const char* bmp_filename = ""; const char* bmp_out = ""; rgb8_image_t img; read_image( bmp_filename, img, bmp_tag() ); write_view( bmp_out + "all_formats_test.bmp", view( img ), bmp_tag() ); } } ----------------- It should generate some errors which I don't quite understand. I have posted the errors here: http://pastebin.com/Wps3YH1N I'm using gcc 4.4.1 . The complete test suite compiles with Visual Studio 2010 without any warnings. Thanks a lot! Christian

5 10

noncopyable && C++11
by Ben Pope 06 Jul '12

06 Jul '12

Hi all, boost::noncopyable interferes with the implicit generation of move construction and move assignment, so I was wondering if anybody had any thoughts on something like this: class noncopyable { protected: noncopyable() = default; noncopyable(noncopyable&&) = default; noncopyable& operator=(noncopyable&&) = default; noncopyable(noncopyable const&) = delete; noncopyable& operator=(noncopyable const&) = delete; }; Which would replace the existing technique when C++11 support is on. I guess it could be argued that non copyable should imply non moveable. However, you won't hear me defending that position; plenty of thought went into move semantics with the defaults chosen to have sa[f|n]e behaviour. The derived class will still be subject to that criteria, I'm just trying to prevent noncopyable from artificially inhibiting move semantics. Would anybody want nonmovable? nonmoveable? Any thoughts / comments / omissions gratefully received. Ben

2 2

[iostreams] cin wrapper
by Daniel Larimer 06 Jul '12

06 Jul '12

I am attempting to 'wrap' std::cin such that all 'blocking' occurs in a dedicated 'cin' thread. This is required because in a cooperatively scheduled thread, no fiber can call cin and block. So I went about attempting a boost::iostreams::source: class cin_source : public boost::iostreams::source { streamsize read( char* s, streamsize n ) { if( n == 0 ) return n; auto r = std::cin.readsome(s,n); if( r <= 0 ) { // post read request to another thread. // cooperatively wait for it to finish... return n; } return r; } }; The problem I have is that this code causes read to be called with 'n == 0'; boost::iostreams::stream<cin_source> my_cin; char buf[100]; my_cin.read( buf, 100 ); It doesn't matter how I attempt to read from the stream, n always equals 0. What am I doing wrong? Dan

1 0

[format] Any interest in decoupling it from std::basic_string?
by news.gmane.org 06 Jul '12

06 Jul '12

I.e. such that alternative string implementations could be used (GCC's vstring, boost's...). I've attempted two methods, both pretty simple. First is to simply template basic_format on the string type and propagate that change throughout the library (including similar for the altstream/stringbuf classes). Second was to add a template template parameter for the string, e.g.: template <class Ch, class Tr, class Alloc, template <typename, typename, typename> class StringT = std::basic_string> class basic_format; and propagate that. I would assume the first method is definitely out due to breaking the interface (especially the altstream classes which I would guess are supposed to look like the std ones). I've not looked at whether something such as templatizing the str() method on the string implementation is possible, as either of the above is sufficient for my own purposes and trivial which I suspect a templatized str() wouldn't be... Anyway, if there's any interest I can post a patch for either or both and if not continue using the first method (simpler diff from the original)! Best regards Luke Elliott.

5 11

[Range] Range adaptor approach for temporary range lifetime issue
by Michel Morin 06 Jul '12

06 Jul '12

When an rvalue range is adapted in range-based for loop, the lifetime of the rvalue range ends before the loop body begins. For example, the following code produces dangling references. for (auto x : std::string("Hello world!") | reversed) { /*...*/ } This is the temporary range lifetime issue. When I proposed BOOST_FOREACH extension for this issue, ( http://lists.boost.org/Archives/boost/2011/04/180591.php ) a solution with "moving an rvalue range into range adaptors" was suggested in the thread. I implemented this approach as a range adaptor (with the aid of rvalue references and decltype C++11 features): for (auto x : std::string("Hello world!") | moved | reversed) { /*...*/ } When an rvalue range is piped to `moved` adaptor, it returns `moved_range`. `moved_range` stores the following data: * Moved rvalue range: The rvalue range is moved and stored in `moved_range`. * Applied adaptors: When range adaptors are applied to`moved_range`, they are not invoked immediately; they are stored in fusion vector. The stored adaptors are invoked when `begin` or `end` member functions of `moved_range` are called. (To prevent repeated applications of the stored range adaptors, begin and end iterators are cached when they are first computed.) For example, in `std::string("Hello world!") | moved | reversed`, 1. By applying `moved` adaptor, `moved_range` is created. It stores `std::string` object moved from `std::string("Hello world!")`. It doesn't store any adaptors. 2. By applying `reversed` adaptor, another `moved_range` is created. It stores `std::string` object moved from the previous `moved_range`. It also stores `reversed` adaptor in fusion vector. Step 2 is repeated if more adaptors are applied. Then, in "for-init-statement" of range-based for loop, the stored adaptors are actually applied (and the result is cached). The free function version (`boost::adaptors::move`) supports `std::initializer_list`: for (auto x : move( {1, 2, 3, 4, 5} ) | reversed) { /*...*/ } Note that we cannot support it in the pipe syntax `{1, 2, 3, 4, 5} | moved` because the C++11 Standard does not allow to use list initializers in binary operators. Code attached. Comments? Regards, Michel

7 40

[exception] [type_traits] warning: unrecognized #pragma GCC system_header
by Krzysztof Czainski 06 Jul '12

06 Jul '12

Hello, Below is a list of files, that contain: #if defined(__GNUC__) #pragma GCC system_header #endif which causes a warning on my TI compiler. E:\boost\include\boost-1_50_0\boost\exception\all.hpp E:\boost\include\boost-1_50_0\boost\exception\current_exception_cast.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\error_info_impl.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\exception_ptr.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\is_output_streamable.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\object_hex_dump.hpp E:\boost\include\boost-1_50_0\boost\exception\detail\type_info.hpp E:\boost\include\boost-1_50_0\boost\exception\diagnostic_information.hpp E:\boost\include\boost-1_50_0\boost\exception\errinfo_errno.hpp E:\boost\include\boost-1_50_0\boost\exception\exception.hpp E:\boost\include\boost-1_50_0\boost\exception\get_error_info.hpp E:\boost\include\boost-1_50_0\boost\exception\info.hpp E:\boost\include\boost-1_50_0\boost\exception\info_tuple.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string.hpp E:\boost\include\boost-1_50_0\boost\exception\to_string_stub.hpp E:\boost\include\boost-1_50_0\boost\throw_exception.hpp E:\boost\include\boost-1_50_0\boost\type_traits\is_virtual_base_of.hpp In other files, i.e. boost\integer.hpp, I've found this #pragma guarded against __GNUC__ >= 4: #if defined(__GNUC__) && (__GNUC__ >= 4) #pragma GCC system_header #endif which doesn't cause a warning on my compiler, because it defines __GNUC__ to 3. Could this be fixed in the files on the list above, or are there some __GNUC__ 3 compilers, that need this pragma to be enabled? Regards, Kris

3 5

[1.50.0] Release candidates available for testing
by Beman Dawes 05 Jul '12

05 Jul '12

Release candidate files for 1.50.0 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. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

8 16

Re: [boost] [cfe-dev] Using c++11 features in clang
by Marshall Clow 05 Jul '12

05 Jul '12

On Jul 5, 2012, at 12:41 PM, Joseph Galbraith wrote: > On 07/05/2012 12:29, Marshall Clow wrote: >> In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: >> http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html >> >> I don't know if this should be a FAQ entry for Boost, or for clang. >> Suggestions/comments/edits welcome. > > Isn't one of both of -std=c++11 and -stdlib=libc++ an ABI change? > > If so, it should probably be noted that all code should be build with > the same settings for these flags. Yes. > In particular, I think that you can't pass a std:: classes from libstdc++ > built code to libc++ code without bad things happening. I would expect that also, but libc++ has versioned namespaces that _should_ prevent that from happening (I.e, cause linker errors). > I'm not sure whether just turning whether the following is safe or not: > > clang++ -c -stdlib=libc++ x.cpp > clang++ -c -stdlib=libc++ -std=c++11 y.cpp > clang++ -stdlib=libc++ x.o y.o I would expect either: * It would "just work" * It would fail to link depending on what the contents of x.cpp and y.cpp were. If you can come up with a good way of explaining this, I'll be happy to add it to my post. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[interprocess] Problem building i386 binary on x86_64 MacOSX machine
by Walter Horsten 05 Jul '12

05 Jul '12

Hello, I have a program that uses boost::interprocess::message_queue, it used to compile correctly as a universal binary (i386 & x86_64) with boost version 1.47, however compiling for i386 fails with version 1.49 and 1.50. The most important parts of the error message are: - no matching function for call to 'boost::interprocess::message_queue_t<boost::interprocess::offset_ptr<void, int, long unsigned int, 0u> >::try_receive(void*, size_t, size_t&, unsigned int&)' - no matching function for call to 'get_rounded_size(long unsigned int, const unsigned int&)' ... is this a bug or is my code incorrect? (I suspect the size of the void* might have something to do with it?) The sample code in the attachment reproduces the problem on my MacBook Pro running OSX Snow Leopard (edit the boost prefix variable in the scripts to your own needs). Kind regards, Walter

1 0

[fusion] g++-4.6, deque, and c++0x compile error
by Karsten Ahnert 05 Jul '12

05 Jul '12

The following trivial program does not compile with g++-4.6.1 and std=c++0x enabled. #include <boost/fusion/container.hpp> int main( int argc , char *argv[] ) { } Seems like a bug, or should I configure something via macros?

3 5

[stratified] library for micro-/userland-threads
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, some of the community members ask me to provide a micro-/userland-thread library based on boost.context - I hope boost.stratified is a sufficient implementation. The library contains classes and interfaces similar to boost.thread. Examples and documentation (not finished and needs some updates/correction) is included. I hope I get some feedback from you. best regards, Oliver source: http://olk.bplaced.net/boost-stratified.zip documentation: http://olk.bplaced.net/boost/libs/stratified/doc/html/

9 24

[c++11] compile_if utility
by Lorenzo Caminiti 04 Jul '12

04 Jul '12

Hello all, I was thinking how to program assertion requirements in C++11. I need to program something like this if "has_equal_to<T>" then "assert(back() == value)" else do nothing, don't even compile "assert(back() == value)" Using C++11 lambdas, I was able to program a compile_if utility to do the following: compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); // compiled and executed iff has_equal_to<T> }); Any interest in adding compile_if to Boost.Utility? It could be renamed exec_if if compile_if is too "strong". I didn't play with compile_if much so there might cases where it doesn't work... but I wanted to share it with the ML anyway: #include <boost/type_traits.hpp> #include <cassert> #include <vector> #include <iostream> template< bool Boolean > struct compile_if_c { template< typename UnaryFunc > compile_if_c ( UnaryFunc f ) { std::cout << "compiling" << std::endl; f(); } }; template< > struct compile_if_c <false> { compile_if_c ( ... ) { std::cout << "not compiling" << std::endl; } }; template< class BooleanMetafunc, class UnaryFunc > void compile_if ( UnaryFunc f ) { compile_if_c<BooleanMetafunc::value> compile(f); } template< typename T > class vector { public: typedef typename std::vector<T>::const_reference const_reference; public: void push_back ( T const& value ) { vector_.push_back(value); compile_if< boost::has_equal_to<T> >([&]() { assert(this->back() == value); }); } public: const_reference back ( void ) const { return vector_.back(); } private: std::vector<T> vector_; }; struct x {}; // no operator== int main ( void ) { vector<x>().push_back(x()); // no == so skip assertion back() == value vector<int>().push_back(123); // has == so assert back() == value return 0; } Thanks. --Lorenzo P.S. Eh, if C++11 lambda had constant captures [const&](){ assert(this->back() == value; } I could have even made the assertion constant-correct...

3 4

[Review Request] Inclusion of the Boost.Polygon Voronoi Library
by Andrii Sydorchuk 04 Jul '12

04 Jul '12

Boost community, It has been two years since I started development of the Voronoi library as part of the Google Summer of Code 2010. Finally I feel that the library is ready to become public and would like to request a review for the inclusion into the Boost.Polygon library. Features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). The full list of features could be found here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm Limitations: - Input geometries should have integer coordinates; - Input segment data sets should not contain intersection points, except segment's endpoints. Information on why the first limitation is not sufficient is explained here: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm The second limitation could be waved using native Boost.Polygon functionality: http://svn.boost.org/svn/boost/sandbox/gtl/doc/gtl_polygon_set_concept.htm Resources: The code is already merged with the Boost.Polygon sandbox branch. All the Voronoi related files are prefixed with "voronoi". - Code location: http://svn.boost.org/svn/boost/sandbox/gtl - Main documentation page: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_main.htm or http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm - Benchmarks: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_benchmark.htm - Examples: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/example/output_data/ - Tests: http://svn.boost.org/svn/boost/sandbox/gtl/libs/polygon/test/ - Tutorials: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm and http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_advanced_tutorial.htm - Official Google+ page: https://plus.google.com/b/109395909314556242008/ Review manager: I would kindly ask Simonson, Lucanus J. the author of the Boost.Polygon library to be my review manager. PS. The library was designed in a user friendly way, so I would invite everyone to give it a try! No configuration of the geometric or predicate kernels is required. Simply follow the basic tutorial: http://svn.boost.org/svn/boost/sandbox/gtl/doc/voronoi_basic_tutorial.htm Thanks and have fun, Andrii

11 86

[ratio] error in template specialization: template parameter n1 depends on another template parameter
by Krzysztof Czainski 04 Jul '12

04 Jul '12

Hello, In order to use Boost.Ratio with my poor compiler from TI, I had to apply the attached fix. I suspect a more general fix would be desirable, should such a fix be added to Boost. However, before investigating further, I'd like to ask, if such a fix would be welcome, or is my compiler too poor to be supported by Boost.Ratio? Regards, Kris

2 3

boost.stratified -> boost.fiber
by Oliver Kowalke 04 Jul '12

04 Jul '12

Hi, as requested I've renamed boost.stratified to boost.fiber. archive is avialble at : http://olk.bplaced.net/boost-fiber.zip for those in Japan, Korea, etc please use http://www.hidemyass.com/ (proxy) to circumvent http 403 from the web-hoster. regards, Oliver

1 0

[type_index] C++03 implementation in boost?
by Agustín K-ballo Bergé 03 Jul '12

03 Jul '12

After crafting my own `type_info_ptr` as a thin wrapper to be able to use `std::type_info` as key in maps, I found out about the new `std::type_index` in C++11. It seems that a C++03 implementation would be trivial, except for the hashing functionality. Could that functionality be built by leveraging implementation specific details like whether there is only one `type_info` instance for each type, or whether the name member function returns distinct values? I believe it would be a nice addition to Boost, perhaps as part of the utility library. It would be useful for those wanting to use C++11 features while still writing C++03 compatible code. Agustín K-ballo Bergé.- http://fusionfenix.com

3 6

Large Integer Library
by Michael Tryhorn 03 Jul '12

03 Jul '12

Dear Boosters, I have written a Boost-compatible library for the representation and manipulation of integers of large or arbitrary size (including 128bit and above). I would like to make a preliminary submission of this library for your review and input, for potential inclusion into Boost v1.51.0 or later, as per the Boost Library Submission Process. The library and all its files are publicly available on github, at: http://github.com/mjtryhorn/Boost.LargeInt A tagged .zip of these files (v1.0.0) is available for download at: http://github.com/mjtryhorn/Boost.LargeInt/tags This library has been written for strict conformance to C++03 and the Boost coding guidelines. This library is also header-only, and as such may be directly merged into existing Boost installations without the need for recompilation. All files are distributed under the Boost Software License, Version 1.0. Now a quick explanation of why I've written this library and what it does: I have found myself on several occasions to be working with unsigned 64bit numbers, mostly for the sizes of files or C++ collections. Where I had a need to perform a calculation upon those numbers, there was often the possibility of overflow. 128bit integers would have been an appropriate fix, but these are either entirely unavailable, non-portable, or in a library which I preferred not to use either due to its complexity or incompatible licensing. Floating-point arithmetic is also a means around the problem, but is inherently inaccurate. I decided to fix this problem once-and-for-all by writing a new integer arithmetic library, making judicious use of C++'s template-metaprogramming and Boost to make my solution both as simple and as transparent as possible. Now, what started out as 128bit integers for my own use has grown into a fully- functional library which has the ability to compose any two integer or integer- like types into a new, larger, signed or unsigned integer type, including all the standard integral operators and a number of utility functions to support them. Thus, Boost.LargeInt supports not only signed and unsigned 128bit integer arithmetic but 24bit, 64bit, 160bit, 192bit, 256bit, 512bit and more. Boost.LargeInt is compatible and has been tested with the following compilers and platforms: GNU GCC 4.6.1, 4.6.2 (Linux, Ubuntu 11.10 (64bit) & openSUSE 12.1 (32bit)) Borland C++ 5.6.4 (Windows XP SP3, Borland C++ Builder 6) Microsoft Visual C++ 2010 (Windows XP SP3, Microsoft Visual Studio 2010) (I have also tried to add compatibility for Microsoft Visual C++ 6, but unfortunately this compiler's support for template-metaprogramming is insufficient and the tests for Boost.LargeInt fail to compile.) Documentation is included in BoostBook format (.qbk), but a pre-compiled version is available alongside the library code itself for your convenience. Please, if you have the time, download this library and give it a try. Any comments, or information upon its compatibility (or lack thereof) with compilers which are or are not listed would be greatly appreciated. If no-one has any comments (I think that unlikely ;-) ), then I shall resubmit this library for formal review. Thanks, Michael J. Tryhorn

9 20

CRC 16 Bit Implementation
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Hi, In my application I need to use crc_64_type. I did not find its implemetation in crc.hpp. Anyone implemented it? -- Regards, Gaurav

2 1

[range] treating N-ary function with N-1 default args as unary
by Nathan Ridge 03 Jul '12

03 Jul '12

Hi, Some Boost.Range adaptors, such as 'transformed' or 'filtered', require a unary function. The documentation does not formally define "unary function", but it's pretty clear what it ought to be: a function (object) that's callable with one argument. Thus, to me, the following is a perfectly valid unary function: int foo(int a, int b = 0); as it is callable with one argument. However, Boost.Range does not accept such a function as an argument to 'transformed' or 'filtered'. For example, the following code: #include <boost/range/adaptor/transformed.hpp> int foo(int a, int b = 0); int main() { int A[5]; A | boost::adaptors::transformed(foo); } produces the following compiler errors (recent Boost trunk, with GCC 4.7): In file included from boost/preprocessor/iteration/detail/iter/forward1.hpp:52:0, from boost/utility/result_of.hpp:113, from boost/iterator/transform_iterator.hpp:23, from boost/range/adaptor/transformed.hpp:16, from test.cpp:1: boost/utility/detail/result_of_iterate.hpp: In instantiation of 'struct boost::detail::cpp0x_result_of_impl<int (* const(int&))(int, int)>': boost/utility/detail/result_of_iterate.hpp:46:8: required from 'struct boost::result_of<int (* const(int&))(int, int)>' boost/mpl/eval_if.hpp:38:31: required from 'struct boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::result_of<int (* const(int&))(int, int)>, boost::mpl::identity<boost::use_default> >' boost/iterator/iterator_adaptor.hpp:160:12: required from 'struct boost::detail::ia_dflt_help<boost::use_default, boost::result_of<int (* const(int&))(int, int)> >' boost/iterator/transform_iterator.hpp:50:17: required from 'struct boost::detail::transform_iterator_base<int (*)(int, int), int*, boost::use_default, boost::use_default>' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: recursively required from 'constexpr const bool std::__has_iterator_category_helper<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >::value' c++/4.7.0/bits/stl_iterator_base_types.h:143:1: required from 'struct std::__has_iterator_category<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' c++/4.7.0/bits/stl_iterator_base_types.h:160:12: required from 'struct std::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/detail/iterator.hpp:81:8: required from 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp:30:75: required from 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/utility/detail/result_of_iterate.hpp:69:5: error: too few arguments to function In file included from boost/range/iterator_range_core.hpp:22:0, from boost/range/iterator_range.hpp:13, from boost/range/adaptor/transformed.hpp:15, from test.cpp:1: boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_value<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:139:49: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:30:75: error: no type named 'value_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_difference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:143:54: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:49:80: error: no type named 'difference_type' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/iterator/iterator_traits.hpp: In instantiation of 'struct boost::iterator_reference<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >': boost/range/iterator_range_core.hpp:157:53: required from 'class boost::iterator_range<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' boost/range/adaptor/transformed.hpp:25:16: required from 'struct boost::range_detail::transformed_range<int (*)(int, int), int [5]>' test.cpp:8:41: required from here boost/iterator/iterator_traits.hpp:36:74: error: no type named 'reference' in 'struct boost::detail::iterator_traits<boost::transform_iterator<int (*)(int, int), int*, boost::use_default, boost::use_default> >' Would it be possible to treat N-ary functions with N-1 default arguments as unary? Thanks, Nate

6 8

[Trac] New components
by Daniel James 03 Jul '12

03 Jul '12

Hello, Please can someone with the appropriate trac permissions add two new components "functional/overloaded function" and "local function", both have maintainer "lcaminiti". Maybe also "utility/identity type", or does that come under "utility"? thanks, Daniel

3 4

Thread (win32) and current_thread_tls_key issues
by Pekka Seppänen 03 Jul '12

03 Jul '12

Hi, Currently Threads's Win32 TLS implementation uses a global static variable thread::current_thread_tls_key that is defined in src/win32/thread.cpp. As you may know, static variables have a tendency of not being allocated in a very specific order. Say, that you have a statically allocated class A that ends up calling thread::set_current_thread_data() (eg. uses thread::thread_specific_ptr). If compiler initializes this class before it initializes current_thread_tls_key (this did happen to me on MSVC9) things go boom: a) Compiler initializes class A, thread::set_current_thread_data() is called, thread::create_current_thread_tls_key() is called once (as expected) and ::TlsAlloc() result is stored to thread::current_thread_tls_key. b) Compiler initializes thread::current_thread_tls_key, TLS_OUT_OF_INDEXES is stored and, as you may guess, c) Any following thread::set_current_thread_data calls will fail as the proper result from ::TlsAlloc() was overwritten. Don't know why this haven't happened before, as previous versions use a static variable, too. Maybe some compilers (MSVC in this case) omit initialization code unless initial value is a non-zero (as with TLS_OUT_OF_INDEXES [0xffffffff] in this case) value. I propose that thread::current_thread_tls_key is moved to a static function that sole purpose is to return reference to that variable (and thus ensure that current_thread_tls_key is initialized before it is used for the first time). Also, move thread::current_thread_tls_init_flag to thread::set_current_thread_data() to make sure this won't happen to that, too. Attached a patch that does the above trick (did move TLS_OUT_OF_INDEXES back to a macro as otherwise the code got too cumbersome, does get undef'd unless it was already defined by Winapi). If you like it, I can submit a ticket to Trac that includes the patch. (Haven't looked what happens during destruction, but guess it's not safe to use TLS features thru Thread.) -- Pekka

4 8

memcpy handling bug in regex_raw_buffer.cpp
by GAURAV GUPTA 03 Jul '12

03 Jul '12

Can anyone verify and commit the following Ticket: https://svn.boost.org/trac/boost/ticket/7032 -- Regards, Gaurav

2 1

Does Boost.Pool have a maintainer ?
by DUPUIS Etienne 03 Jul '12

03 Jul '12

Greetings, Does Boost.Pool have a maintainer ? If no, what happens in that case, who decides to include bug fixes for open bugs ? If there is no maintainer, can I become the maintainer ? If the answer to the latter question is yes, can someone volunteer to be my "mentor" to help me with issues related to the way boost development work ? I have already fixed pool bugs in the sandbox and added related test programs. Regards, Étienne Dupuis 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.

2 2

Priority Deque Container Adaptor
by Nathaniel McClatchey 03 Jul '12

03 Jul '12

Greetings. I have written a container adaptor implementing efficient double-ended priority queues. This preliminary submission is made to determine if/when a formal submission should be made and in the hope that it will be improved by your comments and reviews. The library (a single header file) is publicly available on mediafire: http://www.mediafire.com/download.php?gq8qjpgdoecgqq2 All files are distributed under the Boost Software License, Version 1.0. An explanation of what it does: This library replicates all functions of the STL priority_queue and adds functions for efficient access to the other end of the queue. Where the STL priority_queue uses a max-heap, I use a max-min heap (see article on Wikipedia). This leads to O(log n) complexity for single-element operations, and O(n) complexity for initialization and merging. TL;DR: Double-ended priority queue with algorithmic complexity equaling the STL single-ended priority queue. The current revision has been tested on: GCC 4.7.0 (MinGW on Windows 7 x64) Microsoft Visual C++ 2010 (on Windows 7 x64) Documentation may be generated by Doxygen. Any comments, criticisms, or compatibility information will be appreciated. I currently have one decision to make that requires experience beyond mine. Some const functions require calling operator() in a comparison class; should I make the class mutable, make a non-cost copy of the comparison class when needed, or require that operator() be a const function? So far, I have avoided the last option because it would make the class prerequisites more strict. Thanks, Nathaniel McClatchey

1 0

[1.51.0] Open for merging
by Daniel James 02 Jul '12

02 Jul '12

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging *does not* require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

1 0

Is there a macro to test if std::numerc_limits<>::max_digits10 is supported by a platform?
by Paul A. Bristow 02 Jul '12

02 Jul '12

A proposed (but not reverted) fix for Trac #5758: Boost.Test Floating-point comparison diagnostic output does not support radix 10 if( std::numeric_limits<T>::is_specialized && std::numeric_limits<T>::radix == 10 ) ostr.precision( 2 + std::numeric_limits<T>::max_digits10); // Assume that max_digits10 is provided for all radix 10 as they are quite new, // and anyway Kahan formula will not work for decimal. has caused trouble on platforms that do not yet support std::numeric_limits<T>::max_digits10 We need a macro perhaps BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 that will prevent the compiler seeing this code if max_digits10 is not supported. Do I need to add a default for all compilers # define BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 and then undefine for compilers that DO support #if defined (_MSC_VER >=1600) || (... other compilers that DO support) # undef BOOST_NO_NUMERIC_LIMITS_ MAX_DIGITS10 #endif Can anyone advise compiler versions or library versions that DO support max_digits10? Suggestions? Paul PS maxdigits10 will become more useful generally as the wrong value in float in MSVC 2011 seems to be corrected in Microsoft Visual Studio Ultimate 2012 RC 11.0.50522.1 --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

3 4

[contract] C++11-like auto-functions
by Lorenzo Caminiti 02 Jul '12

02 Jul '12

Hello all, I'm thinking to expand Boost.Contract to support C++11-like auto-functions for C++03. The following macro: CONTRACT_FUNCTION( // f template( typename Left, typename Right ) auto (adding_func) ( (Left const&) left, (Right const&) right ) return(BOOT_TYPEOF_TPL(left + right)) ) { return left + right; } Would expand to something like the code below (but the main of course): #include <boost/typeof/typeof.hpp> #include <iostream> template< typename Left, typename Right > // TPARAMS(f) struct adding_func_result_123 { Left const& left; // PARAMS(f) Right const& right; // PARAMS(f) typedef BOOST_TYPEOF_TPL(left + right) // RESULT_TYPE(f) type ; }; template< typename Left, typename Right > typename adding_func_result_123<Left, Right>::type // TPARAMS(f) adding_func ( Left const& left, Right const& right ) { return left + right; } int main ( void ) { std::cout << adding_func(1, 2) << std::endl; return 0; } I got a ticket for it: https://sourceforge.net/apps/trac/contractpp/ticket/59 But I might implement it only after the Boost review... (Are C++11 auto-function really useful?) Thanks. --Lorenzo

3 2

Re: [boost] Exact Decimal library
by Andrew Robb 02 Jul '12

02 Jul '12

Message-ID: <loom.20120702T032954-809(a)post.gmane.org> Hi Andrew, Would you be able to provide a short summary of the advantages, disadvantages or significant differences of your proposal versus the boost multi-precision library or the C++ std decimal proposal? Regards, Josh. The std decimal proposal seems to centre *IEEE 754-2008 * *hardware or slow software. My proposal is simple to make accounting safer to similar to SQL (NUMERIC and DECIMAL) using all hardware (including * *IEEE 754-2008 for IBM) but also in embedded processors.* * * *I *terminal brain cancer so I want to keep these out 'there'. http://ajrobb.livejournal.com/6918.html "I have expressive dyspepsia caused by terminal grade 4 glioblastoma mutiforme brain cancer" so writing and talking are difficult. Regards, Andrew Robb

1 0

[thread/exception] trivial compile fix
by Tim Blechmann 02 Jul '12

02 Jul '12

the boost.lockfree testsuite requires the following trivial patch, which specifies the namespace for enable_if and disable_if. i've applied a similar patch to boost.parameter some time ago [1]. as it is trivial, is it ok to commit to trunk or shall i submit it to trac that the thread/exception maintainers can apply it? tim [1] https://svn.boost.org/trac/boost/changeset/75902

4 13

thread & 1.50 issues
by Tim Blechmann 02 Jul '12

02 Jul '12

i came across two issues of boost.thread in 1.50. the first is a minor issue: the 1.50 tarball contains a libs/thread/src/shared_mutex.cpp source file, which includes boost/thread/v2/shared_mutex.hpp, which does not exist. by default it is not built, so it is not a big problem, but it is not really clean, either. the second issue is a bit more severe, as it is an undocumented API change: boost::TIME_UTC has been renamed to boost::TIME_UTC_ ... not sure what's the reason for it, but it breaks code that used the old symbol. this includes the boost-style threadpool library [1] ... so i wonder, is this change really needed? tim [1] http://threadpool.sourceforge.net

2 2

Re: [boost] Exact Decimal library
by Andrew Robb 02 Jul '12

02 Jul '12

I am proposing a Boost library for exact decimal numbers https://docs.google.com/document/d/19n-E8Mu-0MWCcNt0pQnFi2Osq-qdMDW6aCBweMK…<https://docs.google.com/document/d/19n-E8Mu-0MWCcNt0pQnFi2Osq-qdMDW6aCBweMK…> Message-ID: <33DFA071B6DD6D4FB44851BDE4A7259317128A(a)xchmbbal503.ds.susq.com> Andrew Robb wrote: > > Introduction [snip] > Exact Decimal [snip lots of information and reference links] The reason for your post is unclear. Are you proposing a Boost library? Are you asking for an indication of interest?

2 1

[geometry] distance on multiline with spherical coordinates
by Karsten Ahnert 01 Jul '12

01 Jul '12

Hi, the following code produces some strange results: typedef cs::spherical_equatorial< boost::geometry::degree > cs_type; typedef model::point< double , 2, cs_type > point_type; typedef model::linestring< point_type > linestring_type; point_type p( 1.0 , 1.0 ); linestring_type l; l.push_back( point_type( 0.0 , 2.0 ) ); l.push_back( point_type( 2.0 , 2.0 ) ); l.push_back( point_type( 4.0 , 2.0 ) ); cout << "Distance : " << boost::geometry::distance( p , l ) << endl; for( size_t i=1 ; i<l.size() ; ++i ) { linestring_type l_tmp; l_tmp.push_back( l[i-1] ); l_tmp.push_back( l[i] ); cout << "Point distance : " << boost::geometry::distance( p , l_tmp ) << endl; } The output is Distance : 0.0174373 Point distance : 0.0174586 Point distance : 0.0174373 This looks like a bug. The distance to the second segment can not be smaller than that to the first one. If I change the coordinate system to cartesian coordinates everything works as expected. Do I miss some major points?

2 7

boost::locale throw exception std::bad_cast
by Alex Ivanov 01 Jul '12

01 Jul '12

Here is code sample: boost::locale::generator gen; std::string text="To be or not to be, that is the question." ssegment_index map(word,text.begin(),text.end(),gen("en_US.UTF-8")); last line throw exception std::bad_cast The tests was made on tthe hosts: Darwin mac-os 10.4.0 Darwin Kernel Version 10.4.0 (gcc version 4.2.1) Linux fedora 2.6.34.9-69.fc13.x86_64 (gcc version 4.8.0 ) Linux fedora 2.6.34.7-66.fc13.x86_64 (gcc version 4.4.5) Linux debian 2.6.32-5-amd64 (gcc version 4.7.0) with boost_1_50_0_beta1 How can I handle this? -- реклама ----------------------------------------------------------- Распродажа % модной одежды. Скидки до 70%. Количество ограниченно! Подробнее на сайте Bonprix http://goo.gl/1qLK1

2 1

Formal Review Request: TypeErasure
by Steven Watanabe 30 Jun '12

30 Jun '12

AMDG I'd like to request a formal review of the TypeErasure library that I've posted about several times before here. The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. As an example of basic usage, we can simulate Boost.Any: any<mpl::vector<copy_constructible<>, typeid_<> > > x(10); int i = any_cast<int>(x); // i == 10 The library is available in the Boost Sandbox at http://svn.boost.org/svn/boost/sandbox/type_erasure/ You can download archives with pre-built documentation from http://sourceforge.net/projects/steven-watanabe.u/files/ Online documentation can be found here: http://steven_watanabe.users.sourceforge.net/type_erasure/libs/type_erasure/ In Christ, Steven Watanabe

26 118

[exception] Boost.Exception and the C++11 standard
by Vicente J. Botet Escriba 30 Jun '12

30 Jun '12

Hi, I was wondering how Boost.Exception works on compilers supporting 18.8.5 Exception propagation. Can an exception thrown by a 3pp library by retrieved by boost::current_exception() by another library or application code? BTW, what is the degree of compliance of Boost.Exception respect to 18.8.5 Exception propagation and 18.8.6 nested_exception sections of the standard? Do you have a plan towards been C++11 compliant? Best, Vicente P.S. I know that I can ask myself the same kind of questions respect to Boost.Ratio/Chrono/Thread, but this should be covered on a separate thread ;-)

2 1

Re: [boost] A GUI Library
by jinhao 30 Jun '12

30 Jun '12

On 2012/6/27 16:24, Klaim - Joël Lamotte wrote: > Hi, > > On Wed, Jun 27, 2012 at 2:55 PM, jinhao<cnjinhao(a)hotmail.com> wrote: > >> Is there any interest in this library? > > > My current understanding is that both Boost and the Standard C++ commitee > are interested in fully C++ library. > > However, the subject is complex and no library until now gathered > enough consensus to even get to the review stage of the boost process > (from memory). > You have to be ready for tons of feedback pointing problems. > > Now, I just read the websites but I have some questions: > > 1. can you write somewhere a big comparison between your library and other > popular GUI C++ libraries? Nana library is written though standard C++, this is a big difference between other libraries, as the brief mentioned, C++ idioms should works with a C++ library, and this is why the other popular GUI C++ libraries are not really C++ style at all. Secondly, this library can be work with a thread pool, it reduces the difficulty for threadization. > 2. if you want to submit your library to Boost, I think it would need to > be compatible (or maybe just use) boost.thread instead of your own solution I recognize that many ideas of my own solutions come from boost, not only boost.thread, there are boost.function, boost.any and so on, this is why I try to submit this library to boost and erase all my own solutions. > 3. the STR macro is a big problem, I think it will be a big source of > negative feedback. Now that we have boost.locale, would it be possible to > work with it instead? Somebody told me the problem before, I left the problem and searched a solution, I found many problem can be fixed by boost, and I rethink, can't keep on stealing ideas from boost. This is also why I try to submit this library to boost. > 4. I understand how you can build a GUI application in a way that is > mostly a list of statements. Does it means that you'd better organize your > windows/forms "types" as constructor functions? (ok found this that > partially answer my question: > http://nanaproject.wordpress.com/2012/01/31/idioms-and-insights-for-a-good-…) > 5. It is said that Nana is cross-platform, but I don't see any > demonstration of this (nevermind, I just found this: > http://nanaproject.wordpress.com/2012/05/16/tutorial-of-release-0-2-3/ ) > What are the target platforms? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now. > 6. Should it work in non-graphic contexts like command-line only display? > (I'm thinking about GUI working in bash for example) Yes, like ncurses. But now it is not able to work in such environment. > 7. Is it thought to be easily extendable? For example, can I write myself > a new front-end implementation and plug it in? The library provide a general method to implement a customer widget, and supports external image-processing algorithm implementation (http://nanaproject.wordpress.com/2012/04/17/an-introduction-to-the-image-pr…) > 8. do you have an available example of complex application being built > with this library? Yes, but its language is Chinese, it is a stock software, a screenshot at http://sourceforge.net/projects/stdex The status of this library I give is alpha and the so library is not used widely. Best Regards! Jinhao

5 6

Meeting C++ - Call for Papers
by Jens Weller 30 Jun '12

30 Jun '12

Dear C++/boost community! I'm proud to announce the call for papers for the Meeting C++ conference! After having talked to some people in Aspen about the plans for a C++ conference in Germany, I've decided to give it a try. Meeting C++ will take place in November in Germany, as a 2 Day C++ conference. We are looking for speakers and possible talks at our conference in fall! Possible topics could include: * (modern) C++ * C++11 * boost * C++ Frameworks like Qt, wxWidgets, Ogre, ... * other C++ related topics You'll find more information and updates at the webpage http://meetingcpp.com Tickets will be available from July at our website. regards, Jens Weller -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

2 2

[config] request for BOOST_NO_CXX11_HDR_ATOMIC
by Tim Blechmann 30 Jun '12

30 Jun '12

preparing boost.lockfree for trunk, i need a good way to figure out if the <atomic> header is available. would it be possible to add a macro to detect that? BOOST_NO_CXX11_HDR_ATOMIC or the like? thanks, tim

3 6

[smart_ptr] Patch for #6824
by Brent Lewis 30 Jun '12

30 Jun '12

Regarding bug report: https://svn.boost.org/trac/boost/ticket/6824 I've attached a diff file

3 2

[nowide] Updates and Standalone Version
by Artyom Beilis 30 Jun '12

30 Jun '12

Hello all Booster, Boost.Nowide updates: The library provides an implementation of standard C and C++ library functions such that their inputs are UTF-8 aware on Windows without requiring using Wide API to make program work on Windows. --------------------------------- I had updated the library: - Changed boost::nowide::convert to boost::nowide::widen, boost::nowide::narrow - Changed boost::nowide::args to restore an original values in destructor - Updated the docs. Also I had created a stand-alone version of the nowide library such that it does not require boost and can be build with CMake - the use is the same just change: #include <boost/nowide/foo.hpp> ... boost::nowide::fstream To #include <nowide/foo.hpp> ... nowide::fstream ------------ Looking forward for more comments on a library that I want to submit for a formal review. Library: Boost.Nowide Download: http://cppcms.com/files/nowide/nowide.zip Documents: http://cppcms.com/files/nowide/html/ Non-Boost: http://cppcms.com/files/nowide/nowide_standalone.zip Git Repo: git://cppcms.git.sourceforge.net/gitroot/cppcms/nowide Tested On: OS: Windows 7 32/64 bit, Linux Compilers: GCC-4.6, MSVC-10 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 7

[make_shared]
by Yuriy Zubritsky 30 Jun '12

30 Jun '12

Regarding https://svn.boost.org/trac/boost/ticket/6829 (make_shared is slower than shared_ptr(new) in MSVC) Does anyone want to apply it? It contains patch inside. Thanks

1 0

[BGL] How can I measure the memory used by a Boost graph ?
by ShNaYkHs ShNaYkHs 29 Jun '12

29 Jun '12

Hi, I have a graph defined as follow: struct NodeData{ /*...*/ }; struct EdgeData{ /*...*/ }; typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> MyGraph; MyGraph G; This graph is updated iteratively (by adding/deleting some edges/vertices). At each iteration, I want to evaluate the memory space occupied by this graph G. How can I do that ?

2 1

Tickets 6123 an 7023
by Luke Camden 29 Jun '12

29 Jun '12

Hi, Is anyone willing to commit these patches for me? If the process is not too involved I don't mind rtfm & DIY as an answer. Cheers, Luke

2 1

[1.50.0] Boost release 1.50.0 available
by Beman Dawes 29 Jun '12

29 Jun '12

Release 1.50.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains four new libraries (Algorithm, Functional/OverloadedFunction, LocalFunction and Utility/IdentityType) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_50_0 You can also download directly from SourceForge: http://sourceforge.net/projects/boost/files/boost/1.50.0/ To install this release on your system, see http://www.boost.org/doc/libs/release/more/getting_started/index.html Thanks, --The Boost release team Beman Dawes Daniel James Eric Niebler Marshall Clow Rene Rivera Vladimir Prus

3 4

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 29 Jun '12

29 Jun '12

Emil Dotchevski: >On Wed, Jun 27, 2012 at 7:46 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> Emil Dotchevski: >> >> > >> > There are 3 aspects of boost::throw_exception: >> > >> > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, >> > 2) it enables boost::error_info, and >> > 3) it enables boost::exception_ptr. >> > >> > 1) and 2) have nothing to do with threads; 3) implements >> > std::exception_ptr, which mostly benefits multi-thread programs (until >> > compilers catch up with std::exception_ptr support.) >> > >> > The cost imposed by libraries that use boost::throw_exception to programs >> > that don't use boost::exception_ptr or boost::error_info is that sizeof() >> > the exception object grows a little. >> >> I'd appreciate a way at compile time to let Boost Exception know >> I'm using it in a single threaded application and it wouldn't add stuff >> to the exception object that isn't needed. Also MSDN says, >> "Most applications do not have to transport exceptions between threads." >> > > There are exception_ptr use cases for single threaded programs. I'm not asking for this to be the default even for single threaded programs. I'd like it to be something that a user could opt out of if they want to. (This is all based on the possibilty that Boost Exception could become required. If that doesn't happen, this request wouldn't be very pressing from my perspective.) I haven't found much on use cases in single threaded programs. Do you have any links? I did find the following comment in some code that uses exception_ptr. "The reason here is that construction/destruction of an exception_ptr are not "cheap"" Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

4 5

Exact Decimal library
by Andrew Robb 29 Jun '12

29 Jun '12

Introduction C++ needs UTF-8 text (Boost.Locale) and exact decimal types support. Together they allow full processing of modern business text. Normal existing binary exponent types (float, double and long double) are not suitable for exact decimal numbers. The IEEE 754-2008 decimal exponent types should be allowed in binary files. Most processors already use IEEE 754-1985 for binary exponent types. IBM processors already support IEEE 754-2008 decimal exponent types in hardware and can used for optimization for exact decimal. Other processors may use fixed-point exact decimal. Exact Decimal Exact decimal numbers indicate not only the value but also the precision. Thus 0.3 and 0.30 indicate the same value but with different precisions. With rounding, the value 0.3 indicates a value between 0.25 and 0.35 but the value 0.30 indicates a value between 0.295 and 0.305. These are different ranges albeit different around the same centres but must be considered different because of their precisions. Currency values are ‘exact’ as there is no legal or commercial meaning in between the smallest adjacent values defined precision. Even when the GBP went decimal with a halfpenny coin, most banks would only keep values to the penny. A lot of normal commercial exact decimal values can be held in 32-bit with fixed-point decimal to 2 places (USD, EUR and GBP currencies) up to about 20,000.00 - more than enough for weekly groceries. As such, they are as quick as 32-bit integers for addition and subtraction an nearly as fast for multiplying too. Exact decimal processing would not require IEEE 754-2008 decimal exponent types and could use decimal fixed-point indest. Indeed, the range of significand could be more than used by IEEE 754-2008 decimal exponent types (e.g. java.math.BigDecimal). Embedded processors can support fast exact decimal their own way (floating or fixed). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf Extensions to support embedded processors must not give a general range decimal fixed-points. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf Extension for the programming language C to support decimal floating-point arithmetic. Again, from IBM and not for decimal fixed-point type. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2849.pdf Extension for the programming language C++ to support decimal floating-point arithmetic. Unfortunately the paper looks only at the IEEE 754-2008 hardware implementation rather than using decimal fixed-point implementation. The proposed solution might be enough for high-end database servers but not would helpful for x86 and ARM type embedded processors, where power savings for would be allowed by turning off the binary exponential processor as well as improved accuracy. For existing binary exponent types (float, double and long double), I think there should be new format string type (e.g “-123U-12”). This has a signed integer significand and a signed integer binary exponent. The significand cannot have decimals (no decimal point). Those IEEE 754 formats can indicate “Inf” and “NaN” as well (numeric_limits::is_iec559). There is no conversion error from binary exponent to decimal as is suffered currently. The new decimal types use a opaque arrangement. This allows each platform to use its own hardware to best effect. Each value is defined as a fixed number of decimal points. The significand grows or shrinks opaquely to take any value and can change how it works for each type. The fixed number of decimal points can be over the thousands before or after the decimal point. Thus the range of the decimal fixed points will be the same or more than those for decimal exponent types (-6143..6144). The significand has a least maximum 34 digits, again to match for decimal exponent - probably at least 38.23 for 128-bit significand. The method of keeping the significand can change with size and processor. For instance, 32-bit binary is fast on 32-bit processors (or 64-bit native binary). 30-bit (9 digit) or 10-bit (3 digit) decimal can grow (BigDecimal) for thousands of digits. IEEE 754 2008 decimal exponent types for IBM processors (also 10-bit groups of 3 digits) but slow without hardware support. Much of the work of exact decimal are similar to the SQL-92 types for NUMERIC (variable decimal places) and DECIMAL (fixed-point decimal) differ by variable or fixed decimal point. The NUMERIC type is similar to decimal exponent. The DECIMAL fixed-point decimal can be set by template or constructor. Only run-time decimal places available for NUMERIC. We don’t limit the number of decimal places but the SQL-92 types limit decimal places to 0 and number of digits (MySQL 5.0.3 supports 65 digits for NUMERIC and DECIMAL and DB2 supports 31 digits.) Accumulators There should be _Accum that can opaquely contain several decimal fixed-point accumulators of all different sizes (with the same fixed number of decimal points). Thus small efficient accumulators are used with small values. Whereas a _Decimal has a union defining the value, a _Accum might have a structure with similar members. If a overflow comes, its old accumulator value is added the to a slower bigger accumulator and reset the small accumulator. The small accumulator receives small values again. When the values are accumulated, the small accumulators are combined into the largest used accumulator for the final answer. Such a complicated behaviors arrangement needs compilation rather than C++ coding. For instance, using the overflow flag uses information from to the compiler. Operations We are only interested in (commercial) safe exact decimal operations for the following types: _Numeric: decimal exponent _Decimal: decimal fixed-point _Accum: several sized decimal fixed-point accumulators Multiply The exact decimal can be multiplied by other exact decimals and integers. The resulting decimal places are the sum of the right hand side. lhs = one * two; lhs *= integer; // or 0 decimal place Divide We can only divide by integers (or exact decimal with 0 place). The results have the same number of decimals. A divisor of zero will be thrown (no infinity). lhs = rhs / integer; lhs /= integer; Modulo There will be a remainder from a divide. Again with the same number decimals. lhs = rhs % integer; lhs %= integer; Add and Subtract We can add/subtract with other exact decimals with the same number of decimal places. Mixing values with different decimal places may cause problems for exact values (different truncation for instance). lhs = rhs + val; lhs = rhs - val; lhs += val; lhs -= val; Where values with different decimal places need combining explicitly we use trunc() to match the decimal places first. This can increase as well as decrease decimal places. It also allows tracks of errors. Comparison <, <=, ==, !=, >= and > between exact decimals with the same number of decimal places. Collections Any _Decimal collection can be limited to values with the same decimal fixed-point places. Truncation The binary exponent values float, double and long double have separate approximate values 1.3f, 1.3 or 1.3L for different sizes. I propose another exact decimal value, for example 1.300d for three decimal places. Alternatively use exact decimal exponent 1300e-3d version (using integer significand). Value Approximation 1.3f - 1.2999999523162841796875.. 1.3 - 1.3000000000000000444089209850062616169452.. 1.3L - 1.3000000000000000000000000000000000385185.. 1.300d or 1300e-3d - 1.300 (exact) Where a value is not the precision, we must expand or truncate to required decimals places and should choose a method of truncation (matched to IEEE 754-2008): ceil - the most negative answer not less than the original floor - the most positive answer not greater than the original zero - the answer furthest from zero not further than the original (the usual C method) round - the answer nearest the original choosing the most positive in case of a tie bank# - like round but choosing the even last digit in case of a tie expand - not truncation (zero padding) and the error should be zero As well as tructaton is then required value, there were be a leftover (similar in % value with a /). By keeping a record of truncation we can assess of errors. template <typename T> _Decimal & _Decimal::trunc(TRUNC, T const &source, T *error = 0); This will be a preferred way to convert binary exponent types into a decimal value for printing. Formatting For place 0 decimal format like integer and between places 1 and 9, the format will be decimal and trailing zeros are significant. Otherwise with the default format will be a exponent (matched to the decimal) with a integer significand. They will resemble binary float types, except that they are accurate and avoid decimals in the significand. 123 (0 decimal place so no decimal point) -0.012340 (6 decimal places) -12340e-12 (12 decimal places or decimal exponent -12) Final number formatting will be up to Boost.Locale using Unicode.

2 1

Range notation grammar
by Dave Abrahams 29 Jun '12

29 Jun '12

This ship has undoubtedly sailed, but I'd like to register my displeasure with names like "uniqued," "taken," and "strided" et. al. The effect (subjectively of course) is to take a beautiful, minimal abstract notation that reflects a common practice (seriously, it's "grep," which is a verb, not "grepped") and mess it up with unconventional and awkward linguistic insurance against misunderstanding. this-has-been-a-test-of-the-emergency-nattering-system-ly y'rs, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

date_time bug.
by GAURAV GUPTA 29 Jun '12

29 Jun '12

Hi All, I have reported one bug: Ticket No:7022. (Link is https://svn.boost.org/trac/boost/ticket/7022 ) As I have tracked. the owner (you can see it on ticket information) assigned to my ticket is not active. I have not found any posts by him newer that year 2007. So, could anyone help in verifying my patch for the reported bug?. I found this bug using some tool. Please reffer the ticket No. 7022 -- Regards, Gaurav

2 4

[review] status of Boost.Conversion?
by Nathan Ridge 29 Jun '12

29 Jun '12

Hi, I am wondering, what is the status of the Boost.Conversion library? On the Review Schedule page, it indicates that a review had taken place in August 2011 and the results of the review are "pending". Does anyone when the results will be forthcoming? Thanks, Nate

4 7

JNI library
by Felipe Magno de Almeida 28 Jun '12

28 Jun '12

Hello Boosters, I'm developing a JNI library for writing native code in C++ for Java and calling Java code within C++, using JNI as interface to the JVM. Is there any interest in this library? Regards, -- Felipe Magno de Almeida

3 10

[Survey] utf8_codecvt_facet::do_length parameter
by Marshall Clow 28 Jun '12

28 Jun '12

There's some confusion in boost (and in various standard libraries) as to the declaration of std::codecvt<>::do_length The '03 and '11 standards say: > template <class internT, class externT, class stateT> > class codecvt : public locale::facet, public codecvt_base { > // blah blah blah > virtual int do_length(stateT&, const externT* from, const externT* end, size_t max) const; > }; But some standard libraries (notably older Dinkumware libraries, and Visual C++ before Visual Studio11) say: > virtual int do_length(const stateT&, const externT* from, const externT* end, size_t max) const; (the first parameter is a const reference) There's some preprocessor stuff to deal with this in boost/detail/utf8_codecvt_facet.hpp, but it's wrong: > #if !defined(__MSL_CPP__) && !defined(__LIBCOMO__) \ > && !defined(_LIBCPP_VERSION) > #define BOOST_CODECVT_DO_LENGTH_CONST const > #else > #define BOOST_CODECVT_DO_LENGTH_CONST > #endif > > virtual int do_length( > BOOST_CODECVT_DO_LENGTH_CONST std::mbstate_t &, > const char * from, > const char * from_end, > std::size_t max_limit > #if BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) > ) const throw(); > #else > ) const; > #endif I'm happy to fix this, but I'd like to be sure which systems actually have const parameters. I've checked gcc and libc++, and they match the standard. STL assures me that all versions of Visual Studio before VS11 do not match, but VS11 does. The #defines above suggest to me that LibCOMO has this problem as well. Does anyone have access to such an install? And if anyone's standard library (that I haven't listed) does define the first parameter to std::codecvt<>::do_length as a const reference, please let me know. Thanks! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

[1.50.0] Release candidate 2 available for testing
by Beman Dawes 28 Jun '12

28 Jun '12

Release candidate 2 files for 1.50.0 are available at http://boost.cowic.de/rc/ RC 2 is supposed to fix the --layout build problems reported for RC 1. 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. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

7 7

[chrono] chrono/config.hpp enforces that time.h defines CLOCK_REALTIME; should it?
by Krzysztof Czainski 28 Jun '12

28 Jun '12

Hello, Suppose I want to use durations, and time_points with a user defined clock. I don't want to use any clocks provided by Boost.Chrono. My compiler provides a <time.h>, which doesn't define CLOCK_REALTIME, which chrono/config.hpp reports as an error. This prevents me from using parts of Chrono, that I believe don't depend on anything from <time.h>. I am able to work around this by simply defining CLOCK_REALTIME. But I would like to ask: Could Boost.Chrono allow using duration.hpp and time_point.hpp in my case? Regards, Kris

2 3

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 27 Jun '12

27 Jun '12

Emil Dotchevski: > On Tue, Jun 26, 2012 at 10:24 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> Is there a penalty for single threaded applications here? There's >> been discussion of the support for transferring exceptions between >> threads; are there aspects of that support that are unneeded in a >> single threaded context? >> > > There are 3 aspects of boost::throw_exception: > > 1) it enables libraries to support BOOST_NO_EXCEPTIONS configurations, > 2) it enables boost::error_info, and > 3) it enables boost::exception_ptr. > > 1) and 2) have nothing to do with threads; 3) implements > std::exception_ptr, which mostly benefits multi-thread programs (until > compilers catch up with std::exception_ptr support.) > > The cost imposed by libraries that use boost::throw_exception to programs > that don't use boost::exception_ptr or boost::error_info is that sizeof() > the exception object grows a little. I'd appreciate a way at compile time to let Boost Exception know I'm using it in a single threaded application and it wouldn't add stuff to the exception object that isn't needed. Also MSDN says, "Most applications do not have to transport exceptions between threads." Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

Re: [boost] program options (consider using BOOST_THROW_EXCEPTION)
by Leo Goodstadt 27 Jun '12

27 Jun '12

> On 22 June 2012 17:51, Vladimir Prus <ghost(a)cs.msu.su> wrote: > > > On 22.06.2012 11:33, Emil Dotchevski wrote: > > > >> On Thu, Jun 21, 2012 at 11:44 PM, Vladimir Prus<ghost(a)cs.msu.su> wrote: > >> > >> On 20.06.2012 07:44, Rowan James wrote: > >>> > >>> On a related note; is there interest in a patch set to use > >>>> BOOST_THROW_EXCEPTION to add this (yes, programmer-oriented) information > >>>> to > >>>> the exceptions thrown by Program Options and/or other Boost libraries? > >>>> > >>>> > >>> Sorry, but I kinda miss context here (and I did read your original post). > >>> What are advantages of > >>> using BOOST_THROW_EXCEPTION and what are drawbacks? Could you summarize > >>> those for me? > >>> > >>> > >> Allow me :- > >> > >> BOOST_THROW_EXCEPTION, being a macro, is able to record the file name, the > >> function name, and the line number of the throw, which is useful when > >> diagnosing unexpected exceptions: > >> > >> catch(...) > >> { > >> std::cerr<< "Unexpected exception caught. Diagnostic information > >> follows.\n"; > >> std::cerr<< boost::current_exception_**diagnostic_information(); > >> } > >> > >> The exception object is examined dynamically for any and all useful > >> information: type, what(), throw location, any stored boost::error_info > >> objects, etc. The location of the throw (if available) is formatted in a > >> way Visual Studio understands: double-clicking shows the throw location, > >> similarly to double-clicking compile errors. > >> > >> The downside is that when templates are involved, BOOST_CURRENT_FUNCTION > >> (invoked by BOOST_THROW_EXCEPTION) can bloat the code. There is a Trac > >> ticket for this. > >> > > > > Emil, > > > > thanks for explaining. Given the above, I am not sure I am interested in > > using > > BOOST_THROW_EXCEPTION for program_options, given that exceptions are used > > there to report > > user mistakes mostly, and so function name or file line is of limited > > interest. > > > > Thanks, > > Volodya > > > Thanks Emil. > > If I can make the case in favour of BOOST_THROW_EXCEPTION, it is for the > very reason that they are reporting user mistakes. The throw location for > an exception is typically accompanied by, or at least close to, the logic > that delineates such a user mistake from acceptable input. As such, it is > a useful remedy in itself; but also gives the user specific information for > finding documentation relevant to fixing the error. Without it, we have at > best the entry point into the library that; and often a lot less if the > exceptions are caught at a higher level. > > Documentation for valid inputs or states to a function can only say so much > about all the possible errors or exceptions that may occur. To elaborate on what Volodya said, program_options is unusual (for Boost) library in its use of exceptions: Most of the time, exceptions are there to inform the programmer of an error in the programme. However, the majority of exceptions in program_options are there to indicate a problem in the construction of the command line by the *end-user* (not the programmer). In other words, the program *is* working exactly as designed. The programmer has no interest in the provenance of these exceptions *except* that they can be used to inform the end-user how they should retype the command line and try again. So, for example, ten times a day, I will type something like ls --colour * and ls will tell me ls: unrecognized option '--colour' and I will know to retype the US spelling... ls --color * If "ls" were using program options, an unrecognised option exception message will be thrown which eventually allows this informative message to be displayed before exiting. It is entirely unhelpful for the end-user to have Exception XXX on line xxx of file yyy.... To make it easier to use program options *in English*, the exception messages have been recently rewritten to be maximally informative to the end-user rather than the programmers. Thus we can take e.what() and write it out to std::cerr without further ado. Of course, for localisation, these error messages have to be reconstructed in the appropriate language. Hopefully, there is enough data in each exception to allow this. Curiously, the current design of exceptions in program_options ended up try to mirror what Emil has done in BOOST_THROW_EXCEPTION. When the exception is thrown deep in the bowels of the command line parsing, it does not have the full context which would allow an informative message to be constructed. The exception has to be propagated up, and then "decorated" before being rethrown. The alternative was to pass the full context down the function call hierarchy to each point at which exceptions can be thrown. This made the code horribly convoluted and ugly, and provoked loud cries of anguish from Volodya. Leo

5 4

Interest in static multidimensional array.
by Brian Smith 27 Jun '12

27 Jun '12

Hi All, Some time ago I uploaded the maps folder, to Boost's sandbox, containing various multidimensional and mathematical arrays. The resulting discussion appeared to indicate some interest in the multidimensional arrays and that the overall design required some reworking. Having now had the opportunity to use a compiler supporting variadic templates, I have rewritten the static multidimensional array class using them. The class, documentation, and some tests are available at, https://github.com/BrianJSmith/Array All feedback would be welcome. Regards Brian -- www.maidsafe.net

2 2

[pool] Objects of varying sizes
by Robert Dailey 27 Jun '12

27 Jun '12

Is it possible to create a pool for polymorphic types? For example: class A; class B : public A; class C : public A; I want to create a pool of type A, but the allocation can be for B or C at any time. Will this work?

7 11

[build] Problem building boost libraries from trunk with layout versioned
by Thomas Heller 27 Jun '12

27 Jun '12

Hi, I am trying to build current trunk with layout versioned. Boost build is currently failing. This looks similar to the problem reported with the 1.50 RC. Here is the error: [heller@faui32m trunk]$ ./b2 toolset=intel --layout=versioned -j2 variant=debug Building the Boost C++ Libraries. Performing configuration checks - 32-bit : no - 64-bit : yes - x86 : yes - has_icu builds : yes warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : yes - icu : yes - gcc visibility : yes - long double support : yes warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <pstage/lib>libboost_context-il-mt-d.so error: previous virtual target { symlink%symlink.ln-libboost_context-il-mt-d.so.SHARED_LIB { common%common.copy-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.link.dll-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.compile.asm-asm/fcontext_x86_64_sysv_elf_gas.o.OBJ { asm/fcontext_x86_64_sysv_elf_gas.S.ASM } } { intel-linux%intel-linux.compile.c++-fcontext.o.OBJ { fcontext.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_allocator_posix.o.OBJ { stack_allocator_posix.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_utils_posix.o.OBJ { stack_utils_posix.cpp.CPP } } } } } error: created from ./stage-unversioned error: another virtual target { symlink%symlink.ln-libboost_context-il-mt-d.so.SHARED_LIB { symlink%symlink.ln-libboost_context-il-mt-d-1_50.so.SHARED_LIB { common%common.copy-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.link.dll-libboost_context-il-mt-d-1_50.so.1.50.0.SHARED_LIB { intel-linux%intel-linux.compile.asm-asm/fcontext_x86_64_sysv_elf_gas.o.OBJ { asm/fcontext_x86_64_sysv_elf_gas.S.ASM } } { intel-linux%intel-linux.compile.c++-fcontext.o.OBJ { fcontext.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_allocator_posix.o.OBJ { stack_allocator_posix.cpp.CPP } } { intel-linux%intel-linux.compile.c++-stack_utils_posix.o.OBJ { stack_utils_posix.cpp.CPP } } } } } } error: created from ./stage-unversioned error: added properties: none error: removed properties: none /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@3737 /home/heller/programming/boost/trunk/tools/build/v2/build/virtual-target.jam:135: in object(file-target)(a)3737.actualize from module object(file-target)@3737 /home/heller/programming/boost/trunk/tools/build/v2/build-system.jam:750: in load from module build-system /home/heller/programming/boost/trunk/tools/build/v2/kernel/modules.jam:283: in import from module modules /home/heller/programming/boost/trunk/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /home/heller/programming/boost/trunk/boost-build.jam:17: in module scope from module It seems to work when using --layout=system Anyone knows a fix to this? FWIW, toolset=gcc has the same problem Thanks, Thomas

2 2

program options (consider using BOOST_THROW_EXCEPTION)
by Roger Martin 27 Jun '12

27 Jun '12

Hi boost, At version 1.49.0 In testing command line with known unknowns such as -V a location unknown exception is thrown from inside program_options recommending to use BOOST_THROW_EXCEPTION. I've been trying to find this and apply BOOST_THROW_EXCEPTION to eliminate the verbosity for users: ---- Command line incorrect: Throw location unknown (consider using BOOST_THROW_EXCEPTION) Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::program_options::unknown_option> > std::exception::what: unknown option -V ---- With this fixed then it'd be closer to: -------- Command line incorrect: unknown option -V -------- Yet I haven't found where. Baffled. Any hint?

6 12

[stl_ext_adv] array based B+ tree
by Vadim Stadnik 27 Jun '12

27 Jun '12

Hi all, First of all, I would like to thank all Boosters for previous useful discussion of dynamically allocated augmented B+ trees. The development of the new array based variant of a B+ tree has been significantly influenced by these comments and suggestions. The problem of the C++ standard sequences based on linear data structures is that every of them has at least one inefficiency, such as linear cost of insert(), erase() functions of std::vector or slow bidrectional iterators of std::list. These inefficiencies create performance bottlenecks and significantly complicate the development of efficient general algorithms based on STL sequences. The new variant of an array based B+ tree offers a solution to these problems of STL sequences by reducing the running time of inefficient operations from linear to logarithmic in the worst case. The array based B+ tree implements a simple partition of an array into a list of sub-arrays connected to a B-tree. Compared to dynamically allocated B+ trees the new tree requires less space and improves locality of reference. In some aspect the array based B+ tree represents an enhanced pool allocator. Performance of the new tree has been optimized for container operations with large numbers of elements. In a number of tests the improvement factor is about 10. A significant advantage of the array based B+ tree over standard sequences is the support of splice() functions with logarithmic running time in the worst case. The high efficiency of these functions extends move semantics for non-intrusive STL sequences, since they allow user algorithms to insert and remove any range of consecutive elements. This high efficiency is not available in standard containers of C++03 and C++11. The splice() function of std::list has linear running time in the worst case. For a discussion of this problem by Boost community, please have a look at this thread: http://boost.2283326.n4.nabble.com/Containers-How-about-a-list-with-O-1-spl… For associative containers the array based B+ tree offers random access iterators and improved efficiency of many container operations against dynamically allocated B+ trees. In the general case associative containers cannot benefit from the splice() functions. Nevertheless, they can be used in algorithms for efficient split operations, since these operations do not change the order of elements in obtained containers. I think that the array based variants of B+ trees are very important, since they offer a number of performance benefits and can be used in many areas from mobile applications to processing huge data sets. The new array based B+ tree is described in this document: http://dl.dropbox.com/u/51041088/stl_ext_adv_doc/doc/array_based_bp_trees.h… The project with source code and tests: https://github.com/vstadnik/stl_ext_adv The new file with implementation of the array based B+ tree: https://github.com/vstadnik/stl_ext_adv/blob/master/container/bp_tree_array… I will appreciate any comments, suggestions and ideas concerning augmented array based B+ trees and STL variants of containers using these data structures. Regards, Vadim Stadnik

1 0

Re: [boost] Policy proposal: All user-visible exceptions should be thrown through BOOST_THROW_EXCEPTION
by Brian Wood 26 Jun '12

26 Jun '12

Pete Bartlett: < snip > > Cons for 1) and 2): > - Always paying for the cost of #including <boost/throw_exception.hpp> > - All libraries are dependent on - and therefore become vulnerable to any > future breakages (if any) in - Boost.Exception. Is there a penalty for single threaded applications here? There's been discussion of the support for transferring exceptions between threads; are there aspects of that support that are unneeded in a single threaded context? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Re: [boost] Interest in a "breadth first" algorithm?
by Brian Wood 26 Jun '12

26 Jun '12

Gary Powell: > > A while ago I needed to serialize and de-serialize a std::map and I > realized that the only interface was begin(), end() which of course meant > that re-creating this same map was the least efficient way possible, as all > the elements were added in sorted order. Because I wrote them out using > begin() -> end() So I wrote a breadth first template which takes a > container, a template to use as the core of a queue, a template for the > allocator, the container and a function to apply to the elements. > It doesn't quite do a true breadth first traversal because I don't look at > the inner data structure of the map, (works with sets as well) but instead > does a middle, then right, left push until it's hit all of the nodes. And > it doesn't copy the elements, it pushes the iterators, and calls the > function on that iterator when the length is 1. > It ended up speeding up my map recreation by about 20% (because I start > with a center enough node that it should never have to be rebalanced) at a > cost of about 5% to write it this way (It's more expensive to create the > queue, and traverse the map from center on out), for a roughly 15% gain in > speed. > Is there any interest this for boost? I've got working code but not any > documentation. And rather than spend a huge amount of time on that I'm > looking to see if anyone else has an interest in this. I'm interested. If you like I'll give you an investment in Ebenezer Enterprises [1]. If you post it here or send it to me, I'll probably use it in the archive available here -- http://webEbenezer.net/build_integration.html<http://webebenezer.net/build_integration.html> . [1] Past performance is not a guarantee of future results. > > "Come gather 'round people wherever you roam. And admit that the waters > around you have grown. And accept it that soon you'll be drenched to the > bone. If your time to you is worth savin'. Ahh you better start swimmin' or > you'll sink like a stone. For the times they are a-changin'" Bob Dylan Huh. Bob Dylan is from the Hibbing/Duluth part of Minnesota. In the days after you posted, that area received a summer's worth of rain in 36 hours. An 8 year old boy nearly died in the flooding when he was swept down a culvert. Thankfully he popped up a mile down the system and has been giving interviews since. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 1

Re: [boost] Boost and exceptions
by Stewart, Robert 26 Jun '12

26 Jun '12

Robert Ramey wrote: > Dave Abrahams wrote: > >> I mean, if there is a problem with boost::throw_exception or > >> any other part of Boost Exception, I'd like to know about > >> it. > > > > It seems clear to me from his posts that Robert wants to > > talk about the process and has forgotten any specifics about > > actual problems. > > > The problem was the gratuitious inclusion of a new dependency. Emil has described repeatedly why the change was not gratuitous. That you fail to recognize the value in the change does not make it gratuitous. I looked at a recent boost/throw_exception.hpp. It includes boost/exception/detail/attribute_noreturn.hpp. That creates a dependency inversion that is unfortunate. That is, a top-level header file depends upon a header file of a library's files. That header is very short and has nothing Boost.Exception specific, so the code could be moved into boost/throw_exception.hpp or boost/detail/attribute_noreturn.hpp, for example. The header also conditionally includes the non-trivial boost/exception/exception.hpp, another dependency inversion, which defines many types and functions, and includes some inline function definitions: boost::exception_detail::refcount_ptr boost:: error_info boost::exception boost::exception_detail::error_info_base boost::exception_detail::type_info_ boost::exception_detail::error_info_container boost::exception_detail::get_info boost::exception_detail::get_diagnostic_information() boost::exception_detail::copy_boost_exception() boost::exception_detail::set_info() boost::exception_detail::error_info_injector boost::enable_error_info() boost::exception_detail::clone_base boost::exception_detail::clone_impl boost::enable_current_exception() If BOOST_EXCEPTION_DISABLE is not defined, then boost::throw_exception() tacks on Boost.Exception features to the exception being thrown. This is a non-trivial set of changes to make to the top-level header. I didn't follow the discussion at the time, but I'll presume there was a lot of discussion about the type and extent of these changes and that it was considered a good idea. In hindsight, I agree with Robert's assertion that there should have been a replacement function, boost::exception::throw_exception() or similar, to introduce the new functionality. Whether the existing function needed to be deprecated is a separate issue. The result is that libraries could knowingly choose the new version, and a dependency on Boost.Exception, or, if warranted, stick with the old. As things now stand, if there is good reason to avoid the new version, it can only be done by defining BOOST_EXCEPTION_DISABLE, which affects an entire build. > The extent/nature of any problem it created or didn't create is > not relevant here. Just the injection of a new body of code > which replaced two lines and added no functionality used/needed > by the serialization library makes the any library which used > boost::throw_exception "bigger" for no reason. The issue you're raising, as I understand it, is dependency inversion: the top-level header brings a dependency on Boost.Exception. > It makes the library more "fragil". It means I have I a new > place to look if something needs looking into. etc.etc. As Nevin pointed out, your code will always be subject to the changes in those libraries on which it depends. The more dependencies you introduce, the more fragile your code becomes, but there's a great deal of benefit to reuse, too. The only issue in this case is that one can reasonably expect a top-level header to avoid dependencies on libraries. > So we'll just move on as Vicente suggested. That will be > satisfactory from my standpoint. That is the only way forward, if there is good reason to avoid the now longstanding changes to boost::throw_exception(). However, you should work with Emil to be sure you correctly and fully understand the issues before deciding that you cannot accept boost::throw_exception() as is. (I don't pretend to know what your concerns are. I just don't want to see a new throw_exception() variant if there isn't a compelling reason, and I don't consider your fragility argument compelling in this case.) _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

20 91

[contract] relaxing preconditions in subcontracting
by Andrzej Krzemienski 26 Jun '12

26 Jun '12

Hi Lorenzo, I am trying to understand how the feature of relaxing preconditions in overridden functions work or should work. Given the situation, where I call an overridden function via base class reference: *struct Base { virtual void fun(bool b) = 0 precondition{ b == true }; }; struct Deriv : Base { void fun(bool b) override precondition{ true }; }; void test( Base & b ) { b.fun(false); **// broken contract or not?** }* Should this be treated as a broken contract or not? My reading of the documentation says that contract is not broken (because the "logic-or<http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…>" logic applies), but I feel that whoever implemented function *test *made a mistake: he cannot assume what type will be implementing "interface" *Base*, so he cannot rely on the precondition being relaxed (even if he gets away with it this time). Regards, &rzej

2 7

boost with cxxflags=-Zc:wchar_t-
by Renato Tegon Forti 25 Jun '12

25 Jun '12

Hi All, I'm mixing QT and boost and noticed problems with wchar_t! I need to compile boost: cxxflags =-Zc: wchar_t- Would like to know what problems I can find! anyone ever had to use 'wchar_t-"? Libs that I am using: boost_mpi boost_serialization boost_system boost_filesystem boost_thread boost_iostreams Thanks

3 2

library dependencies and boost modularization [ was Boost and Exceptions]
by Robert Ramey 25 Jun '12

25 Jun '12

Boost has now close to 100 libraries. In addition there are hundreds of smaller but necessary facilities which aren't technically libraries but they add a lot to the "surface area" that one's brain has to be familiar with to take best advantage of boost facilities. There is also a lot of interconnectedness which makes it an even larger task. This wasn't a big deal when boost was 15 libraries - but now it's different. I would like to propose a classification of boost libraries and guidelines for future libraries. a) Layering of libraries =============== 0) C++ standard library 1) "boost core" libaries 2) "boost utility" libraries 3) "boost user" libraries b) Guidelines ========= 1) a library in a given layer shall include code from libraries in a higher layer 2) boost core libraries are in namespace "boost" 3) boost user libraries are in the name space boost::<name of user library> 4) there is a special user library named "utility" for small libraries which are widely used. 5) boost header directory structures should match namespace structure. example, a library named boost.range should have all it's code in namespace boost::range and in the directory boost/range. 6) exception to 5) above, a user library might have a "convenience header" in directory "boost" which includes all the header directories of that user library. c) Rationale ======== 1) it diminishes the possibility of namespace conflicts as boost/C++ grows 2) it diminishes the possibility of importing a lot more code and depencies than one expected. 3) a library can control its depencies. Often a library will rely only on "boost core". This means that users of the library can know that code is dependent only on that library. 4) It more easily supports the concept of "boost modularization" where by deployment of a subset of boost libraries is can be supported. It's often mentioned how other languages like java, C#, perl have HUGE number of libraries in comparison to C++. I believe these languages have reached their peak and are in fact in decline somwhat. It is possible that this huge number of libraries make them less attractive rather than more? Perhaps a little more formal structure applied to our work might be agood thing. Robert Ramey

1 0

[serialization] Reading newer archives - was throwing unsupported_class_version, now crashes
by Nikolay Mladenov 25 Jun '12

25 Jun '12

Hi Robert, I remember that in the past the serialization library was throwing unsupported_class_version exception when reading of archives with future class versions. This no longer seems to be the case. We had older version of software crash when reading newer archive. The only place that I found to mention unsupported_class_version is commented out and I do not understand the attached note: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // note: we now comment this out. Before we permited archive // version # to be very large. Now we don't. To permit // readers of these old archives, we have to suppress this // code. Perhaps in the future we might re-enable it but // permit its suppression with a runtime switch. #if 0 // trap case where the program cannot handle the current version if(file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); #endif // make sure call is routed through the higest interface that might // be specialized by the user. boost::serialization::serialize_adl( boost::serialization::smart_cast_reference<Archive &>(ar), * static_cast<T *>(x), file_version ); } To allow class to read serialized objects of newer version by default seems very dangerous. I generally requires extra work from the class author and without it will most likely crash. So isn't it better to have an additional trait that a class author needs to define, if a class should be allowed read future versions? something like namespace boost{ namespace serialization { template<class T> struct allow_future_versions : mpl::false_ {}; }} #define BOOST_SERIALIZATION_ALLOW_FUTURE_VERSIONS(T) \ namespace boost{ namespace serialization \ { \ template<> struct allow_future_versions<T> : mpl::true_ {}; \ }} and change the code above to: BOOST_DLLEXPORT void iserializer<Archive, T>::load_object_data( basic_iarchive & ar, void *x, const unsigned int file_version ) const { // trap case where the program cannot handle the current version if( ! boost::serialization::allow_future_versions<T>::value && file_version > static_cast<const unsigned int>(version())) boost::serialization::throw_exception( archive::archive_exception( boost::archive::archive_exception::unsupported_class_version, get_debug_info() ) ); ...... Thanks in advance, Nikolay Mladenov Sitius Automation Inc.

3 10

[move] GCC bug and aliasing questions
by Tr3wory 25 Jun '12

25 Jun '12

Hi, Yesterday I started using Boost.Move in my project. On gcc I had the same problem like the guys here: http://lists.boost.org/Archives/boost/2011/07/184263.php Namely, I can't define the move constructor nor the assignment operators outside my class... After some time I managed to create a minimal example (19 lines) and sent a bug report to the gcc guys: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53725 So far, so good. In the minimizing process I found something interesting: the problem vanishes if I remove the __may_alias__ attribute from the rv<> class. This got me thinking. Do we need this attribute at all? The problematic expression is this: (It's in macros normally placed inside a class, TYPE is the name of this class.) operator ::boost::rv<TYPE>&() { return *static_cast< ::boost::rv<TYPE>*> (this); } But rv<TYPE> is derived from TYPE so to me it looks like the two type is compatible, therefore the code didn't violate the strict aliasing rules, so the attribute is not necessary. (BTW can we violate the strict aliasing rules trough static_cast if we don't do any chained conversion trough void*?) On the other hand, if it's really breaks the rules then we solved the problem for gcc, but we still have undefined behavior on every other compiler. Can we fix this somehow? Cheers, tr3w

3 5

An alternative approach to TypeErasure
by Pyry Jahkola 25 Jun '12

25 Jun '12

Hi all, I was quite impressed by Sean Parent's Friday talk in C++Now! 2012 (see slides in [1], code in [2]) and was left wondering whether the generation of his polymorphic object wrapper could be made simple somehow in C++11. [1]: https://github.com/boostcon/cppnow_presentations_2012/raw/master/fri/value_… [2]: https://github.com/boostcon/cppnow_presentations_2012/blob/master/fri/value… What I ended up with is tricking ADL into allowing the overloading of arbitrary (specifically crafted) function objects that I call _callables_, and then letting the user define interfaces by specifying sets of ("member") function signatures with a callable. You can find the code, and my rambling introductory README file, in GitHub: https://github.com/pyrtsa/poly Comments are welcome! * * * Here's a somewhat shorter intro: 1) Create a callable F by simply deriving it from poly::callable<F>: struct draw_ : poly::callable<draw_> {}; constexpr draw_ draw = {}; 2) Or use the convenience macro POLY_CALLABLE(name) to do the same: POLY_CALLABLE(to_string); // type `to_string_` and object `to_string` 3) Overload your callables by overloading the function named `call`, with the callable as first argument: template <typename T> void call(draw_, T const & x, std::ostream & out, std::size_t position) { out << std::string(position, ' ') << x << std::endl; } std::string call(to_string_, int i) { return std::to_string(i); } template <typename T> std::string call(to_string_, std::vector<T> const & xs) { std::ostringstream s; s << '['; auto i = begin(xs), e = end(xs); if (i != e) s << *i++; while (i != e) s << ", " << *i++; s << ']'; return s.str(); } Now you can call ::draw(x, o, p) and ::to_string(x) for several different types of x: ::draw(123, std::cout, 2); // prints " 123" to stdout ::to_string(std::vector<int>(1, 2, 3)); // "[1, 2, 3]" But you can likewise extend ::draw and ::to_string further by overloading them for your own types too. 4) Define an interface by specifying the set of function signatures as template arguments to poly::interface: using drawable = poly::interface< void(draw_, poly::self const &, std::ostream &, std::size_t, std::string(to_string_, poly::self const &)>; Now, the following calls got automatically defined, and forwarded to whatever type you successfully construct a `drawable` from: void call(draw_, drawable const &, std::ostream &, std::size_t); std::string call(to_string_, drawable const &); * * * I am aware that Steven Watanabe has put some astonishing work on his proposed Boost.TypeErasure. I'm open for discussion whether and how his or mine is a better approach, or if we could combine these into an eventual Boost.Interface library or such! * * * PS. Like I mention in my GitHub page, this kind of type erasure is common in functional languages like Haskell or Clojure. The problem they are solving there is known as the Expression Problem. IMO it makes very much sense to have the corresponding construct in C++ too, as we're moving towards a more and more functional style with parallelism and such. Best Regards, -- Pyry Jahkola pyry.jahkola(a)iki.fi https://twitter.com/pyrtsa

7 16

Multiprecision Review
by Phil Endecott 25 Jun '12

25 Jun '12

Dear All, Here is my review of the proposed Multiprecision review. First a rant: why have so few people contributed to the discussion or written reviews? I have waited until now before writing this in the hope that others would say something useful, but there has been very little to read. Boost will suffer as a result of this. It has been depressing to see that at the same time the mailing list has been full of other discussions, so the problem is not that people don't have the time to contribute. In particular, the long thread about Boost.Exception makes me want to shout "Why Didn't You Say All This When It Was Reviewed?". My view of the proposed library can be summarised as follows: it doesn't do what I want, but maybe it does enough things that other users would like to justify its acceptance anyway. Except probably it doesn't, because if it did those other users would have said so, which they haven't. In particular, I'd like to be able to implement integers of perhaps 128 or 256 bits that behave like the built-in integers. I can quickly throw together something myself that works OK but: - It's difficult to get the last bit of performance because you need to write asm to use the CPU's carry flag; the work-around probably results in a 2X slowdown. - Writing all the operator overloading etc. is tedious. - It's also error prone, as a mistake in e.g. carry propagation might be detected once in very 2^32 operations. It would have been great if this library could have helped with this. Instead, it has produced something worse than my "quick throw-together". It's worse because it has tried to unify this smallish fixed-size type with very large variable-size types, and the compromises necessary to achieve this have sabotaged the performance. It's also worse because it had a subtle bug - which has since been corrected, but I would still not be confident of getting correct answers without verifying against another implementation. Ideally, there would still be some parts of the library that could be useful to me. If the library had been decomposed into data structures vs. algorithms then perhaps I could have applied the algorithms to my simpler data structures. Unfortunately the library has not been organised in this way, and even if it had done the use of sign-magnitude representation might have scuppered any re-use. As far as I can see, the only part of the library that I could re-use would be the expression template front-end, which doesn't seem to improve performance for types of this size anyway. Here are my answers to the standard review questions: What is your evaluation of the design? Not great for my purposes; see above. What is your evaluation of the implementation? I spent half a day chasing down a bug. My observations are that (a) there are subtle bugs, and (b) the code lacks comments or other clues for people like me to quickly pick up what it's all doing. What is your evaluation of the documentation? Satisfactory. What is your evaluation of the potential usefulness of the library? Not useful for me; see above. Did you try to use the library? With what compiler? Did you have any problems? I spent perhaps a day working on a small but real benchmark which was discussed on the mailing list. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About a day-and-a-half in all. I've not looked beyond the areas that I've discussed and I'm aware that there is a lot more to the library i.e. non-integer types. Are you knowledgeable about the problem domain? Not especially. Do you think the library should be accepted as a Boost library? No, because (a) I'm not convinced from this discussion that lots of people are waiting for this functionality (see above). (b) Based on previous experience, I'm sceptical about the possibility of the performance of Boost libraries being improved after acceptance. Despite that, I thank John and Chris for their work which is a considerable leap forward from the last "big number" submission, "xint". Regards, Phil.

5 5

Contribute
by Merve Temizer 25 Jun '12

25 Jun '12

Hello, I am not sure if this is right place to write but, how can i contribute as a newbie programmer? My main intention is learning C++ deeper by contributing to some open source organizations. Sorry for if it is wrong place. Thanks in advance.

2 1

[fusion] for_each on gcc 4.7
by Daniel Larimer 24 Jun '12

24 Jun '12

I recently attempted to update to gcc 4.7 and code that compiled with 4.5.3 broke. It appears that boost::fusion expects boost::fusion::random_access_traversal_tag to implicitly cast to mpl::bool_<false>. Switching the 3rd argument from mpl::bool_<false> to an extra template arg (that was ignored), seems to fix the compilation errors. Compiled with std=c++11 /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: error: no matching function for call to 'for_each(boost::fusion::vector2<double, double>&, const mace::rpc::detail::unpack_sequence<mace::rpc::function_filter<mace::rpc::connection<mace::rpc::json::io> > >&, boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type)' /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: note: candidate is: In file included from /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:11:0, from /usr/local/include/boost/fusion/algorithm/iteration.hpp:12, from /usr/local/include/boost/fusion/algorithm.hpp:10, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/io.hpp:13, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/tcp/server.hpp:4, from /Users/dlarimer/projects/mace/libs/rpc/examples/json_tcps.cpp:1: /usr/local/include/boost/fusion/algorithm/iteration/detail/for_each.hpp:130:5: note: template<class Sequence, class F> void boost::fusion::detail::for_each(Sequence&, const F&, mpl_::false_) /usr/local/include/boost/fusion/algorithm/iteration/detail/for_each.hpp:130:5: note: template argument deduction/substitution failed: In file included from /usr/local/include/boost/fusion/algorithm/iteration.hpp:12:0, from /usr/local/include/boost/fusion/algorithm.hpp:10, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/io.hpp:13, from /Users/dlarimer/projects/mace/libs/rpc/include/mace/rpc/json/tcp/server.hpp:4, from /Users/dlarimer/projects/mace/libs/rpc/examples/json_tcps.cpp:1: /usr/local/include/boost/fusion/algorithm/iteration/for_each.hpp:32:9: note: cannot convert 'boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type()' (type 'boost::fusion::detail::fusion_category_of<boost::fusion::vector2<double, double> >::type {aka boost::fusion::random_access_traversal_tag}') to type 'mpl_::false_ {aka mpl_::bool_<false>}'

5 8

Re: [boost] [review] Multiprecision review (June 8th - 17th, 2012)
by Keith Burton 24 Jun '12

24 Jun '12

Instant reactions on reading though the documentation : 1) Introduction : I would prefer to see e.g. mp::int128_t rather than mp::mp_int128_t, given the stated purpose of the library. 2) cpp_dec_float : Narrowing conversions are truncating. This is a no-no for the usage I have in mind at the moment. 3) Constructing and interconverting : >> // There is a need to be careful with integer types though: >> cpp_int i = 2; >> // Ooops, this really just multiplies by 3: >> i *= 3.14; One of the priorities for my numeric class implementations has always been to protect naive users from equivalent mistakes. What is your evaluation of the design? It is so far beyond anything I have attempted that I cannot usefully comment. The limitations on conversions and mixed precision operations are disappointing but entirely understandable. The ccp_dec_float narrowing conversions being truncating reinforces the my view that the limitations are probably the correct design. What is your evaluation of the implementation? No useful comments. What is your evaluation of the documentation? Good enough to give me confidence to start using the library. I would never expect more than that. What is your evaluation of the potential usefulness of the library? A vital addition to C++ especially for relatively small tasks in commercial software where the Boost backends can be used because performance is not an overriding concern. Did you try to use the library? With what compiler? Did you have any problems? I have started to use the library to embed test code for my special purpose decimal fixed point classes into an application under development. The only issue, using VS2008 /W4 and Boost 1.48, was the need to disable warning 4996. Unfortunately this has been pre-empted by other work. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? More than a quick reading Are you knowledgeable about the problem domain? I have written several numeric classes but all with a narrow scope and protection of naïve users and accuracy as the priority. These were primarily decimal fixed point. Do you think the library should be accepted as a Boost library? Yes

3 2

[multiprecision] Last chance for a review.
by John Maddock 24 Jun '12

24 Jun '12

Just to remind everyone that the multiprecision library review is about to come to an end, so it's time to speak up or shut up ;-) Actually we're a little short on reviews generally, so I'd encourage anyone who hasn't taken a look yet to do so, code is the sandbox under /big_number/, docs are viewable online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… Many thanks, John.

3 2

Trimming Dependencies (was Boost and exceptions)
by Daniel James 24 Jun '12

24 Jun '12

On 24 June 2012 01:55, Dave Abrahams <dave(a)boostpro.com> wrote: > > on Sat Jun 23 2012, Daniel James <dnljms-AT-gmail.com> wrote: > >> >> That's pretty crazy. Do you know if separating test dependencies would >> make much of a difference? > > They're already separated, along with documentation dependencies. You > *really* don't want to see the graph that includes the test dependencies > ;-) OK, I assumed from the dependencies on Test that they were included, but some headers do depend on Test.

2 1

Boost and exceptions
by Dirk Ulrich 24 Jun '12

24 Jun '12

Dear all, when looking at Boost as a whole its obvious that it uses C++ exceptions to report exceptional conditions because its the C++ way of doing it and it has to interact with the C++ standard library. On the other hand it seems also obvious that some libraries (Boost.Units, Boost.MPL, etc.) do probably not use C++ exceptions at all since they are pure compile time libraries or provide services which do not have exceptional cases. I am working on a C++ based project which forbids the usage of C++ exceptions but it is still preferable to use Boost libraries at least the ones which do not make use of C++ exceptions at all. I am especially interested in using Boost.Units and Boost.Math. Which of Boost libraries do NOT make use of C++ exceptions (i did not find such a list but maybe its already available somewhere)? What would it take to use these libraries as a stand-alone "minimal" Boost library? Thanks

18 71

Boost's on the map
by John Maddock 23 Jun '12

23 Jun '12

Literally in this case: http://softwaremaniacs.org/media/alenacpp/cppmap-2012.png John.

4 3

Re: [boost] Boost and exceptions
by Brian Wood 23 Jun '12

23 Jun '12

John Maddock: > This actually looks compelling enough to me, that we should probably mandate > use of BOOST_THROW_EXCEPTION. Are you going to take away their library card if an author doesn't want to do this? ;) Cheers, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Re: [boost] Boost and exceptions
by Brian Wood 23 Jun '12

23 Jun '12

Fabio Fracassi: > That is how modular development works, you let go of some control in > exchange for synergy effects and free added functionality. > Yes, it creates communication overhead but the win (for the users) is huge. I skipped Boost 1.49 and have been updating these results using Boost 1.50 -- http://webEbenezer.net/comparison.html<http://webebenezer.net/comparison.html> . I haven't noticed any performance improvements in the serialization library that's in Boost from 1.48 to the latest version. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

1 0

Linked map
by Kannan R 23 Jun '12

23 Jun '12

Recently i wrote a json parser. I used stl map to store the json objects. Everything was fine except the order of the objects. Is it worth to build something in boost to have the map which provides an iterator to get the elements in same order? Please advise.

3 2

exception handling in multithreaded applications (was: RE: Boost and exceptions)
by Thomas Klimpel 22 Jun '12

22 Jun '12

Fabio Fracassi wrote: > Yes it is, because in reality boost exception solves problems for the > users of any library that uses it. When using boost exception I can > safely let exceptions escape threads and have them rethrown in the > starting thread, for instance. I would be interested to learn how you do this. With open-mp (and mpi), my current way to add exception handling code really adds much noise: bool cancel = false; #pragma omp parallel shared(cancel) { try { ... the real code } catch (std::exception& r) { cancel = true; store_exception(r); } } if (cancel) { rethrow_exception(); } Regards, Thomas

2 1

emulating concepts in C++11
by lcaminiti 22 Jun '12

22 Jun '12

Hello all, I was not able to find Boost.Generic source code (I asked Matt Calabrese but no reply): http://blip.tv/boostcon/boost-generic-concepts-without-concepts-5262126 Are you aware of any trick (e.g., the tricks used by Boost.Generic) to emulate concepts in C++11? Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-emulating-concepts-in-C-11-tp46317… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Still a monolithic library? Or a bunch of independent ones?
by hello world 21 Jun '12

21 Jun '12

Hello, It's been a few years since I didn't come around boost.org, and I was just wondering... Is boost still a monolithic library? or Is it a collection of separate libraries now? Or to state it another way: Is it ``easy'' to take only one library's files from the boost distribution and use it. Or do I have to carry everything around even If I'm using just one library? I understand that this must be library specific, but I'm just asking this to know what your general feel overall. Thanks.

3 2

Interest in a "breadth first" algorithm?
by Gary Powell 21 Jun '12

21 Jun '12

A while ago I needed to serialize and de-serialize a std::map and I realized that the only interface was begin(), end() which of course meant that re-creating this same map was the least efficient way possible, as all the elements were added in sorted order. Because I wrote them out using begin() -> end() So I wrote a breadth first template which takes a container, a template to use as the core of a queue, a template for the allocator, the container and a function to apply to the elements. It doesn't quite do a true breadth first traversal because I don't look at the inner data structure of the map, (works with sets as well) but instead does a middle, then right, left push until it's hit all of the nodes. And it doesn't copy the elements, it pushes the iterators, and calls the function on that iterator when the length is 1. It ended up speeding up my map recreation by about 20% (because I start with a center enough node that it should never have to be rebalanced) at a cost of about 5% to write it this way (It's more expensive to create the queue, and traverse the map from center on out), for a roughly 15% gain in speed. Is there any interest this for boost? I've got working code but not any documentation. And rather than spend a huge amount of time on that I'm looking to see if anyone else has an interest in this. -Gary- -- ------------------ powellg(a)gmail.com "Come gather 'round people wherever you roam. And admit that the waters around you have grown. And accept it that soon you'll be drenched to the bone. If your time to you is worth savin'. Ahh you better start swimmin' or you'll sink like a stone. For the times they are a-changin'" Bob Dylan

4 4

Integrating CUDA nvcc into bjam
by jombi01821 21 Jun '12

21 Jun '12

I would like to know how to take an existing project that build with bjam and have it understand how to handle .cu CUDA files -- View this message in context: http://boost.2283326.n4.nabble.com/Integrating-CUDA-nvcc-into-bjam-tp463163… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50] Is it too late for fixes?
by John Maddock 21 Jun '12

21 Jun '12

I have a trivial fix for 1.50 if it's not too late (missing include guards on a header), see https://svn.boost.org/trac/boost/ticket/7001 Is it too late now, suspect it is? Thanks, John.

1 0

[exception] gcc 4.7 non-virtual destructor warning
by Daniel Larimer 21 Jun '12

21 Jun '12

/usr/local/include/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] Is there a reason why the destructor isn't virtual? This only shows up when I compile with -Wall, which I like to do because it catches many important errors. Unfortunately, if I have to filter out boost warnings it makes it less effective.. particularly when the warning is actually about 30 lines long in my console. Dan

3 3

[release] merge request for test fix
by Jürgen Hunold 20 Jun '12

20 Jun '12

Hi, I would like to merge r78972 to the release branch. It fixes some test failures introduced by 78802 which renamed UTC_TIME to UTC_TIME_. Trunk tests have cycled for 2 days and the interprocress results start to turn green. 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 ! Germany

2 2

hex/unhex()?
by Olaf van der Spek 19 Jun '12

19 Jun '12

Hi, Does Boost have hex/unhex() that support std::string? I can't find them and I think they'd be quite handy to have. -- Olaf

7 35

[svn] post commit hooks broken
by Jürgen Hunold 19 Jun '12

19 Jun '12

Hi, the subversion post commit hooks seem to be broken. The last commit mail I got is Author: garcia Date: 2012-06-07 16:20:43 EDT (Thu, 07 Jun 2012) New Revision: 78856 and there habe been numerous commits since. I have also checked in a followoup to r78802 yesterday, which should have triggered an automated trac entry for #6940. But nothing happens. Can someone with enough karma please take a look at this? As a sidenote: The inofficial git mirror seems stalled, too. 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 ! Germany

2 2

[Locale] VC11 Regressions
by Joshua Boyce 18 Jun '12

18 Jun '12

I am currently porting some code to the VC11 compiler beta, and as part of that process I ran the unit tests on the libraries I use and noticed some failures in Boost.Locale under VC11 that are not present under VC10. Ones of the tests (test_winapi_collate) actually crashes (showing the WER dialog etc). Logs for comparison (tests were run on trunk): http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc10-20120330-2143… http://dl.dropbox.com/u/74751/cpp/boost/logs/locale-test-vc11-20120330-2143… Has anyone else observed this or is it a configuration issue on my end?

4 11

Multiprecision vs. xint
by Phil Endecott 18 Jun '12

18 Jun '12

Dear All, I'd like to encourage people who are looking at the proposed Multiprecision library to remind themselves of the xint review last year. See e.g. http://thread.gmane.org/gmane.comp.lib.boost.devel/218624 (result) http://thread.gmane.org/gmane.comp.lib.boost.devel/215968 (my review) etc. etc. To what extent do we believe that this new library addresses the weaknesses of the last proposal? It would be great if Vladimir Prus, review manager for xint, could write a review of Multiprecision. Here's my take on it: Multiprecision addresses many of the problems of xint, and also extends the scope into areas that xint did not address at all. However it still suffers some of the same problems: if I want an int128_t that is just 128 bits of data, it doesn't help me. Furthermore, it doesn't help me to build the int128_t that I want. Although Multiprecision is divided into "front" and "back"-ends, this division is not in the right place to let me substitute my own backend that just provides the 128 bits of storage. In the xint reviews, we suggested that the algorithms should be decoupled from the data structures and the same applies here. Similarly, this implementation doesn't provide hooks that would allow me to substitute e.g. assembler implementations of the algorithms. Regards, Phil.

5 9

Re: [boost] Formal Review Request: TypeErasure
by Daniel Larimer 18 Jun '12

18 Jun '12

On Jun 8, 2012, at 9:47 AM, Hite, Christopher wrote: >> >> In a nutshell, concept-based-runtime-polymorphism/type-erasure allows you to have runtime polymorphism while preserving value semantics. The value of that win is very commonly underestimated. > > I think you're overselling it a bit here. You can have value sematics with interfaces, just pass around these and heap all the time in clone and maintain single points of ownership or shared_ptr. It has about the same cost as boost::function. > > struct interface{ > virtual ~interface()=0; > virtual interface* clone()=0; > }; > > > To be fair consider the version of any<..,_self&> which doesn't tackle storage and ownership and compare that with an interface with virtual functions. With the any<...,_self&> I've got a virtual table pointer and a pointer to the type-deleted object. With interface& I've got a pointer to an object with a virtual table intruding into it. I suspect that you could achieve generic 'value semantics' for any pure virtual interface via a very simple macro + other C++11 features. I think the cost of making a call with the following code would be the same as using pointer semantics via a virtual call. Consider the following to define value semantics for my_interface: class my_interface { public: virtual ~my_interface() {}; virtual int add( int ) = 0; virtual int add( double, std::string ) = 0; virtual int sub( int ) = 0; }; BOOST_VALUE( my_interface, (add)(sub) ) struct test : virtual public my_interface { int add( int i ) { return i + 5; } int add( double, std::string ) { return 6; } int sub( int i ) { return i - 5; } }; int main( int argc, char** argv ) { value<my_interface> v; v = test(); std::cerr<<v.add(int(5))<<" == 10\n"; std::cerr<<v.add(double(5.5), "hello")<<" == 6\n"; std::cerr<<v.sub(int(5))<<" == 0\n"; return 0; } The macro would expand to: template<> struct value<my_interface> : public value_base<my_interface> { using value_base<my_interface>::value_base<my_interface>; using value_base<my_interface>::operator=; // this is what the macro would most expand template<typename... Args> auto add(Args&&... args) -> decltype( ((my_interface*)0)->add( std::forward<Args>(args)... ) ) { return impl->add( std::forward<Args>(args)... ); } // this is what the macro would most expand template<typename... Args> auto sub(Args&&... args) -> decltype( ((my_interface*)0)->sub( std::forward<Args>(args)... ) ) { return impl->sub( std::forward<Args>(args)... ); } }; Granted the 'only' downside to this approach is that it is 'intrusive'. I have implemented as much here: https://github.com/bytemaster/mace/blob/master/libs/stub/examples/value.cpp You can achieve non-intrusive version with a slightly more verbose interface definition: template<typename T=void,bool impl=false> struct my_interface{ virtual ~my_interface() {} virtual int add( int ) = 0; virtual int add( double, std::string ) = 0; virtual int sub( int ) = 0; }; template<typename T> struct my_interface<T,true> : public T, virtual public my_interface<>{ template<typename... Args> my_interface(Args&& ...args):T( std::forward<Args>(args)... ){} virtual int add( int i) { return T::add(i); } virtual int add( double d, std::string s) { return T::add( d, s); } virtual int sub( int i) { return T::sub( i ); } }; BOOST_VALUE( my_interface, (add)(sub) ) struct test { /** no intrusive base class required **/ int add( int i ) { return i + 5; } int add( double, std::string ) { return 6; } int sub( int i ) { return i - 5; } }; int main( int argc, char** argv ) { value<my_interface> v; v = test(); std::cerr<<v.add(int(5))<<" == 10\n"; std::cerr<<v.add(double(5.5), "hello")<<" == 6\n"; std::cerr<<v.sub(int(5))<<" == 0\n"; return 0; } https://github.com/bytemaster/mace/blob/master/libs/stub/examples/value2.cpp Other than the repetitive nature of the interface spec, it is very straight forward, clear, and easy to read and understand compared to how TypeErasure currently achieves such a feat. Does this have value?? Could you integrate this technique with TypeErasure? Is it good enough for most use cases (non operator overloading)? It probably wouldn't be difficult to convert this to reference semantics and avoid heap alloc!

6 8

Review Wizard Report for June 2012
by Ronald Garcia 18 Jun '12

18 Jun '12

============================================== Review Wizard Status Report for June 2012 ============================================== News ==== 1. Predef Library Reviewed 2. Boost 1.49.0 Released. New Library: Heaps 3. Multiprecision Arithmetic Review Ongoing Open Issues =========== The following libraries have been reviewed and await reports from their review managers: * Predef - reviewed February 2012; review manager: Joel Falcou. * Conversion - reviewed August 2011; review manager: Gordon Woodhull. The following libraries have been accepted to Boost, but have not yet been submitted to SVN: * Constrained Value - accepted September 2010; author: Robert Kawulak. * GIL.IO - accepted January 2011; author: Christian Henning. * Atomic - accepted July 2011; author Helge Bahmann. * Lockfree - accepted August 2011; author: Tim Blechmann. The following libraries have been accepted and submitted to SVN, but have not yet appeared in a release: * Type Traits Introspection - accepted August 2011; author: Edward Diener. * Context - accepted January 2012; author: Oliver Kowalke. The following libraries have been accepted provisionally to Boost, but have not been submitted for mini-review and full acceptance: * Endian - accepted provisionally November 2011; author: Beman Dawes. * Log - accepted provisionally March 2010; author: Andrey Semashev. General Announcements ===================== As always, we need experienced review managers. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants, including library contributors, infrastructure contributors, and other mailing list participants with a substantial track record of constructive participation. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "rxg at cs dot cmu dot edu" and "phillips at pacific dot mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. If you are interested in reviewing a library but won't have time during the review period, you can always prepare your review ahead of time. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. The review schedule is an unordered list of the libraries awaiting review. As such, any library on the schedule can be reviewed once the developer is ready, a review manager has been secured, and the manager, developer, and wizards agree on a date to schedule the review. Review Schedule =============== * Join (M) * Pimpl (M) * Sorting (M) * Quaternions, Vectors, Matrices (M) * Variadic Macro Data (M) * Block Pointer (M) * Singularity (M) * Extended Complex Numbers (M) * Metaparse (M) * Polygon: Voronoi Extensions * Coroutine * Type Erasure * Range Extensions (M) * Contract * Nowide (M) ``(M)`` marks libraries that need review managers. -------------------- Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: https://github.com/boost-vault/Miscellaneous/blob/master/Pimpl.zip :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: https://github.com/boost-vault/Sorting :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 2X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 70% faster than std::sort. string_sort is roughly 2X as fast as std::sort. Quaternions, Vectors, Matrices ------------------------------ :Author: Emil Dotchevski :Review Manager: Needed :Download: http://www.revergestudios.com/boost-qvm/ :Description: QVM defines a set of generic functions and operator overloads for working with quaternions, vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the q_traits, v_traits and m_traits templates. Variadic Macro Data ------------------- :Author: Edward Diener :Review Manager: Needed :Download: `Boost Sandbox <http://svn.boost.org/svn/boost/sandbox/variadic_macro_data/>`__ :Description: This library adds support and functionality for variadic macros to Boost as well as integrating variadic macros with the Boost PP library without changing the latter library in any way. Block Pointer ------------- :Author: Phil Bouchard :Review Manager: Needed :Download: https://svn.boost.org/svn/boost/sandbox/block_ptr/ :Description: Deterministic memory manager of constant complexity capable of handling cyclic collections. Singularity ----------- :Author: Ben Robinson :Review Manager: Needed :Download: https://github.com/icaretaker/Singularity :Description: The Singularity Design Pattern allows you to restrict any class to a single instance. Unlike the infamous Singleton, Singularity gives you direct control over the lifetime of the object, does not require you to grant global access to the object, nor does it limit you to the default constructor for that object. Extended Complex Numbers ------------------------ :Author: Matthieu Schaller :Review Manager: Needed :Download: http://code.google.com/p/cpp-imaginary-numbers/ :Description: The library is an extension of the std::complex class addressing two issues: 1. The standard does not guaranty the behaviour of the complex class if instantiated with types other than float/double/long double. 2. 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) Metaparse --------- :Author: Abel Sinkovics :Review Manager: Needed :Download: http://abel.web.elte.hu/metaparse/metaparse.zip :Description: Metaparse is a library for constructing parsers parsing at compile-time based on template metaprogramming. The parsers built with the library take boost::mpl::strings as input and can produce - types - objects (types with public static members) - callable C++ functions (types with public static method) - template metafunction classes as output (based on the input being parsed). On compilers supporting constexpr the library provides the following syntactic sugar for writing the input of the parsers: BOOST_STRING("this is a string") The library can be used for implementing DSLs in C++, including DSLs making C++ template metaprogramming easier (see examples). Polygon: Voronoi Extensions --------------------------- :Author: Andril Sydorchuk :Review Manager: Lucanus Simonson :Download: http://svn.boost.org/svn/boost/sandbox/gtl/ :Description: This library extends Boost.Polygon with the following features: - Robust and efficient implementation of the sweepline algorithm that allows to construct Voronoi diagram, Delaunay triangulation and medial axis of a set of points and line segments. - Coordinates of the output geometries are computed within the 64 machine epsilon relative error (6 mantissa bits). - Voronoi diagram data structure that allows efficient traversal and data association with the output Voronoi graph. - No 3rd party dependencies (e.g. GMP, MPFR), all the required multiple precision types are implemented as part of the library. - The input and output coordinate type domains are configurable via coordinate type traits, thus allowing to compute coordinates of the Voronoi vertices within any required precision. - The full construction of the Voronoi diagram of 100 000 points takes only 0.27 seconds (see benchmarks). Coroutine --------- :Author: Oliver Kowalke :Review Manager: Hartmut Kaiser :Download: http://gitorious.org/boost-dev/boost-dev/archive-tarball/coroutine :Description: This library is an implementation of coroutines and generators using Boost.Context. Type Erasure ------------ :Author: Steven Watanabe :Review Manager: Lorenzo Caminiti :Download: http://sourceforge.net/projects/steven-watanabe.u/files/ :Description: The TypeErasure library is a generalization of boost::any and boost::function. It allows easy composition of arbitrary type erased operators. Range Extensions ---------------- :Author: Akira Takahashi :Review Manager: Neil Groves :Download: https://github.com/faithandbrave/OvenToBoost :Description: This project adds some features of the Oven Range Library to Boost.Range. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Contract -------- :Author: Lorenzo Caminiti :Review Manager: Dave Abrahams :Download: http://sourceforge.net/projects/contractpp/files/latest/download :Description: This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Nowide ------ :Author: Artyom Beilis :Review Manager: Needed :Download: http://cppcms.com/files/nowide/ :Description: This library makes cross platform Unicode aware programming easier. It provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Libraries under development =========================== See http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction for a current listing of libraries under development.

3 2

[pool] Improvements to boost.pool
by DUPUIS Etienne 18 Jun '12

18 Jun '12

Greetings, In the boost sandbox, under the /pool folder, I have committed a few small improvements and a few fixes for open tickets. Here is what I have changed : 1. I added boost::static_pool, a pool whose maximum size is known when initializing the pool; in which case all memory is allocated when calling the constructor. This is useful for software that must manage memory with great care. The implementation is a simple subclass of boost::pool. In the same vein, I also added boost::static_object_pool. 2. I also added boost::array_pool, a pool whose maximum size is known at compile time. The array_pool object hence already contains all memory it needs. Same for boost::array_object_pool. I am not sure that this is really useful and I am not sure I have picked a good name for it. 3. I handled ticket #3789 (https://svn.boost.org/trac/boost/ticket/3789) In short, releasing objects from a boost::object_pool was O(n) instead of expected O(1) and this constraint was required to keep the pool ordered so that the destructor of object_pool could destroy all objects that the calling program did not released. To solve this problem, I created an O(n log n) function which orders an unordered pool, a function that I called in the destructor. Thus, with my modification, releasing objects is O(1) and the destructor is O(n log n), or O(1) is the calling program was kind enough to release all objects. Although this does not change the API, it could have a negative impact on software that allocate large number of objects (using object_pool) but that never releases them. However, my modification greatly improves programs who repeatedly requests and releases objects. This modification also handles ticket #6610 (https://svn.boost.org/trac/boost/ticket/6610) 4. I added a pool.get_size() function (https://svn.boost.org/trac/boost/ticket/6865) that returns the current number of elements/objects for which the pool has allocated memory. 5. I clarified the meaning of the 'max_size' parameter, a recent addition to limit the amount of memory a pool can allocate with a single call to the allocator. See ticket #6867 (https://svn.boost.org/trac/boost/ticket/6867) for details. 6. I fixed miscellaneous minor tickets : #5902 (division by zero when requesting null sized buffers), #6561 (crash when releasing a null pointer), #6710 (integer overflows and possible crashes when requesting too many elements). 7. I added test cases for all modifications. I manually tested each case on Windows and used bjam on Linux, although I am not exactly sure that bjam did anything as it did not even report which test it ran. 8. I still need to update the documentation. Before doing that, I thought that I should submit my changes to the Boost community to see whether they are approved or not. And more prosaically, I still need to figure out how to generate the said documentation ! Now that these changes have been made in the sandbox, what is the next step to get them approved/amended/rejected ? Regards, Étienne 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.

5 6

Formal Review Request: Boost.Contract
by Lorenzo Caminiti 18 Jun '12

18 Jun '12

Hello all, I have released Contract++ 0.4.0 on SourceForge. If ever accepted into Boost, this library will be Boost.Contract (and all macros/symbols will be prefixed by BOOST_/boost::). This library implements Contract Programming for the C++ programming language (see the end of this email). In addition, the library implements virtual specifiers (final, override, and new, see C++11), concept checking, and named parameters. This library is implemented for the C++03 standard and it does not require C++11. Documentation: http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… Source: http://sourceforge.net/projects/contractpp/files/latest/download I would like to request a formal Boost review of the library. Comments are welcome! Thanks, --Lorenzo INTRODUCTION Contract Programming is also known as Design by Contract(TM) and it was first introduced by the Eiffel programming language. All Contract Programming features of the Eiffel programming language are supported by this library, among others: * Support for preconditions, postconditions, class invariants, block invariants, and loop variants. * Subcontract derived classes (with support for pure virtual functions and multiple inheritance). * Access expression old values and function return value in postconditions. * Optional compilation and checking of preconditions, postconditions, class invariants, block invariants, and loop variants. * Customizable actions on contract assertion failure (terminate by default but it can throw, exit, etc). All features: http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… EXAMPLE The example below shows how to use this library to program contracts for the STL member function std::vector::push_back (in order to illustrate subcontracting, the vector class inherits from the somewhat arbitrary pushable base class). #include <contract.hpp> // This library. #include <boost/concept_check.hpp> #include <vector> #include "pushable.hpp" // Some base class. CONTRACT_CLASS( template( typename T ) requires( boost::CopyConstructible<T> ) // Concepts. class (vector) extends( public pushable<T> ) // Subcontracting. ) { CONTRACT_CLASS_INVARIANT_TPL( empty() == (size() == 0) // More class invariants here... ) public: typedef typename std::vector<T>::size_type size_type; public: typedef typename std::vector<T>::const_reference const_reference; CONTRACT_FUNCTION_TPL( public void (push_back) ( (T const&) value ) override precondition( size() < max_size() // More preconditions here... ) postcondition( auto old_size = CONTRACT_OLDOF size(), // Old-of values. size() == old_size + 1 // More postconditions here... ) ) { vector_.push_back(value); // Original function body. } // Rest of class here (possibly with more contracts)... public: bool empty ( void ) const { return vector_.empty(); } public: size_type size ( void ) const { return vector_.size(); } public: size_type max_size ( void ) const { return vector_.max_size(); } public: const_reference back ( void ) const { return vector_.back(); } private: std::vector<T> vector_; }; NOTES This library suffers of two limitations: 1. The unusual syntax used to declare classes and functions within the macros which causes cryptic compiler errors when not used correctly (syntax error checking and reporting could be somewhat improved in future revisions of the library but there are fundamental limitations on what can be done using the preprocessor). http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… 2. High compilation times (the authors have not tried to optimize the library proprocessor and template meta-programming code yet, that will be the focus of future releases). http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp… This library could be extended to also support concept definitions (at least for C++11): http://contractpp.svn.sourceforge.net/viewvc/contractpp/releases/contractpp…

2 4

rvalue ref best practices?
by Daniel Larimer 17 Jun '12

17 Jun '12

I am trying to define my library API and have been using rvalue references and have observed some patterns that I would like to run by the community. In c++03 I would pass almost everything by const& unless it was to be modified. This results in extra copies any time a temporary is passed. In c++11 I would pass anything that I plan on 'storing' or 'consuming' by &&. This results in the most efficient code, but 'breaks' lvalue compatibility and forces me to consider having two (or more) versions of every method. Unfortunately, you get a explosion of permutations of rvalue and const& as the number of arguments increases and it makes getting function pointers much more 'ugly'. Instead of providing two (or more) overloads, one for lvalues and one for rvalue, I have decided to only provide the rvalue overload and if the user wants to pass an lvalue they wrap with std::ref(), std::cref(), std::move() or my own helper copy() which makes the copy explicit and converts the lvalue to a rvalue. (std::ref() and std::cref() could only work if the arguments are template parameters... in which case the method would probably use std::forward<>() to handle the auto-detection of move vs copy semantics. template<typename T> T copy( const T& v ) { return v; } If I am writing a method that does not 'store' or 'consume' the input then I use const& As rvalue references are quite new, this 'convention' may be unexpected by users. How would you feel about using an API that assumed move semantics unless you explicitly specify copy or reference semantics? Is there any reason that there shouldn't be a boost::copy() in boost/utility for use in this situation? Are there some down sides to this approach that I am missing? In my experience 90% of functions that take std::string() end up using a temporary and 90% of strings are 'calculated', 'used', and 'forgotten', yet most methods take const& and result in a temporary value. I should probably clarify, that I would use const& for any types that do not benefit from move semantics (no deep copies). But when you are writing template code, you do not want to make that assumption about the type. Another practice I am considering is making certain classes 'explicit copy only'. template<typename T> T copy( const T& t ) { return t; } class test { public: test(){...}; test( test&& t ){...} private: template<typename T> friend T copy(const T&t); test& operator=(const test&); // not implemented test( const test& t ){...} std::vector<char> large_data; }; int main( int argc, char** argv ) { test x; test y = copy(x); test z = x; // error, test(const test&) is private... return 0; } I would use this for any class that contains any 'movable members', such a strings, vectors, maps, etc. Technically there is no reason why I couldn't copy them, but why shouldn't I attempt move semantics everywhere possible unless I really do want to copy? With implicit copies there is no way for the compiler to warn me that I am doing something potentially expensive. If it didn't break backward compatibility I would suggest that all of the standard containers adopt an explicit copy or move syntax or at least have a compiler flag to 'enable/disable' implicit copying for 'testing purposes'. Perhaps we could put them in a different namespace for those of us that want to disable implicit copying of deep data types, ie: xc::vector<>, xc::string, etc. Are these sane conventions? What could go wrong? I am I abusing rvalue references?

13 54

Result of boost::split against empty string changed in post-1.45 release
by Mateusz Loskot 17 Jun '12

17 Jun '12

Hi, I have a simple program runs boost::split against empty string. I'm testing with Boost 1.45 and later versions like 1.46 or 1.49. As stated in the // comment below, there is difference in behaviour depending on the Boost version: // https://gist.github.com/2910461 #include <cassert> #include <string> #include <vector> #include <boost/algorithm/string/split.hpp> #include <boost/algorithm/string/classification.hpp> int main(int argc, wchar_t* argv[]) { std::wstring s; std::vector<std::wstring> a; assert(s.empty()); boost::split(a, s, boost::is_any_of(L", "), boost::token_compress_on); // Boost 1.45: true // Boost 1.46+: false // Assertion failed: s.empty() == a.empty(), file boost_split_empty_string.cpp, line 16 assert(s.empty() == a.empty()); return 0; } IMHO, the behaviour exposed in newer versions is a bug. Could anyone shed light on what happened in post-1.46? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

4 11

[context] build and warning fixes for gcc on Windows
by news.gmane.org 16 Jun '12

16 Jun '12

Hello Posting here as there's no context component in trac yet. This specifically relates to boost.context and cygwin's mingw64-x64_64_gcc toolchain with ml and ml64 from Visual Studio 2010. The patch attached is against trunk (rev 78752) for the following warnings: * ..\..\../boost/context/detail/fcontext_x86_64_win.hpp:20:0: warning: ignoring #pragma warning * ..\src\seh.cpp:36:87: warning: format %08lX expects type long unsigned int, but argument 5 has type ULONG_PTR (I'm guessing %p used in the patch is probably not the best solution for cross-platformness) * ..\src\seh.cpp:39:53: warning: deprecated conversion from string constant to char* The last issue I've had is with jump_fcontext and make_fcontext exports: Warning: .drectve `/EXPORT:jump_fcontext /EXPORT:make_fcontext 3' unrecognized Which seems to cause: collect2: ld terminated with signal 6 [Aborted], core dumped Removing the EXPORT directive in the asm file results in a successful build, but naturally the symbols aren't exported. I hacked around this by changing the asm functions to jump_fcontext_impl and make_fcontext_impl, and provided an extern C jump_fcontext and make_fcontext in fcontext.cpp that forward to them. I'm sure there are far nicer ways to force the symbols to be exported so I've not attached the patch for this. With these changes, I can more-or-less successfully use context which is great! (A slight issue with exceptions; possibly crossing dll boundaries and/or due to this gcc's exception implementation using setjmp/longjmp.) Finally, is there any technical reason why gas assembly couldn't be provided for use with gcc on Windows? Having to have masm available seems a shame, aside from the issues above. I had a very quick go at it without success but could possibly have another attempt ... Thanks for the library and regards, Luke Elliott.

3 7

Fwd: [Boost-users] [filesystem] is path comparison case-insensitive on Windows?
by Mateusz Loskot 15 Jun '12

15 Jun '12

Hi, I wonder, would it be possible for authors of Boost.Filesystem to provide clear answer to this question in the FAQ [1]? It seems to be a good candidate for FAQ. [1] http://www.boost.org/doc/libs/1_49_0/libs/filesystem/v3/doc/faq.htm Mateusz ---------- Forwarded message ---------- From: Nathan Ridge <zeratul976(a)hotmail.com> Date: 15 June 2012 07:12 Subject: [Boost-users] [filesystem] is path comparison case-insensitive on Windows? To: Boost Mailing List <boost-users(a)lists.boost.org> Hi, I couldn't find this info in the Filesystem documentation, so I thought I'd ask here: is equality comparison between path objects case-insensitive on Windows? I think it ought to be, since the operating system treats two paths differing by case only to be the same, but I thought I'd double-check. Thanks, Nate _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Multiprecision] Benchmarking
by Phil Endecott 15 Jun '12

15 Jun '12

Dear All, I have attempted to evaluate the proposed multiprecision library by applying it to the "Dealaunay Flip" function for 32-bit integer coordinates, as this is one of the few things that I've ever implemented that needed more than 64-bit integers: inline bool delaunay_test(int32_t ax, int32_t ay, int32_t bx, int32_t by, int32_t cx, int32_t cy, int32_t dx, int32_t dy) { // Test whether the quadrilateral ABCD's diagonal AC should be flipped to BD. // This is the Cline & Renka method. // Flip if the sum of the angles ABC and CDA is greater than 180 degrees. // Equivalently, flip if sin(ABC + CDA) < 0. // Trig identity: cos(ABC) * sin(CDA) + sin(ABC) * cos(CDA) < 0 // We can use scalar and vector products to find sin and cos, and simplify // to the following code. // Numerical robustness is important. This code addresses it by performing // exact calculations with large integer types. i64 ax64 = ax, ay64 = ay, bx64 = bx, by64 = by, cx64 = cx, cy64 = cy, dx64 = dx, dy64 = dy; i64 cos_abc = (ax64-bx64)*(cx64-bx64) + (ay64-by64)*(cy64-by64); i64 cos_cda = (cx64-dx64)*(ax64-dx64) + (cy64-dy64)*(ay64-dy64); if (cos_abc >= 0 && cos_cda >= 0) return false; if (cos_abc < 0 && cos_cda < 0) return true; i64 sin_abc = (ax64-bx64)*(cy64-by64) - (cx64-bx64)*(ay64-by64); i64 sin_cda = (cx64-dx64)*(ay64-dy64) - (ax64-dx64)*(cy64-dy64); i128 sin_sum = static_cast<i128>(sin_abc)*cos_cda + static_cast<i128>(cos_abc)*sin_cda; return sin_sum < 0; } As you can see, with 32-bit inputs, the first set of computations yield 64-bit results and about half of calls terminate at this stage. Otherwise a calculation yielding a 128-bit result is carried out. In practice, the results of the subtractions are typically small and the 128-bit value rarely has more than 64 significant bits. I have compared the following types used for i64 and i128 in the code above: (1) int64_t and int64_t (which gives WRONG ANSWERS, but is useful for comparison) (2) int64_t and my own "quick and dirty" int128_t. (3) cpp_int. (4) int64_t and cpp_int. (5) cpp_int without expression templates. (6) int64_t and cpp_int without expression templates. (7) int64_t and mp_int128_t. (8) mpz_int. (9) int64_t and mpz_int. Mean times per function call are as follows: (1) 39.3 ns (2) 61.9 ns (3) 513 ns (4) 103 ns (5) 446 ns (6) 102 ns (7) 102 ns (8) 2500 ns (9) 680 ns (AMD Athlon(tm) II X2 250e Processor @ 3 GHz; g++ 4.6.1.) Note that: - GMP is slowest, despite oft-repeated claims about its good performance. - Expression templates make the code slower. - Even the fastest Boost.Multiprecision type, mp_int128_t, is significantly slower than my own quick hack. This is all a bit disappointing. Perhaps the problem is that I'm dealing only with 128 bits and the intended application is for much larger values? I am reminded of my experience with xint last year. See e.g. this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/215565 The current proposal seems much better - xint was hundreds of times slower than my ad-hoc code - but I still find it discouraging. I suspect that the performance difference may be attributable to the use of sign-magnitude representation; as a result, the implementation is full of sign-testing like this: template <unsigned MinBits, bool Signed, class Allocator> inline void eval_subtract(cpp_int_backend<MinBits, Signed, Allocator>& result, const signed_limb_type& o) { if(o) { if(o < 0) eval_add(result, static_cast<limb_type>(-o)); else eval_subtract(result, static_cast<limb_type>(o)); } } I think I understand the motivation for sign-magnitude for variable-length representation, but I don't see any benefit in the case of e.g. mp_int128_t. I also wonder about the work involved in e.g. a 64 x 64 -> 128-bit multiplication. Here is my version, based on 32x32->64 multiplies: inline int128_t mult_64x64_to_128(int64_t a, int64_t b) { // Make life simple by dealing only with positive numbers: bool neg = false; if (a<0) { neg = !neg; a = -a; } if (b<0) { neg = !neg; b = -b; } // Divide input into 32-bit halves: uint32_t ah = a >> 32; uint32_t al = a & 0xffffffff; uint32_t bh = b >> 32; uint32_t bl = b & 0xffffffff; // Long multiplication, with 64-bit temporaries: // ah al // * bh bl // ---------------- // al*bl (t1) // + ah*bl (t2) // + al*bh (t3) // + ah*bh (t4) // ---------------- uint64_t t1 = static_cast<uint64_t>(al)*bl; uint64_t t2 = static_cast<uint64_t>(ah)*bl; uint64_t t3 = static_cast<uint64_t>(al)*bh; uint64_t t4 = static_cast<uint64_t>(ah)*bh; int128_t r(t1); r.high = t4; r += int128_t(t2) << 32; r += int128_t(t3) << 32; if (neg) r = -r; return r; } So I need 4 32x32->64 multiplies to perform 1 64x64->128 multiply. But we can't write this: int64_t a, b ...; int128_t r = a * b; because here a*b is a 64x64->64 multiply; instead we have to write something like r = static_cast<int128_t>(a)*b; so that our operator* overload is found; but this operator* doesn't know that its int128_t argument is actually a promoted int64_t, and it has to do an 128x64->128 or 128x128->128 multiply, requiring 8 or 16 32x32->64 multiplies. The only chance of avoiding the extra work is if the compiler can do constant-propagation, but I have my doubts about that. Any thoughts? My test code is here: http://chezphil.org/tmp/boost_mp_review.tbz2 $ make $ cat nn100000.dat | benchmark (Note that this needs a fix to the resize() issue reported earlier in order to get accurate answers, but that doesn't much alter the execution time.) Regards, Phil.

8 15

help
by Bertolino, Keith D. 15 Jun '12

15 Jun '12

unsubscribe

1 0

[multiprecision review] Possible use of uninitialised value
by Phil Endecott 14 Jun '12

14 Jun '12

Dear All, I decided to try to evaluate the proposed Boost.Multiprecision on the code that I wrote recently when looking at the proposed Delaunay Triangulation / Voronoi Diagram code. Specifically, this function: inline bool delaunay_test(int32_t ax, int32_t ay, int32_t bx, int32_t by, int32_t cx, int32_t cy, int32_t dx, int32_t dy) { // Test whether the quadrilateral ABCD's diagonal AC should be flipped to BD. // This is the Cline & Renka method. // Flip if the sum of the angles ABC and CDA is greater than 180 degrees. // Equivalently, flip if sin(ABC + CDA) < 0. // Trig identity: cos(ABC) * sin(CDA) + sin(ABC) * cos(CDA) < 0 // We can use scalar and vector products to find sin and cos, and simplify // to the following code. // Numerical robustness is important. This code addresses it by performing // exact calculations with large integer types. i64 ax64 = ax, ay64 = ay, bx64 = bx, by64 = by, cx64 = cx, cy64 = cy, dx64 = dx, dy64 = dy; i64 cos_abc = (ax64-bx64)*(cx64-bx64) + (ay64-by64)*(cy64-by64); i64 cos_cda = (cx64-dx64)*(ax64-dx64) + (cy64-dy64)*(ay64-dy64); if (cos_abc >= 0 && cos_cda >= 0) return false; if (cos_abc < 0 && cos_cda < 0) return true; i64 sin_abc = (ax64-bx64)*(cy64-by64) - (cx64-bx64)*(ay64-by64); i64 sin_cda = (cx64-dx64)*(ay64-dy64) - (ax64-dx64)*(cy64-dy64); i128 sin_sum = static_cast<i128>(sin_abc)*cos_cda + static_cast<i128>(cos_abc)*sin_cda; return sin_sum < 0; } Here i64 and i128 are typedefs for appropriate 64- and 128-bit signed integer types. when I try to use boost::multiprecision::cpp_int, I get answers that are only mostly correct. Specifically, sometimes the very first call gives the wrong answer. It is dependent on the number of iterations of my benchmark loop and other factors. valgrind reports the following: ==15713== Conditional jump or move depends on uninitialised value(s) ==15713== at 0x8053B0C: boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>::mp_number<boost::multiprecision::detail::plus, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, void, void>(boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::plus, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, boost::multiprecision::detail::mp_exp<boost::multiprecision::detail::multiply_immediates, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, boost::multiprecision::mp_number<boost::multiprecision::backends::cpp_int_backend<0u, true, std::allocator<unsigned int> >, true>, void, void>, void, void> const&) (in /home/phil/boost_mp_review/benchmark) As expected, the error is impenetrable. Can anyone guess what is going on? (I seem to get the right answers and no valgrind errors with the fixed-size and no-expression-templates types.) Regards, Phil.

2 3

[mpi] MPI_IN_PLACE equivalent
by Alain O Miniussi 14 Jun '12

14 Jun '12

Some collective mpi operations allow the user to re-use the input buffer as the output buffer (MPI_IN_PLACE). I did not find that functionality in boost::mpi and filed a ticket (https://svn.boost.org/trac/boost/ticket/6704) along with a patch for a possible implementation for all_reduce and the associated testing. What is the best way to get some input regarding that proposed patch ? (the ticket itself has been untouched for 3 months now) Best regards, -- Alain Miniussi Responsable Tech. Centre de Calcul Haute Performance Observatoire de la Côte d'Azur - BP 4229 - 06304 Nice Cedex 4 tel: +33 4 92 00 30 09 https://crimson.oca.eu

1 0

[multiprecision review] EOF not declared, and noexcept errors
by Phil Endecott 14 Jun '12

14 Jun '12

Dear All, I'm trying to do some simple tests with the proposed Boost.Multiprecision, but anything that includes e.g. boost/multiprecision/cpp_int.hpp gives errors like this: /big_number/boost/multiprecision/mp_number.hpp:1730:11: error: ‘EOF’ was not declared in this scope /big_number/boost/multiprecision/rational_adapter.hpp:208:45: error: expected ‘;’ at end of member declaration /big_number/boost/multiprecision/rational_adapter.hpp:208:47: error: ‘noexcept’ does not name a type My guess is that the EOF error may be a missing include, while the latter two errors may be something that's missing in the relatively old Boost installation on this test machine. Can anyone suggest what I need to do? Regards, Phil.

4 4

Cannot access structure elements using iterator to list containing shared_ptr<struct>
by Manjunath BJ 14 Jun '12

14 Jun '12

> > Hi, >> I would like to have a list(STL) of shared_ptr. The shared_ptr >> would hold the pointer to the structure "packet_holder" >> . >> > struct packet { > >> int c; >> union{ >> struct pkt_header header; >> struct ip_header ip_hd; >> }type; >> > }packet_holder; >> >> > list<boost::shared_ptr<packet_holder> > pkt_list; > boost::shared_ptr<packet_holder> pkt(new packet_holder); > pkt_list.push_pack(pkt); > > Having defined this, I would like to use iterator to iterate > through the list. > list<boost::shared_ptr<packet_holder> >::iterator it; > for(it = list.begin();it != list.end();it++) > But I am not able to access the inner details of the struct > "packet_holder" using the iterator. > it->type.header is not accessible. > > Can anyone please suggest me where exactly I might be wrong. > > -- >> With Regards, >> Manjunath BJ >> > > > > -- > With Regards, > Manjunath BJ > -- With Regards, Manjunath BJ

2 2

[test] max_digits10 code breaks regression testing for many older platforms
by David Deakins 13 Jun '12

13 Jun '12

Paul, I noticed that the change to set_precision in Boost.Test (rev 78908) seems to have broken regression testing on the trunk for all of the platforms that don't have max_digits10 in their standard library (even for non-math-related tests). Is there any way to restrict this new code to only platforms that can support it? Thanks, -Dave

1 0

Boost mpi, serialization and shared_ptr
by Max Moorkamp 13 Jun '12

13 Jun '12

Hi, I have started to parallelize one of my applications using MPI and I am running into trouble with serializing classes that contain shared_ptr member to be send through MPI. Below is a minimal case that demonstrates my problem. #include <boost/serialization/serialization.hpp> #include <boost/shared_ptr.hpp> #include <boost/mpi.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/serialization/export.hpp> class Base { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { } public: Base() { } virtual ~Base() { } }; class Derived: public Base { private: double b; boost::shared_ptr<Base> MemberPointer; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & boost::serialization::base_object<Base>(*this); ar & MemberPointer; ar & b; } public: Derived() { } virtual ~Derived() { } }; //BOOST_CLASS_EXPORT(Base) BOOST_CLASS_EXPORT(Derived) int main(int argc, char *argv[]) { boost::mpi::environment env(argc, argv); boost::mpi::communicator world; boost::shared_ptr<Base> Pointer(new Derived()); boost::mpi::broadcast(world, Pointer, 0); } I want to broadcast the derived class that has a member that is a shared_ptr. When I compile this code with gcc-4.6, intel or clang all compilers complain, this is the output from gcc-4.6 In file included from Hacks/serialization_mpi.cpp:11:0: /usr/local/include/boost/serialization/shared_ptr.hpp: In function ‘void boost::serialization::load(Archive&, boost::shared_ptr&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = Base]’: /usr/local/include/boost/serialization/split_free.hpp:58:9: instantiated from ‘static void boost::serialization::free_loader<Archive, T>::invoke(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ /usr/local/include/boost/serialization/split_free.hpp:74:5: instantiated from ‘void boost::serialization::split_free(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ /usr/local/include/boost/serialization/shared_ptr.hpp:171:5: instantiated from ‘void boost::serialization::serialize(Archive&, boost::shared_ptr&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = Base]’ /usr/local/include/boost/serialization/serialization.hpp:128:9: instantiated from ‘void boost::serialization::serialize_adl(Archive&, T&, unsigned int) [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ /usr/local/include/boost/archive/detail/iserializer.hpp:188:5: instantiated from ‘void boost::archive::detail::iserializer<Archive, T>::load_object_data(boost::archive::detail::basic_iarchive&, void*, unsigned int) const [with Archive = boost::mpi::packed_skeleton_iarchive, T = boost::shared_ptr<Base>]’ Hacks/serialization_mpi.cpp:64:3: instantiated from here /usr/local/include/boost/serialization/shared_ptr.hpp:133:9: error: ‘class boost::mpi::packed_skeleton_iarchive’ has no member named ‘append’ /usr/local/include/boost/serialization/shared_ptr.hpp:139:5: error: ‘class boost::mpi::packed_skeleton_iarchive’ has no member named ‘reset’ If I remove the shared_ptr member, it compiles and runs. If I remove BOOST_CLASS_EXPORT(Derived) it compiles, but when running it I get terminate called after throwing an instance of 'boost::archive::archive_exception' what(): unregistered class - derived class not registered or exported Is this a bug or am I doing something wrong? A google search shows an old discussion (2007) that concludes that this problem is fixed in boost 1.45. I see this happening with both 1.48 and 1.49. Any help is appreciated. Regards Max

3 6

[Nowide] Formal Review Request
by Artyom Beilis 13 Jun '12

13 Jun '12

Hello, I'd like to ask to add Boost.Nowide to review queue: Boost.Nowide is a library implemented by Artyom Beilis that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. Sources: http://cppcms.com/files/nowide/ Docs: http://cppcms.com/files/nowide/html/ Git: git://cppcms.git.sourceforge.net/gitroot/cppcms/nowide Thank You Very Much! Artyom Beilis P.S.: Previous mail was sent accidentally to boost.users list, sorry. -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

3 4

[pool] Broken documentation
by Klaim - Joël Lamotte 12 Jun '12

12 Jun '12

Hi, http://www.boost.org/doc/libs/1_49_0/libs/pool/doc/html/boost_pool/pool/poo… In this page all images are broken for me. Joel Lamotte

3 3

Review Request : Boost.Range Extension
by Akira Takahashi 11 Jun '12

11 Jun '12

Hi, Neil Groves and Boosters. OvenToBoost is a project that intend to add some features of Oven Range Library into Boost.Range. I'd like to request a review. Features: - Additional Range Adaptors (taken, taken_while, dropped, dropped_while, elements, elements_key, memoized, outdirected) - Extensions for using Lambda (regular function, regular operator) - Infinite Range (iteration function) - and additional range utilities. Future Plan: I have written primary features. If these features are accept, I'd like to implement/add following features: - Range of Range Adaptors (concatenated, transposed) - Cyclic Range - Range Utilities for String Source Code: https://github.com/faithandbrave/OvenToBoost Document: http://dl.dropbox.com/u/1682460/git/OvenToBoost/libs/range/doc/html/index.h… Regards, Akira >>======================== Akira Takahashi mailto:faithandbrave@gmail.com site: https://sites.google.com/site/faithandbrave/about/en

4 24

From an user to developers
by Oodini 10 Jun '12

10 Jun '12

Hello, I am an user, and I am currently reviewing all the Boost libraries. But for a common user, some needs are not satisfied in the libraries descriptions. The Boost organization should compel the libraries authors to put in their documentation : 1. the history of all releases, with notes for each release 2. the motivation of their library 3. when they offer services similar to the ones provided by the STL, why did they feel the need to complete it, and what are the differences 3. for the relevant libraries, their status regarding the new features of C++11 (are they obsolete ? do they remain some differences ? ex : Array, Chrono, DateTime), especially the ones related to TR1 An homogeneous structure for the documentation would be welcome.

5 6

[1.50] OK to merge documentation changes?
by John Maddock 10 Jun '12

10 Jun '12

I have some documentation changes that I'd like to merge: * Corrected typos in Boost.Math docs. * Updated some scripts and Jamfiles for correct PDF doc build generation. Is there a good time to commit these to release, or is it all to late for 1.50 now? Thanks, John.

2 1

[git/modularization] Suggested names for branches?
by Beman Dawes 10 Jun '12

10 Jun '12

At the C++Now! session discussing moving to git and modularization, I showed the usual git flow overview graphic from http://nvie.com/posts/a-successful-git-branching-model/ showing the workflow for a library. Someone (Dave?) mentioned that the git flow choices for branch names were not what we would like for Boost. I agree, but don't recall the exact suggestions for more appropriate names. The three branches in question, with the git-flow names in parens, were the main development branch (develop), release prep branches (?), and the branch with actual releases (master). Is there a better usual convention for these names? I have a vague memory of someone mentioning "master" for the main development branch, "release" for the branch with the actual releases, and maybe "beta-x.xx.x" for release prep branches. To try to avoid an extended bicycle shed discussion, perhaps people could mention names they have actually seen used and know worked well. --Beman

8 14

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by Marc Glisse 09 Jun '12

09 Jun '12

(sorry for the broken thread, I wasn't subscribed yet) A few quick comments: * gmpxx != mpfr_class * the version of gmpxx in the repository hasn't used any temporary for the example given in the introduction for a while, it is only because of a slow release cycle that you haven't seen it yet (will be in 5.1). * the example about using 0 vs 11 temporaries doesn't mention what happens to the boost package if we disable expression template. Does it use a single temporary (using rvalue-references) or plenty? * having an implicit narrowing conversion from double to bigint is a bad idea, it should be explicit (it isn't completely obvious from the doc if that is the case). * you could get good results with a backend that uses gmp's mpn_* functions but not the mpz_t type. * what about infinite precision floats? By that I mean something like bigint*2^n, where operations + - * are computed exactly. It can be quite a bit faster than rationals, when it is sufficient. * if I want reference-counting, I guess that should be done in a back-end. -- Marc Glisse

5 22

C++Now! keynote videos are available
by Marshall Clow 08 Jun '12

08 Jun '12

Howard's was not recorded Daveed: http://www.youtube.com/watch?v=8SOCYQ033K8 Sean: http://www.youtube.com/watch?v=iGenpw2NeKQ The full list of videos is at: http://www.youtube.com/user/BoostCon (more will be added soon) -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

basic information: code post
by Majid Qureshi 08 Jun '12

08 Jun '12

Hi I am new to boost mailing list. I am wondering if I wish to submit my template class for review to be added as part of boost library, what do I need to do? and please advise if I am not suppose to send email to this mailing list for any such proposal. Also what mailing list do I need to send such emails? Very much appreciated.Thanks

2 1

[Who's using boost?] Sankel Software
by David Sankel 08 Jun '12

08 Jun '12

Sankel Software Sankel Software has been using boost for over 10 years to develop high performance and customized CAD/CAM applications, industrial control, computer artistry, and business software. If it wasn't for Boost, we would have stopped using C++ long ago. Its libraries allow us to write more concise code and, more importantly, give us the tools to implement higher level constructs such as denotational semantics based, top-down program design. Home Page: http://sankelsoftware.com Here is a list of the libraries we currently use: - Boost.Any - Boost.Serialization - Boost.Array - Boost.Assign - Boost.Bind - Boost.Integer - Boost.DateTime - Boost.Foreach - Boost.Function - Boost.Fusion - Boost.Variant - Boost.Optional - Boost.LexicalCast - Boost.SmartPtr - Boost.Math - Boost.MPL - Boost.MultiIndex - Boost.Operators - Boost.Signals2 - Boost.Thread - Boost.Tuple - Boost.TypeTraits - Boost.Utility - David -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

1 0

[1.50.0] Release branch open for bug fixes and doc updates
by Beman Dawes 07 Jun '12

07 Jun '12

The final release is scheduled for Monday, June 25th. The release candidate is scheduled to to be built Thursday, June 21st. That gives us two weeks to apply post-beta bug fixes and doc updates. Let's try a slightly more streamlined procedure for this post-beta period; until Monday, June 18th permission is not required to merge bug fixes and documentation updates. Starting June 18th 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, --Beman

2 1

[1.50] Can't build quickbook PDF docs.
by John Maddock 07 Jun '12

07 Jun '12

Just a note that the quickbook docs don't build as a PDF due to XML validation failures at the FO stage: fop.render.pdf ..\..\bin.v2\tools\quickbook\doc\msvc-10.0\debug\link-static\threading-multi\quickbook.pdf M:/download/programs/xep/xep.bat ..\..\bin.v2\tools\quickbook\doc\msvc-10.0\debug\link-static\threading-multi\quickbook.fo ..\..\bin.v2\tools\quickbook\doc\msvc-10.0\debug\link-static\threading-multi\quickbook.pdf (document [system-id file:/M:/data/boost/branches/release/doc/pdf/../../bin.v2/tools/quickbook/doc/msvc-10.0/debug/link-static/threading-multi/quickbook.fo] (validate [error] Element 'fo:block' cannot be a child of 'fo:root'. [error] Element 'fo:block' cannot be a child of 'fo:root'. [error] Element 'fo:block' cannot be a child of 'fo:root'. [error] Attribute 'space-before.optimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.minimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.maximum' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:inline'. [error] Attribute 'break-before' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:block'. [error] Attribute 'margin-left' cannot occur at element 'fo:block'. [error] Attribute 'font-family' cannot occur at element 'fo:block'. [error] Attribute 'keep-together.within-column' cannot occur at element 'fo:block'. [error] Attribute 'keep-with-next.within-column' cannot occur at element 'fo:block'. [error] Attribute 'font-family' cannot occur at element 'fo:block'. [error] Attribute 'font-weight' cannot occur at element 'fo:block'. [error] Attribute 'keep-with-next.within-column' cannot occur at element 'fo:block'. [error] Attribute 'space-before.minimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.optimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.maximum' cannot occur at element 'fo:block'. [error] Attribute 'text-align' cannot occur at element 'fo:block'. [error] Attribute 'start-indent' cannot occur at element 'fo:block'. [error] Attribute 'marker-class-name' cannot occur at element 'fo:marker'. [error] Element 'fo:marker' should be a descendant of 'flow'. [error] Attribute 'font-size' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:inline'. [error] Attribute 'internal-destination' cannot occur at element 'fo:basic-link'. [error] Attribute 'color' cannot occur at element 'fo:inline'. [error] Attribute 'space-before.optimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.minimum' cannot occur at element 'fo:block'. [error] Attribute 'space-before.maximum' cannot occur at element 'fo:block'. [error] Attribute 'id' cannot occur at element 'fo:block'. [error] Attribute 'border-color' cannot occur at element 'fo:block'. [error] Attribute 'border-width' cannot occur at element 'fo:block'. [error] Attribute 'border-style' cannot occur at element 'fo:block'. [error] Attribute 'padding-left' cannot occur at element 'fo:block'. [error] Attribute 'padding-right' cannot occur at element 'fo:block'. [error] Attribute 'padding-top' cannot occur at element 'fo:block'. [error] Attribute 'padding-bottom' cannot occur at element 'fo:block'. [error] Attribute 'widows' cannot occur at element 'fo:block'. [error] Attribute 'orphans' cannot occur at element 'fo:block'. [error] Attribute 'font-size' cannot occur at element 'fo:block'. [error] Attribute 'hyphenate' cannot occur at element 'fo:block'. etc. Any ideas? Thanks, John.

2 1

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

[review] Multiprecision review scheduled for June 8th - 17th, 2012
by Jeffrey Lee Hellrung, Jr. 07 Jun '12

07 Jun '12

Hi all, The review of the proposed Boost.Multiprecision library authored by John Maddock and Christopher Kormanyos has been scheduled for June 8th - June 17th, 2012 and will be managed by myself. >From the Introduction: -------- "The Multiprecision Library provides *User-defined* integer, rational and floating-point C++ types which try to emulate as closely as practicable the C++ built-in types, but provide for more range and precision. Depending upon the number type, precision may be arbitrarily large (limited only by available memory), fixed at compile time values, for example 50 decimal digits, or a variable controlled at run-time by member functions. The types are expression-template-enabled for better performance than naive user-defined types." -------- And from the original formal review request from John: -------- Features: * Expression template enabled front end. * Support for Integer, Rational and Floating Point types. Supported Integer backends: * GMP. * Libtommath. * cpp_int. cpp_int is an all C++ Boost licensed backend, supports both arbitrary precision types (with Allocator support), and signed and unsigned fixed precision types (with no memory allocation). There are also some integer specific functions - for Miller Rabin testing, bit fiddling, random numbers. Plus interoperability with Boost.Rational (though that loses the expression template frontend). Supported Rational Backends: * GMP * libtommath * cpp_int (as above) Supported Floating point backends: * GMP * MPFR * cpp_dec_float cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher Kormanyos' e_float code (published in TOMS last year). All the floating point types, have full std lib support (cos sin exp, pow etc), as well as full interoperability with Boost.Math. There's nothing in principal to prevent extension to complex numbers and interval arithmetic types (plus any other number types I've forgotten!), but I've run out of energy for now ;-) Code is in the sandbox under /big_number/. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… -------- I hope everyone interested can reserve some time to read through the documentation, try the code out, and post a formal review, either during the formal review window or before. I expect to conduct the review in the "traditional" manner, i.e., entirely within the regular boost developers' mailing list (boost(a)lists.boost.org) I will send a reminder of review process details closer to the review window. Thanks! - Jeff

4 23

1.50.0 beta 1 Beta release available
by Beman Dawes 06 Jun '12

06 Jun '12

Boost release 1.50.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains 4 new libraries (Algorithm, Functional/OverloadedFunction, LocalFunction, Utility/IdentityType) and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/history/version_1_50_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

[1.50.0] Beta 1 release candidates available for testing
by Beman Dawes 06 Jun '12

06 Jun '12

Release candidate files for 1.50.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. Thanks, --Beman --PS: I tested the 7z version, and it built without errors on Win7/VC++ Express 2010 sp1

16 43

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by John Maddock 06 Jun '12

06 Jun '12

>>Let us know as soon as you have some results. > > Tested the time taken to run through all the Boost.Math Bessel function > tests, with type double, real_concept (a simple wrapper around double from > Boost.Math's test suite) and mp_number<float_backend<double> > (a trivial > mp_number backend that wraps a floating point type): > > Time for double = 0.0157549 seconds > Time for real_concept = 0.0166421 seconds > Time for float_backend<double> = 0.0408635 seconds > Time for float_backend<double> - no expression templates = 0.0253047 > seconds > > So as you can see, expression templates are a dis-optimization for such > simple types, and even without them you take a noticeable hit: I'm a > little disappointed by this, but not that surprised, mp_number is a rather > heavyweight solution for lightweight types if you see what I mean. > > In any case I'll have a look at the assembly to see if there are any > obvious non-optimizations going on. >From a quick casual look it appears as though the extra time is going in functions not expanded inline - that's certainly the case for the expression template unpacking code. Seems like there may be some small opportunity for optimization of the comparison operators as well (i.e. not evaluating in terms of a compare() function). However, that latter case is only appropriate for exceptionally lightweight backends, for most typical extended precision backends, non of this will make the slightest difference at all... John.

3 3

[COUNTERTREE + SUBALLOCATOR ] New Version
by Francisco José Tapia 05 Jun '12

05 Jun '12

Hi this message is to announce the new version of the [countertree + suballocator] library. You can find in (http://dl.dropbox.com/u/8437476/works/countertree/index.html)<http://dl.dropbox.com/u/8437476/works/countertree/index.html> When I was writing the document explaining the allocator's algorithm. I reexamined my code , and It run well and have an easy interface , but the internal design was obscure and difficult to understand. Due this, I decided redesign it in order to make it clear and easy to understand. I changed too the version of the GCC compiler form the 4.6 to 4.7, and the machine used for the benchmarks. My old computer, where I developed the code, had a good cache but a bad bus memory (Single channel 533Mz), and this introduce a distortion in the comparison of some algorithms. The new machine is a QuadCore with 8M of cache and 8G dual channel 1066 MHz. The results obtained are more similar to the obtained in a modern machine. I added a new point to the documentation explaining the additional features of the countertree set, multiset, map and multimap with two examples. You can find in ( http://dl.dropbox.com/u/8437476/works/countertree/ordered.html#functionality) For the people who don't know this project, this is a description : *COUNTERTREE* This library is an implementation of a binary red-black counter tree. This tree have an additional counter in each leaf. This permit the access to the elements by the position, like in a vector. It is a random access container with random access iterators . With this tree we have vectors (cntree::vector_tree) with identical interface than std::vector. The vector_tree have the same speed inserting and deleting in any position (all the operations are O(log N)).It is slower than std:vector inserting and deleting at end, but much faster for to insert and delete in any other position. With ordered information, we have in the cntree namespace the classes set, multiset, map and multimap, with identical interface than the STL classes, with the plus of access to the elements by position, like in a vector. The iterators are random access , and you can subtract two iterators in a O(log N) time for to know the number of nodes between them (even with the end( ) and rend( ) iterators) *SUBALLOCATOR* The allocator is the data structure defined in the STL, as interface between the data structures and the memory provided by the Operating System (O.S.). The allocator manages the memory received from the Operating System, and the memory requested in the allocate operations and the memory returned in the deallocate operations. To write an allocator for to manage a wide range of size elements and a big number of elements (several millions) of each size in a fast way, it's a very difficult task. When the number of elements grows, many allocators begin to have speed problems. For to improve the speed allocating of the small size elements, many allocators request to the Operating System big chucks of memory. With this, the allocator don't need request memory to the operating system for each allocation. But many allocators don't return well the unused chucks of memory to the Operating System and the memory used by the allocator is the maximum used, never decrease . These allocators are named pool allocators. If you have a small number of elements, you have a small problem, small resources and small time operations. But, if you have several millions of elements allocated, perhaps you are using several GB of memory. Running a program with GB of memory don't used, because the allocator don't return the memory request, is a great waste of resources. This problem is specially important in two environments : - When you have a limited resources, as occurs in the mobile phones, pads , tablets... - When the programs must run continuously in a multitask environment If you use an allocator for the allocation of variable size elements, and a pool allocator for the allocation of fixed size elements, this improve the speed, but increase the memory consumption, which is the sum of the maximum memory of the pool allocator and the memory used by the allocator. If the pool allocator don't return to the Operating System the unused memory, this can't be reused by the allocator. The *suballocator is a solution to these problems*, and others memory problems described in the suballocator page. The suballocator is a layer between the allocator and the data structures, compatible with any allocator with the STL definition. The suballocator request memory to the allocator, and return to it when unused. With the suballocator a) *We have a very fast allocation* *(around 2 times faster than the std::allocator of GCC 4.7, CLANG 3.0 and 3 times than Visual Studio 10 *See details in the *Suballocator Benchmark<http://dl.dropbox.com/u/8437476/works/countertree/suballocator.html#benchma…> *)* b) *Return memory to the allocator, for to be used by others types of data*. Many allocators, return this memory to the Operating System, and decrease the memory used by the program, *( as you can see in the *Suballocator Benchmark <http://dl.dropbox.com/u/8437476/works/countertree/suballocator.html#benchma…> *)* c) *You can use with any allocator if it is according with the STL definition*. The suballocator provides speed and memory management to any allocator d) Even the time of the allocation is a small part of the time spent in the insertion in a std::set, the suballocator obtain time reductions over over the 30% respect the std::allocator. The secret is the cache performance due to the data locality improvement. *COUNTERTREE + SUBALLOCATOR* The join of the two ideas provide us data structures with a suballocator built-in. They are, in the namespace cntree, the vector_tree_pool, set_pool, multiset_pool,map_pool and multimap_pool, with identical interface than the STL classes but better performance. Tray it. It fast, useful and easy to understand and use,. They are the STL classes with a few additional functions. I had checked this code with GCC 4.7 (32 and 64) , CLANG/LLVM 3.0 and Visual Studio 1010 (32 and 64). If you find any error or problem in the code , the documentation or in any other part ( as friendly do Mr Rene Rivera in the first version). Please mail me ( fjtapia(a)gmail.com) or if you mail Boost, please insert [countertree] in the head of the message. Some days I have not time to read all messages arrived to my mail, but if I see that I detect and respond first. If you have some idea, or have any comment, please mail me, always two legs run more than only one in the pursuit of the goal, to be useful to the community of programmers in the same way than our predecessors had been useful to us. Sincerely yours Francisco Tapia fjtapia(a)gmail.com

1 0

[Who's Using Boost?] FaceBook
by Brian Wood 05 Jun '12

05 Jun '12

Thanks for the link. I notice Folly has an IntrusiveList derived from boost::intrusive::list. We have a nickname for boost::intrusive::list also -- ilist. Perhaps there are others who have done the same? Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

1 0

[bind] Move Parameters?
by Daniel Larimer 05 Jun '12

05 Jun '12

Say I have some synchronous code like this: vector<data> v; some_method( std::move(v) ) Now I want to call to make that some_method call asynchronous so what I really want is function<void()> f = bind( some_method, boost::rref( std::move(v) ) ) asio_io_service.post(f); // performs async move of v into some_method asio_io_service.post(f); // undefined, or throw bound parameter has already moved... As far as I can tell there is no current support for anything like this, and I think it could be very useful. Dan

1 0

Re: [boost] [git/modularization] Suggested names for branches?
by Sean Chittenden 04 Jun '12

04 Jun '12

> The three branches in question, with the git-flow names in parens, > were the main development branch (develop), release prep branches (?), > and the branch with actual releases (master). > > Is there a better usual convention for these names? I have a vague > memory of someone mentioning "master" for the main development branch, > "release" for the branch with the actual releases, and maybe > "beta-x.xx.x" for release prep branches. re: git flow branch names, I'd advocate for their use simply because it matches all of the external training material (videos, docs, flow charts, etc) available regarding the use of git flow (and it reduces the friction for getting initially setup). I agree that they aren't ideal and much prefer the naming convention used by the FreeBSD project (where branch names indicate a stable API, 9-STABLE, 8-STABLE, etc., vs -CURRENT), but I'd stick with the default names for now and then in a release or three consider changing from the defaults to something boost specific. -sc # Initialize default git flow branches git flow init -d # From project/.git/config [gitflow "branch"] master = master develop = develop [gitflow "prefix"] feature = feature/ release = release/ hotfix = hotfix/ support = support/ versiontag = -- Sean Chittenden sean(a)chittenden.org

1 0

folly (Facebook's open source C++ library)
by Tudor Bosman 04 Jun '12

04 Jun '12

https://www.facebook.com/notes/facebook-engineering/folly-the-facebook-open… I'm Tudor, one of the folly developers. I'll try to answer your questions or poke the appropriate people :) Re: "NO EXCEPTIONS" in the README -- the README file was intended for internal Facebook contributors (hence stray references to internal paths), and "NO EXCEPTIONS" referred to "no exceptions to the rules above", NOT "no C++ exceptions". Will fix / clarify / remove soon. -Tudor.

2 1

[Who's Using Boost?] FaceBook
by Dave Abrahams 04 Jun '12

04 Jun '12

as noted in https://www.facebook.com/notes/facebook-engineering/folly-the-facebook-open… -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 4

asio::epoll_reactor::complete_operations_and_timers() - thread saftey
by Hite, Christopher 04 Jun '12

04 Jun '12

I thought I'd take a look at the epoll_reactor implementation. I thinking of using asio proactor style code to use kernel bypass libraries. I wanted to see how you do async IO with a pool of threads. I think I see a bug. None of the operations there done outside of the lock seem thread safe. They unsafely modify linked lists. lock.unlock(); read_op_queue_.complete_operations(); write_op_queue_.complete_operations(); except_op_queue_.complete_operations(); Chris

1 0

[python] run python script from bjam
by lcaminiti 03 Jun '12

03 Jun '12

Hello all, I build a Boost.Python module and install it using bjam as follow: python-extension pydef : deduced_params_pydef.cpp : <library>/boost/python//boost_python <library>/boost/regex//boost_regex <link>shared:<define>BOOST_REGEX_DYN_LINK=1 ; install pydef_install : pydef : <install-dependencies>on <install-type>SHARED_LIB <install-type>PYTHON_EXTENSION <location>. ; I the same dir I have a python script deduced_params_pydef.py which will import the module and test it. How do I run the python script automatically from bjam so to fully compile and test the module that my code generates? Something like (this doesn't work of course): # Make sure pydef target is built first, then runs python deduced_params_pydef.py run-py pydef_install : deduced_params_pydef.py ; Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-python-run-python-script-from-bjam… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

boost.unordered undocumented methods
by niXman 03 Jun '12

03 Jun '12

Hello! In the documentation for boost-1.49.0 the following methods are not documented: https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_ma… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… https://github.com/ryppl/boost-svn/blob/master/boost/unordered/unordered_se… -- Regards, niXman ___________________________________________________ Dual-target(i686/x86_64) MinGW compilers for i686/x86_64 hosts: http://sourceforge.net/projects/mingwbuilds/

1 0

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)
by Antony Polukhin 03 Jun '12

03 Jun '12

Hi, There is a detail/sp_typeinfo.hpp which is not documented, and has some drawbacks. This header provides type_info like class that can be used with RTTI disabled. I am proposing to refactor this header, move it to utility/template_info.hpp and document it as a separate utility. Refactored header will provide classes template_info_ptr, template_info<T>, type_info_ptr and free function get_template_info<T>() Advantages: 1) more portable and reliable than detail::sp_typeinfo (no sp_typeid_<T>::ti_ public static variable) 2) copyable type_info like classes 3) has all the type_info functions + name_demangle 4) works with disabled RTTI 5) better functionality: no need to write macros like: #if defined( BOOST_NO_TYPEID ) # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X)==(Y)) #elif (defined(__GNUC__) && __GNUC__ >= 3) \ || defined(_AIX) \ || ( defined(__sgi) && defined(__host_mips)) # include <cstring> # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) \ (std::strcmp((X).name(),(Y).name()) == 0) # else # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X)==(Y)) #endif 6) user can explicitly chose between template_info+template_info_ptr and type_info+type_info_ptr 7) no macro (get_template_info<T>() instead of &BOOST_SP_TYPEINFO(T) ) Disadvantages: 1) Does not work with variables (but you can still use BOOST_TEMPLATE_INFO_PTR(BOOST_TYPEOF(var))) 2) BOOST_CURRENT_FUNCTION produces long strings, and that could lead to code bloat when RTTI disabled Some usage examples: int main () { // Portable way that works with and without RTTI: copyable_type_info t1 = get_template_info<std::string>(); copyable_type_info t2 = get_template_info<int>(); // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << t1.name_demangled() << '\n'; // int std::cerr << t2.name_demangled() << '\n'; // false std::cerr << (t1 == t2) << '\n'; // true std::cerr << (t1 != t2) << '\n'; copyable_type_info t1_copy = t1; // .?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@ std::cerr << get_template_info<std::string>().name() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << get_template_info<std::string>().name_demangled() << '\n'; // explicitly using no-RTTI methods // int>::name_begin(void) std::cerr << template_info<int>::name_begin() << '\n'; // int std::cerr << template_info<int>::name_demangled() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >::name_begin(void) std::cerr << template_info<std::string>::name_begin() << '\n'; // class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > std::cerr << template_info<std::string>::name_demangled() << '\n'; template_info_ptr p1 = template_info<int>::construct(); template_info_ptr p2 = template_info<std::string>::construct(); std::cerr << (p1 == p2) << '\n'; std::cerr << (p1 != p2) << '\n'; } If there is interest, I can commit code to sandbox and request for review. P.S.: As I know, Boost.Function, Boost.Shared_ptr and Boost.Exception use code similar to what I am proposing. Following libraries use typeid() and can benefit from using proposed classes: Boost.MSM, Boost.Math, Boost.Test, Boost.Graph, Boost.Units, Boost.XPressive, Boost.Any, Boost.Statechart -- Best regards, Antony Polukhin

3 4

[filesystem] Linker error against std::codecvt in VS2012 RC
by Lars Viklund 02 Jun '12

02 Jun '12

Hi list, I foolishly installed the Visual Studio 2012 RC yesterday night and made an overnight build of Boost. It seems like there's something awry, as I'm getting a mysterious linker error in Filesystem's path.obj [1], even in a fresh empty testbed project. I'm linking Boost statically and the CRT dynamically. If I link the CRT statically, the linker error goes away. Has anyone else installed this software and can reproduce this problem? I'm building Boost against trunk, r78785. I dread to think of the horror that I will have go through in actually reporting a bug against the runtime itself :( [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : error LNK2001: unresolved external symbol "protected: virtual int __thiscall std::codecvt<wchar_t,char,int>::do_length(int const &,char const *,char const *,unsigned int)const " (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) -- Lars Viklund | zao(a)acc.umu.se

4 5

[msm]entry point pseudo states and events (Re: [msm] orthogonal region and event consume)
by Takatoshi Kondo 02 Jun '12

02 Jun '12

Hi Christophe, I changed the subject. Current topic isn't concerned with orthogonal region directly. On Thu, May 31, 2012 at 5:43 AM, Christophe Henry <christophe.j.henry(a)googlemail.com> wrote: > Hi Takatoshi, > > >>> I read your ticket. Note that it's not UML-conform to have 2 transitions >>> originating from Entry1 (11-08-06.pdf §15.3.8 page 551). >>> After reading the Standard again twice, I realized that no example >>> provided >>> there displays any event on both transitions, which is really bad if it's >>> what they mean. I need to have a look at other literature. > > >> I read the section that you mentioned carefully. My interpretation of >> UML specification is different from yours. >> It's really difficult to explain my interpretation. So, I draw the >> diagram. See the attached file. >> Am I misunderstanding? > > > I will not pretend I have the perfect understanding of the Standard. Here's > my take. I also saw the sentence on top of your diagram and didn't fully > understand it when reading the Standard. There is also the following > sentence in the Standard: > > "An entry pseudostate is used to join an external transition terminating on > that entry point to an internal transition > emanating from that entry point". > > Which sounds logical because on your diagram the regions would not be > orthogonal. > > This means you cannot have transitions triggered by different events leading > to the entry point, not can you have different transitions leaving it. You > will need more entry points. > > Caution: I am far from being sure I got it right. That's why I precised my > definition of it in the doc. The implemented solution has the advantage that > you have the normal transition handling, including multiple transitions and > guards, events with data, base events, etc. > What you don't have is entry in multiple regions, which only the fork > currently provides, at the cost of lesser encapsulation. > Correct or not, this is the part of the Standard I chose to implement pseudo > entries. > > To be honest, I'm not of fan of pseudo entries. I prefer the vastly superior > solution of entering a submachine the "normal" way, then letting a > templatized, enable_if'd on_entry of the submachine do something clever with > the event at compile-time. Aha! I completely overlooked such approach. For example, we can choose the initial state in submachine using mpl and initial_state typedef instead of using entry_pseudo_state. I believe that I've understood your design decisions. I also think that following the UML standard blindly is not essential. >> My goal is to improve sub-machines' re-usability. If we want to reuse >> sub-machines in another state machines, sub-machines shouldn't know >> the outside information. > > > I agree but is it the case? I mean, if you send normal events to your > submachine through your outer machine, it also needs to know them, right? > I understand this as: "hi, I'm a submachine and I provide the following > entry points: Entry1 requires Event1, Entry2 requires Event2, etc.". A bit > like function parameters. I wanted to explain that as follows: "hi, I'm a submachine and I provide the following entry points: Entry1 accepts any events. Because I don't care that. " Let me introduce more practical example that requires entry_pseudo_state. ScanFinger.png is a sub-machine. This sub-machine's primary purpose is to scan fingerprint. Before scanning, the sub-machine checks that finger is alive or not. But it's optional. To skip this check procedure, the entry point pseudo state ScanOnly is provided. FingerPrintRegister.png is the parent state machine. It uses ScanFinger as a sub-machine twice. In this scenario, alive checking is not required. So, the parent machine uses ScanOnly enty_pt. In another scenario, not mentioned here, might require the normal entry into ScanFinger to check the finger is alive. ScanFinger machine doesn't care about outer event. In FingerPrintRegister, the states RightScnning and LeftScanning have different incoming events for ScanOnly entry points. But any events are accepted. And then, it's not referred. Based on your suggestion, I introduce the base event class. As long as the incoming event of entry point is not "none", this approach works good. struct AnyEvent {}; struct Completed: public AnyEvent {}; struct StartButtonPressed: public AnyEvent {}; (See 39_FingerPrintExampleBaseEvent.cpp) If the incoming event is "none", the transition is stopped. Sometimes I want to use "none" as incoming event for entry point in the same sub-machine. And it is impossible that msm::front::none inherits user event classes such as AnyEvent. I'm trying to find better approach to solve the above problem. Thanks, Takatoshi >> See my second mail in this thread. My solution using templates >> (entry_pseudo_event_template.cpp) requires the template parameters >> same as the number of entry point pseudo states in sub-machine. It's >> acceptable but if outgoing transition would be able to use none, I >> would remove the template parameters. > > >> In the above case, it is not required to support multiple incoming >> transitions to one entry pseudo state. Because the instances of >> sub-machine are different. > > > In this case, maybe I could interest you in defining a base event class for > Event1 and Event2, then making this base event the event triggering the > inside transition. Your first example would be changed this way: > > struct BaseEvent {}; > struct Event1: public BaseEvent {}; > ... > msmf::Row < Entry1, BaseEvent, State2_2, msmf::none, msmf::none > > > > > Regards, > Christophe > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 6

Interest in double-ended priority queue? (priority_deque)
by Nathaniel McClatchey 02 Jun '12

02 Jun '12

Details: Template-based container adapter. Mimics std::priority_queue interface and requirements. O(1) read and O(log n) delete of either end of queue. O(n) create and merge. Functions for unordered access and mutating of elements. Remaining development: Further optimization. Note: Implementation is similar to but independent from http://lists.boost.org/Archives/boost/2011/12/188848.php

2 2

Standardization of Boost (and other) libraries
by Beman Dawes 01 Jun '12

01 Jun '12

The C++ standards committee has set up a discussion forum (also accessible via email) to help those preparing language and library proposals. Requests for feedback, help, champions, and anything else related to proposals is on topic. https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals Note that this is a different URL than mentioned at C++Now! - language and library proposal groups have since been combined into a single group. After some false starts, discussion has started in earnest. The first two requests for feedback were on proposals for Boost.Any and Boost.Optional. If you are interested in proposing a Boost library for standardization, you probably want to check out std-proposals. --Beman

1 0

Re: [boost] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by John Maddock 01 Jun '12

01 Jun '12

>>* What is the type of boost::multiprecision::number_category::type for >>all the provided backends? Could the specialization for >>boost::multiprecision::number_category::type be added in the >>documentation of each backend? and why not add also B::signed_types, >>B::unsigned_types, B::float_types, B::exponent_type? > > OK. On second thoughts, the members of B::signed_types etc are basically implementation details - optimizations if you will. Rather than listing the types explicitly I'd prefer some more weasel wording along the lines of "This type will interoperate natively with any signed or unsigned built in integer type no wider than a long - this means for example that multiplying by a integer literal is more efficient than constructing an mpz_int temporary from the integer and then multiplying. Likewise for the other arithmetic operations." John.

1 0

Re: [boost] [filesystem] Linker error against std::codecvt in VS2012 RC
by Stewart, Robert 01 Jun '12

01 Jun '12

Peter Dimov wrote: > Lars Viklund wrote: > > > [1] 1>libboost_filesystem-vc110-mt-gd-1_50.lib(path.obj) : > > error LNK2001: unresolved external symbol "protected: virtual > > int __thiscall std::codecvt<wchar_t,char,int>::do_length(int > > const &,char const *,char const *,unsigned int)const " > > (?do_length@?$codecvt@_WDH@std@@MBEHABHPBD1I@Z) > > Well, you could start by preparing a simple test program that > calls std::codecvt in the same way path.obj does, to eliminate > Boost as a factor. If do_length is indeed not present in the > dynamic runtime, this would probably be a showstopper bug > against the RC, so it will get noticed. :-) If that's not the problem, verify that you built Boost.Filesystem using the same CRT. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 1

Re: [boost] [Boost-users] [review] Multiprecision review scheduled for June 8th - 17th, 2012
by Jeffrey Lee Hellrung, Jr. 31 May '12

31 May '12

Just to preempt this, I think it will be more appropriate for any review discussions to take place on the developers' list (boost(a)lists.boost.org) On Wed, May 30, 2012 at 2:38 PM, Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr> wrote: > Le 29/05/12 23:08, Jeffrey Lee Hellrung, Jr. a écrit : > > Hi all, > > > > The review of the proposed Boost.Multiprecision library authored by John > Maddock and Christopher Kormanyos has been scheduled for > > > > June 8th - June 17th, 2012 > > > > and will be managed by myself. > > > > I hope everyone interested can reserve some time to read through the > documentation, try the code out, and post a formal review, either during > the formal review window or before. > > > Hi, > > glad to see that the library will be reviewed soon. > > I have spent some hours reading the documentation. Here are some comments > and a lot of questions. > > * As all the classes are at the multi-precision namespace, why name the > main class mp_number and not just number? > > typedef mp::number<mp::mpfr_float_**backend<300> > my_float; > > * I think that the fact that operands of different backends can not be > mixed on the same operation limits some interesting operations: > > I would expect the result of unary operator-() always signed? Is this > operation defined for signed backends? > I would expect the result of binary operator-() always signed? Is this > operation defined for signed backends? what is the behavior of > mp_uint128_t(0) - mp_uint128_t(1)? > > It would be great if the tutorial could show that it is possible however > to add a mp_uint128_t and a mp_int256_t, or isn't it possible? > I guess this is possible, but a conversion is needed before adding the > operands. I don't know if this behavior is not hiding some possible > optimizations. > > I think it should be possible to mix backends without too much complexity > and that the library could provide the mechanism so that the backend > developer could tell to the library about how to perform the operation and > what should be the result. > > * Anyway, if the library authors don't want to open to this feature, the > limitation should be stated more clearly, e.g in the reference documentation > "The arguments to these functions must contain at least one of the > following: > > An mp_number. > An expression template type derived from mp_number. > " > there is nothing that let think mixing backend is not provided. > > * What about replacing the second bool template parameter by an enum class > expression_template {disabled, enabled}; which will be more explicit. That > is > > typedef mp::mp_number<mp::mpfr_float_**backend<300>, false> my_float; > > versus > > typedef mp::mp_number<mp::mpfr_float_**backend<300>, > mp::expression_template::**disabled> my_float; > > * As I posted in this ML already I think that allocators and precision are > orthogonal concepts and the library should allow to associate one for fixed > precision. What about adding a 3rd parameter to state if it is fixed or > arbitrary precision? > > * Why cpp_dec_float doesn't have a template parameter to give the integral > digits? or as the C++ standard proposal from Lawrence Crow ( > http://www.open-std.org/jtc1/**sc22/wg21/docs/papers/2012/**n3352.html<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html>), > take the range and resolution as template parameters? > > * What about adding Throws specification on the mp_number and backend > requirements operations documentation? > > * Can the user define a backend for fixed int types that needs to manage > with overflow? > > * Why bit_set is a free function? > > * I don't see nothing about overflow for cpp_dec_float backend operations. > I guess it is up to the user to avoid overflow as for integers. what would > be the result on overflow? Could this be added to the documentation? > > * can we convert from a cpp_dec_float_100 to a cpp_dec_float_50? if yes, > which rounding policy is applied? Do you plan to let the user configure the > rounding policy? > BTW, I see in the reference "Type mp_number is default constructible, and > both copy constructible and assignable from: ... Any type that the Backend > is constructible or assignable from. " > I would expect to have this information in some way on the tutorial. I > will appreciate also if section "Constructing and Interconverting Between > Number Types" says something about convert_to<T> member function. > > If not, what about a mp_number_cast function taking as parameter a > rounding policy? > > * Does the cpp_dec_float back end satisfies any of the Optional > Requirements? The same question for the other backends? > > * Is there a difference between implicit and explicit construction? > * On c++11 compilers providing explicit conversion, couldn't the > convert_to function be replaced by a explicit conversion operator? > * Are implicit conversion possible? > > * Do you plan to add constexpr and noexcept to the interface? After > thinking a little bit I'm wondering if this is this possible when using 3pp > libraries backends that don't provide them? > > * Why do you allow the argument of left and right shift operations to be > signed and throw an exception when negative? Why don't just forbid it for > signed types? > > * Why the "Non-member standard library function support" can be used only > with floating-point Backend types? Why not with fixed-point types? > > * What is the type of boost::multiprecision::number_**category::type > for all the provided backends? Could the specialization for > boost::multiprecision::number_**category::type be added in the > documentation of each backend? and why not add also B::signed_types, > B::unsigned_types, B::float_types, B::exponent_type? > > * Why have you chosen the following requirements for the backend? > - negate instead of operator-() > - eval_op instead of operator op=() > - eval_convert_to instead of explicit operator T() > - eval_floor instead of floor > > Optimization? Is this optimization valid for short types (e.g. up to 4/8 > bytes)? > > * As the developer needs to define a class with some constraints to be a > model of backend, which are the advantages of requiring free functions > instead of member functions? > * Couldn't these be optional if the backend defines the usual operations? > * Or could the library provide a trivial backend adaptor that requires the > backend just to provide the usual operations instead of the eval_xxx? > * How the performances of mp_number<this_trivial_**adaptor<float>, false> > will compare with float? > > * And last, I don't see anything related to rvalue references and move > semantics. Have you analyzed if its use could improve the performances of > the library? > > Good luck for the review. A really good work. > Vicente > > > ______________________________**_________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users> >

3 2

[nowide] Easy Unicode For Windows: Request For Comments/Preliminary Review
by Artyom Beilis 31 May '12

31 May '12

Hello all Booster, I comments on a library that I want to submit for a formal review. The library provides an implementation of standard C and C++ library functions such that their inputs are UTF-8 aware on Windows without requiring using Wide API to make program work on Windows. Library: Boost.Nowide Download: http://cppcms.com/files/nowide/nowide.zip Documents: http://cppcms.com/files/nowide/html/ Features: http://cppcms.com/files/nowide/html/index.html#main_the_solution Tested On: OS: Windows 7 32/64 bit, Linux Compilers: GCC-4.6, MSVC-10 Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

7 17

Is there interest in typeid(TYPE).name() like function that does not require RTTI
by Antony Polukhin 30 May '12

30 May '12

Hi, Would be there some interest in function for getting class name without RTTI? Such function can be implemented like that: template <class TemplateNameT> std::string template_type(const TemplateNameT& v) { #ifdef _MSC_VER const char* const template_name_begin = strstr(BOOST_CURRENT_FUNCTION, "(const ") + sizeof("(const ") - 1; BOOST_ASSERT(template_name_begin); const char* const template_name_end = template_name_begin + strlen(template_name_begin) - sizeof("&)"); #else // Code for other platforms #endif return std::string(template_name_begin, template_name_end); } If there is some interest, I'll update code to work on other platforms, and change method signature from template_type(instance) to template_type<InstanceTypeT>::name() Usage example: // Function can be compiled with RTTI disabled. template <class T> void foo(const T& val) { std::cerr << template_type<T>::name(); // instead of typeid(T).name(); } -- Best regards, Antony Polukhin

4 7

[msm] orthogonal region and event consume
by Takatoshi Kondo 30 May '12

30 May '12

Hello Christophe, I'm using Boost.MSM version 1.49.0. I bumped on a suspicious behavior. See the attached diagram and code. When Event1 occurs in State1, Action1 is invoked. I think the event isn't consumed correctly. If the transition from State1 to State2 connect State2 directly instead of Entry1, the event seems to be consumed. What do you think? Thanks, Takatoshi

4 9

Memory upgrade of wowbagger
by DongInn Kim 30 May '12

30 May '12

Dear all, My name is DongInn Kim, systems administrator of the current boost server machine, wowbagger. I am sorry for this short notice but we would like to upgrade wowbagger's memory at 2:00pm (E.T.) May 30, 2012. We need to reboot wowbagger and It should not take more than 10 mins to upgrade RAMs. During the memory upgrade, the following services would not be available. - mailing list - mail archives - trac - subversion - official websites Please let me if you have any issues or questions about the outage. Regards, -- - DongInn --------------------------- CREST System administrator dikim(a)cs.indiana.edu Indiana University Bloomington, IN

1 1

[1.50.0] Beta closing; planning to build Beta RC tomorrow
by Beman Dawes 30 May '12

30 May '12

Per the schedule, building a release candidate for the beta will begin tomorrow. There are still a few hours left for merging emergency bug fixes that are stable in trunk, with a release manager's permission. But that's being charitable. We need to let tests cycle overnight and move forward. This is a beta, after all, and not the final release. branches/release will reopen for bug fixes as soon as the beta ships. See the calendar at http://www.boost.org/community/index.html for the release schedule. --Beman

1 0

Status of Boost.Atomic?
by Sean Chittenden 30 May '12

30 May '12

Does anyone know what the status of Boost.Atomic is? I remember hearing that Boost.Atomic was to be committed by the end of March, but now that we're backed up against the release, it doesn't look like Boost.Atomic is going to make it in to 1.50.0. Is there any chance that someone can push Boost.Atomic along and commit it to trunk so that it can finally get some exposure and possibly make it in to a release? -sc PS CLang 3.1 was released recently with with support for atomics, but the current version of XCode ships a dated version of CLang 3.1 with atomics disabled. This compatibility shim is going to be very useful during the C++11 transition. >>>> Where can I find the latest version of boost.lockfree ? There's nothing >>>> in >>>> the sandbox or the vault (it seems). The latest commit on Tim's public >>>> git >>>> repo was done more than 6 month ago. >>>> >>>> Now that atomic has been accepted, are there any roadblocks to have >>>> boost.lockfree released ? >>> >>> boost.atomic has been accepted, but it hasn't been merged into trunk, yet >>> ... helge, do you have any timeline? >> >> I will package it up before the end of march, this should suffice? > > great! -- Sean Chittenden sean(a)chittenden.org

2 1

Release notes for 1.50
by Daniel James 30 May '12

30 May '12

Hello everyone, It's time to fill in the release notes, they're at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/boost… Note that from now on, that this is on the live site, not the beta site. If you don't know quickbook syntax, don't worry, I'll clean it up before regenerating the page. You can see the html output at: http://www.boost.org/users/history/version_1_50_0.html It isn't automatically updated, so you'll only see your changes when I update it. But if that's too much for you, you can email me and I'll sort it out. It's probably better for you if do it yourself, as there's always the chance that an email will slip through the cracks, and it will be easier for you to fix typos and link errors later on. Also, please don't link to changesets in the history, if you don't have something to link to, just create a ticket, accept it and close it with a message like: "Fixed in trunk in [1234]. fixed in release in [5678]". It's also a good idea to add a more detailed change log to your library's documentation and link to that. There are a few outstanding things to do, which I should sort out before posting this, but this is at shorter notice than normal. I'll deal with them in the next day or two, so please have a little patience. thanks, Daniel

7 10

Status of GIT and BOOST
by Marshall Clow 29 May '12

29 May '12

[ reposted in its own thread so that it is less easily missed ] Synopsis: ========= The Boost Steering Committee has agreed IN PRINCIPLE to move ahead with the migration to Git and to a modular repository structure. What? ===== Development of Boost will move from a monolithic subversion repository to the much-discussed Git repository structure consisting of one super-module that points (via submodules) to other repositories, each containing an individual Boost library. The Git repositories will be hosted on github. Although Boost will move to a distributed development model, it will still be tested and released as a unified whole. There will be scripts to reassemble the monolithic Boost from its constituents. The development work flow need not change for contributors. They have the option to check out boost super-module and all the submodules, execute the script to make a monolithic whole, and develop and test as usual. It is currently an open question what to do about issue tracking once we move to modularized repos. Both Github and Redmine have been suggested as possible solutions that would give users a unified way to search for bugs across all of boost. The migration will NOT take place before this issue is settled. Why? ==== Boost is big and getting bigger. We've been experiencing scalability problems with our tools and with our release and testing procedures for a while now. The problem is bigger than "subversion commands are slow". Moving a large, diverse library collection forward in lock-step slows down progress. Our solutions to the scalability problems have themselves caused problems. We don't branch from trunk for our releases. Changes languish on trunk because people forget to merge them. Trunk is a wild west where test results for any one library are often broken due to requirements shifting from under it, causing confusion about whether a change can be safely merged to release. And the converse is also true: just because tests are green on trunk is no assurance that a change won't cause problems on release. The solution is to free each library to evolve independently within its own repository. Boost is a collection of the last stable releases of each of its constituent libraries. Library maintainers develop and test against this latest stable library collection and issue rolling releases on their own timetable. Release managers pick which versions of each library to include and have the option to temporarily fork a library to correct integration issues to get a release out, issuing pull requests to get the fixes upstream. The result is a more dynamic, loosly-coupled ecosystem where both the individual libraries and Boost as a whole can move forward more quickly. How? ==== The modular git repositories have already been created along with a script to populate them automatically. At some point, the old svn repo will be locked permanently and the modular git repos will be re-populated from svn. John Wiegley has worked on a script to do the conversion with perfect fidelity. A separate git repo with all of Boost's history will be created such that it can be grafted on to each submodule if desired. That way, each submodule can share history with all the others (a significant space win). The test and release scripts and the website will be updated to account for the new development model. From that point forward, all development will take place in the git repos. The old Trac will eventually be locked and archived. Whatever issue tracking solution we come up with, tickets must be migrated. The plan is still coming together here. Bear with us. When? ===== The approval is IN PRINCIPLE and not IN FACT at this point because the necessary pieces are not yet all in place. In particular, issues such as trac integration and testing are not yet settled. Also, we want a script in hand that verifies that no changesets are lost or munged in the svn->git migration. Once the steering committee is satisfied that all the pieces are in place, we'll give a final go-ahead, the dates will be announced, and the transition will take place. An ETA is hard to predict at this point, but we are aiming for making the switch in the next few months. Possibly after 1.50 or 1.51. Comments: ========= The Boost Steering Committee understands that there is general but not universal support in the Boost community for this migration. The committee came this to decision after long analysis of the ongoing problems facing Boost, and of the merits of the proposed migration. It is the role of the Steering Committee to make difficult decisions like this, even when the wider community is unable to reach universal consensus. We will do everything to make this transition as painless as possible, and to give those not comfortable with git the support they need. We all appreciate your understanding. THANKS: ======= Thanks are due to the many people who have worked over the past few years to make this transition happen, including: Dave Abrahams Daniel Pfeifer John Wiegley Beman Dawes Eric Niebler Troy Straszheim Thanks, guys! Here's to making Boost better, faster and stronger. --Your friendly neighborhood steering committee Beman Dawes Dave Abrahams Hartmut Kaiser Jeff Garland Jon Kalb Marshall Clow Robert Stewart Steven Wantanabe -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

1 0

Revelations at C++Now!?
by Lars Viklund 29 May '12

29 May '12

Hi list. Rumor has it that C++Now! is now over, and people are slowly returning to reality. What I wonder is if anything relevant to our lives was discussed or revealed at the conference. I know how easy it is at a conference or workshop to completely forget about the people out there that are not present when things are discussed or presented. If I recall correctly, there were to be some modularisation/VCS presentation from the Steering Committee, and I'm sure that you lads all had some lovely brainstorms and fistfights over beer and pizza. Come on, spill the beans. What did you all decide that will have an influence on the lives of us mortals going forward? -- Lars Viklund | zao(a)acc.umu.se

8 10

[filesystem] Create poisoned directory?
by Beman Dawes 29 May '12

29 May '12

Ticket #6932 identifies error reporting bugs in the filesystem create_directories() function. To run test cases I'd like to create a directory is OK to delete, but is poisoned against as many other operations as possible. How can this be done via the POSIX API? How can this be done via the Win32 API? Thanks, --Beman

2 1

[Spirit] Possible regression (certainly a behavioural change) regarding sequential-or with optional rhs
by adam.butcher＠selexelsag.com 29 May '12

29 May '12

Hi Hartmut, Joel, It seems that the new optional-collapsing behaviour in Spirit 2.5.1 overly simplifies the attributes of certain productions, transforming a tristate 'optionality' (optional<optional<S>>) into a simple boolean (optional<S>). This effectively flattens the two 'omitted' states into one -- in some cases (the use case below for example) they need to be distinguished (unless there is a better way to specify the rule). Ref our previous discussion on this ( http://lists.boost.org/Archives/boost/2009/12/159680.php) (in fact it is exactly this example that is causing us the problem with the latest version). Adam Butcher wrote on 2009-12-04 at 13:19:51: > [snip] > The [array subscript] grammar spec is > > (start || (':' >> -start)) > > and not > > (start || (':' >> start)) > > I would expect optional<S> for both only in the latter case. > In the former I am deliberately allowing the specifier to the right of > the colon to be omitted -- within the already optional right-hand-side > of the sequential-or. This allows for input such as > > (1) $x // $x (assume it references a sequence) > (2) $x[7] // element 7 of $x > (3) $x[7:] // a slice of $x beginning at element 7 > (4) $x[:7] // a slice of $x up to element 7 > (5) $x[2:7] // a slice of $x beginning at 2 ending at 7 > (6) $x[:] // equivalent to $x (unspecified bounds) > > In the action function, wrt to right-hand-side of the sequential-or, I > need to determine: > a) whether a range specifier has been provided at all > (given by (bool) at_c<1>(access_spec)) > b) whether the range specifier includes an explicit bound > (given by (bool) *at_c<1>(access_spec)) > > The left-hand-side of the sequential-or is either an (optional) > 'range_begin' index if a range specifier is given or a lone 'index' > specifier if no range specifier is given. > > If the two optionals on the right-hand-side were collapsed would I not > lose the ability to distinguish between (2) and (3)? The attached program demonstrates the issue. With boost 1.47 (2.5) it works fine, with 1.48 (2.5.1) it breaks. I've attached the source file but included the comment at the top in this mail for convenience. Kind regards, Adam // Change of behaviour in Spirit 2.5.1 regarding collapsing optionals // in sequential-or productions. // // Previous discussion from 2009 related to this: // http://lists.boost.org/Archives/boost/2009/12/159680.php // // // Given the STDIN // // s[:] // // the program below is expected to produce the following output: // // Have range spec... // No begin specified, using container begin. // No end specified, using container end. // Got: 'Range[B:E)' // // However, with 2.5.1, it produces the following: // // Have range spec... // No begin specified, using container begin. // Have range end '' // Got: 'Range[B:)' // // 2.5.1 also fails with the simpler STDIN: // // s[7] // // the program is expected to output: // // Have plain index 7 // Got: 'Index[7]' // // but with 2.5.1 it outputs: // // Have range spec... // Have range begin '7' // No end specified, using container end. // Got: 'Range[7:E)' // // This can be remedied to an extent by switching the #if 1 below // to be #if 0 enabling the collapsed optional code; however this // makes the presence of range-end indistinguishable from the // presence of a range-spec. // ----------------------------------------------- This email and any attached files contains company confidential information which may be legally privileged. it is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel.

1 0

[bind][phoenix] unified placeholders, yea or nay?
by Eric Niebler 29 May '12

29 May '12

I'm considering taking on as a side project the unification of the bind and phoenix placeholders, a perennial source of confusion and annoyance. I hesitate before beginning because it necessarily introduces some complexity into boost.bind, a very small, simple, and light-weight library. In particular, the unification would: 1) Cause boost.bind to depend on boost.proto. (I would do what I could to keep that dependency as slight as possible.) 2) Could not be supported on all platforms; e.g. not on borland or (gcc < 4) where the placeholders are actually static inline functions(!). (Peter, is this an ODR thing?) 3) Would introduce Phoenix behaviors into Bind, insofar as _1 is a lambda such that _1(42) evaluates to 42. At this point, it's not obvious to me that the benefits outweigh the costs. Opinions? Peter, I'd especially like to hear your thoughts. -- Eric Niebler BoostPro Computing http://www.boostpro.com

9 13

Re: [boost] [Intrusive] Cleaning up trailing white space
by Brian Wood 29 May '12

29 May '12

Olaf van der Spek <ml(a)vdspek.org> On Thu, May 17, 2012 at 1:12 AM, Brian Wood <woodbrian77(a)gmail.com> wrote: >> >> This is probably the easiest way to improve Boost. ?I hope authors will > Really? Why? It can be done with a simple sed script and applied either to individual libraries or all of Boost. It's a small detail, but I hope it gets some attention. I brought it to Ion's attention as I use the Intrusive library and take a number of steps to reduce the need for new hardware. I won't stop using the library if he doesn't do this, but the squeaky wheel gets the oil. Cheers, Brian Ebenezer Enterprises http://webEbenezer.net <http://webebenezer.net/>

10 16

[bind]bind question
by Max 28 May '12

28 May '12

Hi, I have the following code: bool do_something_conditional(int *handle, const boost::function<bool(int)> &pred); bool pred_a(int handle); bool pred_b(int handle, int n1, int n2); bool do_something(int *handle, int n1, int n2) { return do_something_conditional(handle, boost::bind(std::logical_and<bool>(), boost::not1(&pred_a), boost::bind(&pred_b, _1, n1, n2))); } But it does not compile. I have been not playing with bind stuff for some time. But I've reviewed the doc and some of my old 'bind' code, it seems correct to me. The error message, you know, is quite complicated for me to find a direct answer. Could anybody please help me? Thanks in advance. I'm using 1.39 with MS VS2008SP1 Best regards Max

4 6

[GettingStarted] request for adding Boost.Chrono
by Vicente J. Botet Escriba 28 May '12

28 May '12

Hi, could Boost.Chrono be added to the list of libraries that need to be built in http://www.boost.org/doc/libs/1_49_0/more/getting_started/windows.html#head… Best, Vicente

1 0

[io_base-utilities] Request for interest and/or comments.
by Vicente J. Botet Escriba 28 May '12

28 May '12

Hi, While refactoring the Boost.Chrono IO (version 2) I've created some utilities that could be of general use. * Manipulator Mixin It is is based on http://www.angelikalanger.com/Articles/Cuj/05.Manipulators/Manipulators.html. http://svn.boost.org/svn/boost/trunk/boost/chrono/io/utility/manip_base.hpp defines a class manip that can be used as follows class mendl: public manip<mendl> { public: explicit mendl(size_t how_many) : count(how_many) {} template <typename out_stream> void operator()(out_stream &out) const { for (size_t line = 0; line < count; ++line) { out.put(out.widen('\n')); } out.flush(); } private: size_t count; }; * std::ios_base Specific Pointers std::ios_base allows to create specific pointers indexed by xalloc() and retrieved by pword(). http://svn.boost.org/svn/boost/trunk/boost/chrono/io/utility/ios_base_state… defines a class ios_state_ptr class that provides the same interface that a smart ptr with some minor adaptations to a std::ios_base. template <typename Tag, typename T> class ios_state_ptr; The type T must be CopyConstructible. This class must be used as follows struct mytag {} struct myT { int i; }; ios_state_ptr<mytag, myT > ptr(ios); if (! ptr) { ptr.reset(new myT); } ptr->i =0; This class is not thread_safe and should be protected as other io functions if the user needs to use them in a multi-threaded environment; The user can use also ios_state_ptr for classes T that are DefaultConstructible, so that the type is created implicitly if not already created. ios_state_not_null_ptr<mytag, myT > ptr(ios); ptr->i =0; This class is not thread_safe. Boost.Chrono use it as follows namespace chrono { namespace detail { template<typename CharT> struct ios_base_data_aux { std::basic_string<CharT> time_fmt; std::basic_string<CharT> duration_fmt; public: ios_base_data_aux() : time_fmt(""), duration_fmt("") {} }; template<typename CharT> struct ios_base_data {}; } // namespace detail template<typename CharT> static inline std::basic_string<CharT> get_time_fmt(std::ios_base & ios) { ios_state_not_null_ptr<detail::ios_base_data<CharT>, detail::ios_base_data_aux<CharT> > ptr(ios); return ptr->time_fmt; } template<typename CharT> static inline void set_time_fmt(std::ios_base& ios, std::basic_string< CharT> const& fmt) { ios_state_not_null_ptr<detail::ios_base_data<CharT>, detail::ios_base_data_aux<CharT> > ptr(ios); ptr->time_fmt = fmt; } } The internal single call to xalloc should be done before main() to be thread safe. The library provide a initializer class xalloc_key_initializer that takes as parameter a tag class. namespace chrono { namespace detail { namespace /**/ { xalloc_key_initializer<detail::ios_base_data<char> > ios_base_data_aux_xalloc_key_initializer; xalloc_key_initializer<detail::ios_base_data<wchar_t> > wios_base_data_aux_xalloc_key_initializer; #if BOOST_CHRONO_HAS_UNICODE_SUPPORT xalloc_key_initializer<detail::ios_base_data<char16_t> > u16ios_base_data_aux_xalloc_key_initializer; xalloc_key_initializer<detail::ios_base_data<char32_t> > u32ios_base_data_aux_xalloc_key_initializer; #endif } // namespace } } * ios_flags ios_base allows also to create specific pointers indexed by xalloc() and retrieved by iword(). http://svn.boost.org/svn/boost/trunk/boost/chrono/io/utility/ios_base_state… defines a class template <typename Final> class ios_flags; providing an interface similar to "27.5.3.2 ios_base state functions [fmtflags.state] fmtflags flags() const; Returns: The format control information for both input and output. fmtflags flags(fmtflags fmtfl); Postcondition: fmtfl == flags(). Returns: The previous value of flags(). fmtflags setf(fmtflags fmtfl); Effects: Sets fmtfl in flags(). Returns: The previous value of flags(). fmtflags setf(fmtflags fmtfl, fmtflags mask); Effects: Clears mask in flags(), sets fmtfl & mask in flags(). Returns: The previous value of flags(). void unsetf(fmtflags mask); Effects: Clears mask in flags() " and that creates implicitly the index of the ios_base::iword() function once for a specific ios_flags<Final>. For example, Boost.Chrono use it as follows to store the use_symbol and use_local flags. class fmt_masks : public ios_flags<fmt_masks> { typedef ios_flags<fmt_masks> base_type; public: fmt_masks(std::ios_base& ios): base_type(ios) {} enum type { uses_symbol = 1 << 0, uses_local = 1 << 1 }; duration_style get_duration_style() { return (flags() & uses_symbol) ? duration_style::symbol : duration_style::prefix; } void set_duration_style(duration_style style) { if (style == duration_style::symbol) setf(uses_symbol); else unsetf(uses_symbol); } timezone get_timezone() { return (flags() & uses_local) ? timezone::local : timezone::utc; } void set_timezone(timezone tz) { if (tz == timezone::local) setf(uses_local); else unsetf(uses_local); } }; The internal single call to xalloc should be done before main() to be thread safe. The library provide a initializer class namespace detail { namespace /**/ { xalloc_key_initializer<fmt_masks > fmt_masks_xalloc_key_initializer; } // namespace } // namespace detail Do you see a design flaw on the design of these classes? Is there an interest to include them in Boost? Could these classes be associated iostreams? Best, Vicente

1 0

Sophisticated Email Virus
by Richard Scott 28 May '12

28 May '12

Good Afternoon All, Early this morning, I was the victim of a email virus which may have captured your email address from my address book. Hopefully, my antivirus software prevented that. If you receive a very terse but generally plausible message from me exhorting you to open an unnamed web site link, DO NOT open that link. This message might be transmitted from a third site using my email address. It will attempt to capture your email addresses and possibly information of an unknown sort and retransmit it to a third site for subsequent use. This could happen either immediately or months from now. For my part, my messages are generally not overly short or cryptic and I generally employ named links. Richard Scott

2 1

[1.50] [Config] Enhancing support of -fno-rtti on clang
by Michel Morin 27 May '12

27 May '12

When using clang with -fno-rtti, the use of `typeid` results in either compile-time errors or run-time errors. But Boost.Config did not define BOOST_NO_TYPEID for that case. So, for example, including any client header of BOOST_SP_TYPEID produced compiler errors on clang trunk with -fno-rtti. This was fixed in r78510 about a week ago: (http://svn.boost.org/trac/boost/changeset/78510) -#if !__has_feature(cxx_rtti) +#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_RTTI) # define BOOST_NO_RTTI #endif +#if !__has_feature(cxx_rtti) && !defined(BOOST_NO_TYPEID) +# define BOOST_NO_TYPEID +#endif If Boost would like to enhance the support of -fno-rtti on clang, it would be good to merge the fix into the release branch. I ran the test runner (clang trunk with -fno-rtti) for unpatched release branch and patched release branch. There was no regression and more than 1000 test results got improved. Regards, Michel

2 2

[pimpl] links
by Vicente J. Botet Escriba 26 May '12

26 May '12

Hi, where can I get the source and documentation for the proposed Boost.PImpl? The doc link points to a paper and the source link points to github. Best, Vicente

2 1

Schedule link broken for multiprecision doc
by Vicente J. Botet Escriba 26 May '12

26 May '12

Hi, the link http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h…. is broken. Best, Vicente

4 3

committing patches to other libraries (was [1.50.0] Beta schedule)
by Jeffrey Lee Hellrung, Jr. 26 May '12

26 May '12

:: bump :: On Tue, May 22, 2012 at 11:13 AM, Jeffrey Lee Hellrung, Jr. < jeffrey.hellrung(a)gmail.com> wrote: > On Tue, May 22, 2012 at 5:46 AM, Beman Dawes <bdawes(a)acm.org> wrote: > >> C++Now! is history, so it is high time to get the 1.50.0 beta out the >> door. >> >> Branches/release is now closed for all changes except by permission >> from a release manager. >> > > Request to merge > > https://svn.boost.org/trac/boost/changeset/78501 > > which just takes care of a shadowing warning on gcc. > > Couple things: > (a) I just went ahead and made this change on trunk a few days ago because > I stumbled into this warning myself, searched track, and saw that it was > already reported and had a patch (indirectly) attached; in retrospect, I > apologize if I stepped on anyone's (Jeremy's?) toes, and so I ask: Is there > a formal or informal protocol for applying relatively simple patches like > this one? > (b) Along the same lines, assuming permission is granted and given (a), > should I be merging this to release, or should that fall to the library > maintainer? > > Thanks, > > - Jeff > I was hoping to get some direction regarding the above before continuing to; specifically, what should be done about this particular changeset, and some guidelines for similar situations in the future. (I am aware of the recently revised release schedule, so disregard the "request to merge" in that context.) Thanks, - Jeff

1 0

[range] Will Boost.Range be merged
by Barend Gehrels 26 May '12

26 May '12

Hi, Will Boost.Range (including the change of boost::size from signed to unsigned) be merged into release? Regards, Barend

1 0

[python] incorrect use of keywords and, or, etc
by lcaminiti 25 May '12

25 May '12

Hello all, Boost.Python uses operator keywords in macro expansion. This is a bad idea because on some compilers like MSVC that implement and, or, etc using macros #define to &&, ||, these macros will not expand correctly when ciso646 is included before including python.hpp. #include <ciso646> // boost/python/operators.hpp BOOST_PYTHON_BINARY_OPERATOR(and, rand, &) BOOST_PYTHON_BINARY_OPERATOR(or, ror, |) ... This will actually expand to: BOOST_PYTHON_BINARY_OPERATOR(&&, rand, &) BOOST_PYTHON_BINARY_OPERATOR(||, ror, |) And then expand the macro causing a compiler error because the operator code will have names like op_&&, op_||, etc instead of the intended op_and, op_or, etc. An easy and safe fix should be to change the macro to move the _ to the macro call: BOOST_PYTHON_BINARY_OPERATOR(_and, rand, &) BOOST_PYTHON_BINARY_OPERATOR(_or, ror, |) Now _and, _or, etc are no longer keywords so it's safe to use them. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-python-incorrect-use-of-keywords-a… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[range] Boost.Range induced regression, is there somewhere a change?
by Barend Gehrels 25 May '12

25 May '12

Hi, Is there something changed in Boost.Range? Background: I just noticed that there appeared many failing issues (yellow squares) in the Boost.Geometry regression matrix here: http://www.boost.org/development/tests/trunk/developer/geometry.html I checked the assemble square and it gives me an assertion: Assertion `id.ring_index >= -1 && id.ring_index < boost::size(interior_rings(polygon))' Because this did not use to be the case, I did run the test on my local machine and it was OK. Then I updated some Boost libraries (manually, separately) and as soon as I updated Boost.Range this exception did appear. So the regression is somehow caused by a change in Boost.Range. I did not yet research it further, it might be that we do something wrong here that was previously accepted but now is not, but it still stays an unexpected regression... Is there someone who has any idea what introduced this? Thanks, Barend

1 1

C++ Standards Committee membership for Boost?
by Beman Dawes 25 May '12

25 May '12

The relationship between Boost and the C++ Standards Committee has been strictly informal. That's been fine, particularly given that most Boost moderators were members of the standards committee and regularly attended meetings. As the standards committee gears up to accept library proposals, the relationship is getting even closer. I believe it would be advantageous for Boost to join the C++ committee as a voting member. Procedurally, that would mean joining the INCITS (www.incits.org) PL22.16, which is the US national body for C++ standardization. Boost is consider US domiciled in ISO-speak. The advantages of joining include: * We get to participate in formal votes. Right now, we only participate in straw votes. * Boosters would be able to attend committee meetings by right rather than as a courtesy. * Boosters would be able to participate in committee mailing lists with less hoops to jump through. * Psychologically, it may give us a bit more weight in committee matters. Comments? Opinions? --Beman

8 14

regression tests fail with no error?
by lcaminiti 24 May '12

24 May '12

Hello all, Some of my library regression tests occasionally fail like this: http://www.boost.org/development/tests/release/developer/Sandia-darwin-inte… If you follow the link, there is no actual error. Plus the tests sometimes it fails (with no actual error) and other times it passes (as it should). Is this just a problem with the regression test parsing script? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-regression-tests-fail-with-no-erro… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[1.50.0] Beta schedule
by Beman Dawes 24 May '12

24 May '12

C++Now! is history, so it is high time to get the 1.50.0 beta out the door. Branches/release is now closed for all changes except by permission from a release manager. Unless there are strong objections, I suggest we close branches\release for all changes next Monday, May 28, and ship the beta release as soon after that as a RC can be built and tested. I'm about to post a separate message discussing the length of beta periods. --Beman

19 51

[MSM] Single event, multiple orthogonal submachines
by Andrew Hundt 23 May '12

23 May '12

I'm trying to deal with having multiple orthogonal submachines that process one event containing data. I have a contrived example that hopefully conveys the issue. Suppose I am hoping to create a state machine "Game2D" with a set of orthogonal submachines that guard certain transitions based on each other, and I would like some events to be processed by multiple submachines. Parent Machine: Game2D Event: CharacterStatus - contains character position and velocity Submachines: IsMoving - changes state based on CharacterStatus CorrectPosition - updates position based on CharacterStatus CharacterStatusUpToDate - times out to an error state if CharacterStatus hasn't been received for a while EnemyAlive - doesn't process CharacterStatus RunSystem - guards some transitions based on the state of IsMoving Since some, but not all of these submachines needs the "CharacterStatus" event, what is the best way to make sure they all get it when I call Game2D.process_event(CharacterStatus)? I want to be able to reuse these pieces, and keep things as simple as possible. Does this seem like an ok approach? Should I simply have a state "UpdateCharacterStatus" that directly updates each of these objects then creates an event to transition away, or something else entirely? Cheers! Andrew Hundt

2 1

Release schedule related updates
by Beman Dawes 23 May '12

23 May '12

https://svn.boost.org/trac/boost/wiki/ReleaseSchedule has been updated to reflect experience and lengthen the beta period. https://svn.boost.org/trac/boost/wiki/ReleasePractices/ManagerCheckList has been updated to reflect the importance of the calendar. The Google calendar itself has been updated for releases 1.50.0, 1.51.0, and 1.52.0. I'm looking into ways to queue postings of release milestones so they get sent automatically and don't get forgotten. Thanks, --Beman

1 0

[ot] choosing a build system
by Nathan Ridge 23 May '12

23 May '12

Hello, I am developing a new C++ library (unrelated to Boost) and I need to choose a build system for it. I had originally planned to use Boost.Build, because I figured that it would be particularly suitable for a C++ library, and because I've come to associate Boost with high quality and excellence. However, recently I've heard talk of Boost switching its own build system from Boost.Build to CMake (in fact, the currently active thread about modularization suggests that this change is imminent). My understanding is that Boost is the primary user of Boost.Build, and therefore I am concerned about what this switch means for the future of Boost.Build. Do you think choosing Boost.Build as the build system for a project is still a sound choice, or am I better off choosing something else like CMake? More generally, what build system would you recommend for a C++ library? My requirements for the build system are the following: - straightforward support for multiple variants of the build (32-bit vs. 64-bit, debug vs. release, static vs. shared, etc.), including coexistence of multiple variants on the same machine - general ease of use (for the library writer and library users) - suitability for a C++ project - cross-platform, FOSS Any thoughts are appreciated. Thanks, Nate

26 59

spirit classic modularization
by Dave Abrahams 22 May '12

22 May '12

While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories: https://github.com/boost-lib/spirit https://github.com/boost-lib/spirit_classic The manifest entries begin here, and as you can see, are quite long for these two libraries: https://github.com/ryppl/boost-modularize/blob/master/manifest.txt#L643 This is mostly due to the limited expressivity of the manifest language, but regardless... The question, for Spirit developers: which arrangement is better? Should both spirits go back into a single repository? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 4

[test] mingw 4.5, 4.6, compile failure with trunk
by Beman Dawes 22 May '12

22 May '12

..\..\../boost/test/utils/runtime/config.hpp: In function 'void boost::runtime::putenv_impl(boost::runtime::cstring, boost::runtime::cstring)': ..\..\../boost/test/utils/runtime/config.hpp:95:51: error: 'putenv' was not declared in this scope This is preventing me from testing other Boost libraries that use Boost.Test:-( --Beman

2 2

[releases] How long between beta and final release?
by Beman Dawes 22 May '12

22 May '12

Although there has been general agreement that there should be more time between beta and final releases, we haven't nailed down the exact duration. To get discussion started, I'll propose five weeks as the target time between beta and final release. Since there needs to be a week for final regression tests to cycle and release candidates to be tested, that would allow four weeks for beta fixes to be incorporated. Comments? --Beman

1 0

Using Boost with IBM Rhapsody and UML?
by David Hagood 22 May '12

22 May '12

Does anybody have experience pulling Boost into IBM's Rhapsody UML tool, such that Rhapsody will be able to use Boost in UML models and UML to C++ codegen?

2 1

[decimal] Proposed portable implementation ofstd::decimal
by Josh Quigley 22 May '12

22 May '12

Hi all. A first draft of this library is available at https://sourceforge.net/projects/stddecimal/ Runs on MSVC10 and gcc 4.6.3. Wraps the Intel implementation only, Until we resolve the licencing issue, top-level README contains detailed instructions about where to get 3rd party code and what to do with it. I'm keen on feedback on a particular point (although all feedback is of course welcome!): The current project can parse and execute the test cases maintained by Mike Cowlishaw from http://speleotrove.com/decimal/ (referred to as the Test Cases). To be completely clear, I also have normal, interface testing test cases, I am *not* talking about those below. - Question: How useful do people feel the Test Cases to be? I originally expected 99% of these tests to pass, but it turns out that most of them require: - The operands to be parsed and stored at the precision they appear in the Test Case file - The operation to be performed at precision of the operands - The high precision result to be rounded to the precision required by the Test Cases. - The test inputs to be parsed with correct rounding in underflow situations (not required by IEEE afaik) The above requirements are based on my experience with the tests - it is possible I'm making a blunder somewhere. Since the Test Cases are really testing the 3rd party library, an argument could be made they are not essential, or even desirable. I'm inclined to think they would be very, very nice to have, as they would give users a lot of confidence - I suspect user uptake would be poor without this confidence. So... what do people think? Regards, Josh. (PS gmail seems to be confused about who 'boost' is, so apologies for the cross-posts!)

2 2

Re: [boost] Boost Modularization: did we get it right?
by Oliver Kowalke 21 May '12

21 May '12

The headers are moved into directory'include' - how does the build system handle includes (header from other boost libs)? At least I get error that header xyz is not found if I execute the tests using bjam. Oliver -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

10 44

Boost Modularization: did we get it right?
by Dave Abrahams 21 May '12

21 May '12

Hi All, As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful. Thanks! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

16 28

Re: [boost] [Boost-commit] svn:boost r78350 - in sandbox/pool: boost/pool libs/pool/test
by Steven Watanabe 21 May '12

21 May '12

AMDG On 05/06/2012 06:29 AM, svart.riddare(a)gmail.com wrote: > Author: edupuis > Date: 2012-05-06 09:29:40 EDT (Sun, 06 May 2012) > New Revision: 78350 > URL: http://svn.boost.org/trac/boost/changeset/78350 > > Log: > Added new get_size() member function for pool, static_pool and object_pool. This fixes #6865. Please reopen this and any other tickets you've closed like this. Tickets are not fixed until they're at least fixed in the trunk and preferably in release. > Added: > sandbox/pool/libs/pool/test/test_bug_6865.cpp (contents, props changed) > Text files modified: > sandbox/pool/boost/pool/object_pool.hpp | 5 +++++ > sandbox/pool/boost/pool/pool.hpp | 10 ++++++++++ > sandbox/pool/boost/pool/static_pool.hpp | 5 +++++ > 3 files changed, 20 insertions(+), 0 deletions(-) > <snip> In Christ, Steven Watanabe

2 1

boost/range/algorithm/for_each.hpp - enable_if.hpp
by Richard Crossley 20 May '12

20 May '12

There would seem to be a missing include for enable_if in /boost/range/algorithm/for_each.hpp... shows up from change 18502.

1 0