- 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