- Boost - lists.preview.boost.org

Boost.Logging 1.51 Using VS2012.
by syvyi 09 Jan '13

09 Jan '13

Hello, my application which was successfully compiled on VS2010 brings the next errors using VS2012 c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(227): error C2664: 'std::pair<_Ty1,_Ty2> boost::log_mt_nt5::basic_attribute_set<CharT>::insert(const std::pair<const boost::log_mt_nt5::basic_slim_string<CharT>,boost::log_mt_nt5::basic_attribute_set<CharT>::mapped_type> )' : cannot convert parameter 1 from 'std::pair<_Ty1,_Ty2>' to 'const std::pair<_Ty1,_Ty2> &' 4> with 4> [ 4> _Ty1=boost::log_mt_nt5::basic_attribute_set<char>::iter<false>, 4> _Ty2=bool, 4> CharT=char 4> ] 4> and 4> [ 4> _Ty1=std::basic_string<char,std::char_traits<char>,std::allocator<char>>, 4> _Ty2=boost::shared_ptr<boost::log_mt_nt5::attribute> 4> ] 4> and 4> [ 4> _Ty1=const boost::log_mt_nt5::basic_slim_string<char>, 4> _Ty2=boost::log_mt_nt5::basic_attribute_set<char>::mapped_type 4> ] 4> Reason: cannot convert from 'std::pair<_Ty1,_Ty2>' to 'const std::pair<_Ty1,_Ty2>' 4> with 4> [ 4> _Ty1=std::basic_string<char,std::char_traits<char>,std::allocator<char>>, 4> _Ty2=boost::shared_ptr<boost::log_mt_nt5::attribute> 4> ] 4> and 4> [ 4> _Ty1=const boost::log_mt_nt5::basic_slim_string<char>, 4> _Ty2=boost::log_mt_nt5::basic_attribute_set<char>::mapped_type 4> ] 4> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(226) : while compiling class template member function 'std::pair<_Ty1,_Ty2> boost::log_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>::add_attribute_unlocked(const std::basic_string<_Elem,_Traits,_Alloc> &,const boost::shared_ptr<T> &)' 4> with 4> [ 4> _Ty1=boost::log_mt_nt5::basic_attribute_set<char>::iter<false>, 4> _Ty2=bool, 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, 4> _Elem=char, 4> _Traits=std::char_traits<char>, 4> _Alloc=std::allocator<char>, 4> T=boost::log_mt_nt5::attribute 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\severity_feature.hpp(188) : see reference to function template instantiation 'std::pair<_Ty1,_Ty2> boost::log_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>::add_attribute_unlocked(const std::basic_string<_Elem,_Traits,_Alloc> &,const boost::shared_ptr<T> &)' being compiled 4> with 4> [ 4> _Ty1=boost::log_mt_nt5::basic_attribute_set<char>::iter<false>, 4> _Ty2=bool, 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, 4> _Elem=char, 4> _Traits=std::char_traits<char>, 4> _Alloc=std::allocator<char>, 4> T=boost::log_mt_nt5::attribute 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\channel_feature.hpp(212) : see reference to class template instantiation 'boost::log_mt_nt5::sources::basic_logger<CharT,FinalT,ThreadingModelT>' being compiled 4> with 4> [ 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(315) : see reference to class template instantiation 'boost::log_mt_nt5::sources::channel<ChannelT>::apply<BaseT>' being compiled 4> with 4> [ 4> ChannelT=std::string, 4> BaseT=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(49) : see reference to class template instantiation 'boost::log_mt_nt5::sources::aux::inherit_logger_features::apply<PrevT,T>' being compiled 4> with 4> [ 4> PrevT=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> T=boost::log_mt_nt5::sources::channel<std::string> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\aux_\preprocessed\plain\apply.hpp(63) : see reference to class template instantiation 'boost::mpl::apply_wrap2<F,T1,T2>' being compiled 4> with 4> [ 4> F=boost::log_mt_nt5::sources::aux::inherit_logger_features, 4> T1=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> T2=boost::log_mt_nt5::sources::channel<std::string> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\aux_\preprocessed\plain\reverse_fold_impl.hpp(81) : see reference to class template instantiation 'boost::mpl::apply2<F,T1,T2>' being compiled 4> with 4> [ 4> F=boost::log_mt_nt5::sources::aux::inherit_logger_features, 4> T1=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> T2=boost::log_mt_nt5::sources::channel<std::string> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\mpl\reverse_fold.hpp(41) : see reference to class template instantiation 'boost::mpl::aux::reverse_fold_impl<N,First,Last,State,BackwardOp,ForwardOp>' being compiled 4> with 4> [ 4> N=2, 4> First=boost::mpl::v_iter<boost::mpl::vector2<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>>,0>, 4> Last=boost::mpl::v_iter<boost::mpl::vector2<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>>,2>, 4> State=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> BackwardOp=boost::log_mt_nt5::sources::aux::inherit_logger_features, 4> ForwardOp=boost::mpl::arg<1> 4> ] 4> c:\program files (x86)\boost\boost_1_51_0\boost\log\sources\basic_logger.hpp(338) : see reference to class template instantiation 'boost::mpl::reverse_fold<Sequence,State,BackwardOp>' being compiled 4> with 4> [ 4> Sequence=boost::log_mt_nt5::sources::features<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>>, 4> State=boost::log_mt_nt5::sources::basic_logger<char,manster::logger::manster_logger_mt,boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>>, 4> BackwardOp=boost::log_mt_nt5::sources::aux::inherit_logger_features 4> ] 4> d:\sankom\manster\manster\manster\manster_logger.h(160) : see reference to class template instantiation 'boost::log_mt_nt5::sources::basic_composite_logger<CharT,FinalT,ThreadingModelT,FeaturesT>' being compiled 4> with 4> [ 4> CharT=char, 4> FinalT=manster::logger::manster_logger_mt, 4> ThreadingModelT=boost::log_mt_nt5::sources::multi_thread_model<boost::log_mt_nt5::aux::light_rw_mutex>, 4> FeaturesT=boost::log_mt_nt5::sources::features<boost::log_mt_nt5::sources::severity<severity_level>,boost::log_mt_nt5::sources::channel<std::string>> 4> ] What is the solution ? -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Logging-1-51-Using-VS2012-tp464114… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 7

Requesting permission to merge 82408 to release
by Glen Fernandes 09 Jan '13

09 Jan '13

82408 is a fix for #7867 (found by Mathias) where BOOST_NO_EXCEPTIONS was not honored. Glen

2 1

[non-instrusive move] interest in new library?
by THOMAS JORDAN 09 Jan '13

09 Jan '13

Hi, Would there be interest for Boost in a small library providing a simple, non-instrusive emulation of move semantics for C++03 (though it could also be used in a C++11 environment)? It consists of a small number of 'move' function overloads, plus a trait class. It can be used facilitate move semantics/value-orientated programming in environments which lack/forbid C++11 or intrusive move libraries, and facilitate/force copy-elision and RVO optimisations in certain situations where they might otherwise not occur. Its mechanism is as follows: it detects at compile-time if the type of the argument(s) has a member swap function, and if so, it performs a swap, otherwise is calls the regular assignment operator. It can be used to provide an emulation of: move-assignment between lvalues moving an rvalue to an lvalue moving an lvalue to a temporary. It also supports moving between built-in arrays. Example use-cases are: //returning a value std::string foo(std::string s) { //append something to s //... //compiler can perform rvo, if just used 'return s;' compiler would not perform nrvo return move(s); } //passing a value std::string s("hello"); void bar(std::string s) {...} foo(s); //copy foo(move(s)); //move //moving a value into place void MyClass::MyClass(std::string s) { //move value into default constructed member move(s, s_); }

1 0

[log] v2 beta 1 mini-review request
by Andrey Semashev 09 Jan '13

09 Jan '13

Hi, It's been a while since Boost.Log v1 was reviewed back in 2010. Here is the review result: http://lists.boost.org/boost-announce/2010/03/0256.php But the time was spent for purpose as the library took substantial changes. I've just uploaded the v2 beta 1 to the SourceForge project page: Code: http://sourceforge.net/projects/boost-log/files/boost-log-2.0-beta1-r800.zi… Docs: http://boost-log.sourceforge.net/libs/log/doc/html/index.html SVN: svn co https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log I must say this is not the final release; the docs are not quite complete (in particular, the Extending the library section has not been updated yet) and the code may have rough edges here and there. But it is good enough to review the changes, or the whole library if you haven't got acquainted with v1. The change log is quite big, you can see it here: http://boost-log.sourceforge.net/libs/log/doc/html/log/changelog.html I'll just mention the most significant highlights here: - Character type support unified. Log records, core, filters and most sinks have been made character type agnostic. It is possible now to emit log records with messages with different character types in a single application. Character code conversion will be performed as needed when formatting log records. - Filters and formatters were rewritten and are now based on Boost.Phoenix. Unified attribute value placeholders in filters and formatters. The template expressions now reside in the common namespace "expressions". - Added support for attribute keywords in filters and formatters. Attribute keywords identify particular attribute values within log records; their use significantly simplify template expressions syntax. - Reworked attribute value extraction. In fact, the old extraction API has been split into visitation and the new extraction APIs. In conjunction with attribute keywords this makes extracting attribute values very simple. - Introduced a concept of a default sink which is used when no sinks are registered in the logging core. The sink outputs formatted log records to the console. - Trivial logging now outputs to console by default. Actually, trivial logging logs to the default sink by default. - Asynchronous sink now supports customizing record queueing strategies. New bounded queue strategies solve the problem of log records piling in the queue. - Attributes are now implemented following the pimpl pattern; it is no longer needed to create attributes using make_shared or new. This simplified attribute registration code. - Channel logger now allows changing channel name after construction. I don't plan any major changes to the code until the final release, unless something critical comes up during the review. I will keep updating the docs in the coming days and will request permission to merge to Boost when done. Comments are welcome.

3 4

[interprocess] (OS X) waiting on condition variable = CPU 100% + fans running loud
by Francisco Lopes 08 Jan '13

08 Jan '13

Hi, I was implementing a kind of server using shared memory. The server should keep idle, waiting for a request and I do this by waiting on a condition variable, of course. I then noticed my fans running high when I let the server waiting a little longer while testing and discovered this happens simply because of some busy loop implementation for condition waiting. Is there any reason for that? Given the interprocess library age, there's no way for implementing a non-busy interprocess condition variable waiting available? https://svn.boost.org/trac/boost/ticket/6108 Regards, Francisco Lopes

6 15

Re: [boost] [interprocess] (OS X) waiting on condition variable = CPU 100% + fans running loud
by Peter Dimov 08 Jan '13

08 Jan '13

> > Clang has std::atomic though, doesn't it? It probably supports the > > __sync intrinsics as well. > > Actually, it seems to support the even better __atomic intrinsics: > > http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html Also here: http://libcxx.llvm.org/atomic_design_a.html

2 2

Re: [boost] [interprocess] (OS X) waiting on condition variable = CPU 100% + fans running loud
by Peter Dimov 08 Jan '13

08 Jan '13

> Clang has std::atomic though, doesn't it? It probably supports the __sync > intrinsics as well. Actually, it seems to support the even better __atomic intrinsics: http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html

1 0

[release] permission to merge (fix show-stopper in 1.53-rc)
by Oliver Kowalke 08 Jan '13

08 Jan '13

I'd like to merge trunk to release in order to fix bug #7864 (unresolved symbols on Windows)

2 2

Re: [boost] new proposal: order statistics tree (Szymon Wojciechowski)
by Leo Goodstadt 07 Jan '13

07 Jan '13

> On Fri, Jan 04, 2013; 4:33am, "Rahul Sr" <srivasrrahul(a)gmail.com> wrote: > > On Wed, Jan 2, 2013 at 3:46 PM, Szymon Wojciechowski wrote: > > Briefly, it is container which allows logarithmic inserting, searching and > > erasing as in set, but additionally it permits to access elements via > > numerical value - key order. > > Will it be like this? > http://stackoverflow.com/questions/11230734/c-stl-order-statistic-tree > http://www.opensource.apple.com/source/llvmgcc42/llvmgcc42-2336.9/libstdc++… The libstdc++ policy based data structure (pb_ds) order statistic tree only has "set" behaviour. It takes a certain amount of extra work to use it as a replacement for multiset and multimap. They recommend using a set (tree) of lists to use pb_ds::tree like a multiset. However, this obviously doesn't work for order_statistic tree: each of the duplicates is only counted once (each list of duplicates is a single element in the tree). Does your order statistic tree allow duplicates? Leo Goodstadt

2 1

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[CMake] current status of project
by Алексей Кутумов 07 Jan '13

07 Jan '13

Hello! I am new to boost community and i want to know about current status of "CMake modularization" project. I try to build boost according this page: https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus, and i`ve got some issues during configuring and building under win32, and i have some ideas how to fix them, but i didn`t see any activity since May 2012. I see Is this project alive?

1 0

[utf8_codecvt_facet]
by Robert Ramey 06 Jan '13

06 Jan '13

change Revision: 81616 Author: marshall Date: 11:12:42 AM, Wednesday, November 28, 2012 Message: Fixed incorrect 'const' param for utf8_codecvt_facet::do_length ---- Modified : /trunk/boost/detail/utf8_codecvt_facet.hpp This change causes the a failure in the serialization library test suite with "test_utf8_codecvt" on all platforms which use the gcc standard library. I'm not sure what motivated the change or what it addressed but I'm pretty sure it's causing this (and a couple other) test failures. Note that all the failures are related to usage of wchar_t - perhaps that helps. Note that the test is part of the serialization library test suite - but it has nothing to do with serialization per se and doesn't use any of the serialization library. It just happens to be there because there was no more convenient place to put it. Marshall - could you please look into this? Robert Ramey

2 9

[Release][Spirit] Asking for approval to merge bugfix
by Hartmut Kaiser 06 Jan '13

06 Jan '13

Hey, I somehow missed to merge one commit from trunk to the release branch (see attached). May I commit this to fix a compilation problem in Spirit? The patch is very low risk as it just renames a parameter. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 4

[Locale] Security bug announcement - UTF-8 validation
by Artyom Beilis 06 Jan '13

06 Jan '13

Hello, Boost.Locale library in Boost 1.48 to 1.52 including has a security flow. boost::locale::utf::utf_traits accepted some invalid UTF-8 sequences. Applications that used these functions for UTF-8 input validation could expose themself to security threats as invalid UTF-8 sequece would be considered as valid. This bug is fixed in upcoming Boost 1.53. For more details see: https://svn.boost.org/trac/boost/ticket/7743 Users who can't upgrade to the latest versions may apply the following patch to fix the problem. http://cppcms.com/files/locale/boost_locale_utf.patch Regards, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

7 9

[config] MSCV 10 defines BOOST_NO_CXX11_HDR_TUPLE with a C++03 implementation
by Vicente J. Botet Escriba 05 Jan '13

05 Jan '13

Hi, The current implementation of boost::make_unique_locks needs a std::tuple with C++11 move semantics.* *MSCV 10 provides <tuple> and rvalue references so that BOOST_NO_CXX11_HDR_TUPLE and BOOST_NO_CXX11_RVALUE_REFERENCES are not defined. However I suspect that the implementation provided by <tuple> with this version is the one corresponding to TR1 and doesn't provide move semantics as the message in http://tinyurl.com/atjdoh3 could let think. Could someone confirm my suspicion?* *Is there a way to request MSVC 10 to not import TR1 files? Should BOOST_NO_CXX11_HDR_TUPLE be defined for MSVC 10 as it doesn't implements the c++11 semantics while BOOST_NO_HDR_TUPLE could be undefined? * *Best, Vicente ** Test output: id - thread - make_unique_locks__mutex_p / msvc-10.0 Rev 82343 / Thu, 3 Jan 2013 23:15:13 +0000 *Report Time: *Sat, 5 Jan 2013 12:53:31 +0000 Compile [2013-01-04 08:34:35 UTC]: fail call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"c:\boost\regression\trunk\results\boost\bin.v2\libs\thread\test\make_unique_locks__mutex_p.test\msvc-10.0\debug\threading-multi\sync\mutual_exclusion\locks\unique_lock\cons\make_unique_locks_mutex_pass.obj.rsp" make_unique_locks_mutex_pass.cpp c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\tuple(79) : error C2558: class 'boost::unique_lock<Mutex>' : no copy constructor available or copy constructor is declared 'explicit' with [ Mutex=boost::mutex ] c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\tuple(77) : while compiling class template member function 'std::tr1::_Cons_node<_Car,_Cdr>::_Cons_node(const std::tr1::_Cons_node<_Car,_Cdr> &)' with [ _Car=boost::unique_lock<boost::mutex>, _Cdr=std::tr1::_Cons_node<boost::unique_lock<boost::mutex>,std::tr1::_Cons_node<boost::unique_lock<boost::mutex>,std::tr1::_Tuple_type<std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil>::_Type>> ] c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\tuple(479) : see reference to class template instantiation 'std::tr1::_Cons_node<_Car,_Cdr>' being compiled with [ _Car=boost::unique_lock<boost::mutex>, _Cdr=std::tr1::_Cons_node<boost::unique_lock<boost::mutex>,std::tr1::_Cons_node<boost::unique_lock<boost::mutex>,std::tr1::_Tuple_type<std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil,std::tr1::_Nil>::_Type>> ] ..\libs\thread\test\sync\mutual_exclusion\locks\unique_lock\cons\make_unique_locks_mutex_pass.cpp(41) : see reference to class template instantiation 'std::tr1::tuple<_Arg0,_Arg1,_Arg2,_Arg3,_Arg4,_Arg5,_Arg6,_Arg7,_Arg8,_Arg9>' being compiled with [ _Arg0=boost::unique_lock<boost::mutex>, _Arg1=boost::unique_lock<boost::mutex>, _Arg2=boost::unique_lock<boost::mutex>, _Arg3=std::tr1::_Nil, _Arg4=std::tr1::_Nil, _Arg5=std::tr1::_Nil, _Arg6=std::tr1::_Nil, _Arg7=std::tr1::_Nil, _Arg8=std::tr1::_Nil, _Arg9=std::tr1::_Nil * *

1 0

[Range] Proposal: a sub-maintainer of Boost.Range
by Michel Morin 05 Jan '13

05 Jan '13

Dear Neil, Dear Nate, First I'd like to say thank you for your library, Neil. It is a very useful library and it's great fun to writing codes with range adaptors. Boost.Range is one of the most important Boost libraries that are not yet added to the Standard. I know that Neil has made an effort to make time for developing the library, but recently making time for development seems difficult. And there are several open tickets of trivial bugs (e.g. #5603, #6110). Considering this situation, I'd like to make a proposal about Boost.Range: ** Adding a sub-maintainer to Boost.Range ** This reduces author's maintenance burden and also helps more stable development of the library. I recommend Nathan Ridge as a sub-maintainer of Boost.Range. His knowledge, experiences and contribution to Boost are great. If both of Neil and Nate accept the proposal, and if Nate needs some support for the start-up, I'll try my best to support him. I also believe that Jeff will also support him ;) Neil, what do you think about this proposal? I would appreciate and respect any of your reply. Yours sincerely, Michel

11 42

[smart_ptr] error with nullptr_t
by Vicente J. Botet Escriba 05 Jan '13

05 Jan '13

Hi, next follows a compile error with clang 3.1 c++11 just including #include <boost/shared_ptr.hpp> iMac-de-Vicente-Botet-Escriba:test viboes$ time bjam toolset=clang-3.1x ts_ -q ...patience... ...found 1100 targets... ...updating 50 targets... clang-darwin.compile.c++ ../../../bin.v2/libs/thread/test/test_so.test/clang-darwin-3.1x/debug/threading-multi/test_so.o In file included from ../example/test_so.cpp:6: In file included from ../../../boost/shared_ptr.hpp:17: ../../../boost/smart_ptr/shared_ptr.hpp:344:22: error: non-friend class member 'nullptr_t' cannot have a qualified name shared_ptr( std::nullptr_t ) BOOST_NOEXCEPT : px( 0 ), pn() // never throws ~~~~~^ ../../../boost/smart_ptr/shared_ptr.hpp:344:33: error: expected ';' at end of declaration list shared_ptr( std::nullptr_t ) BOOST_NOEXCEPT : px( 0 ), pn() // never throws ^ ;

9 22

[Range] pop_front() / pop_back() docs for iterator_range?
by Olaf van der Spek 04 Jan '13

04 Jan '13

Hi, Where are pop_front() and pop_back() for iterator_range documented? Can't find them at http://www.boost.org/doc/libs/1_52_0/libs/range/doc/html/range/reference/ut… Am I looking in the wrong place or are they missing? -- Olaf

3 3

Request permission to merge [82349]
by Peter Dimov 04 Jan '13

04 Jan '13

Release managers, May I please merge revision 82349 to release? It's a documentation update for shared_ptr.

3 4

[Release managers] Permission to rollback Boost.Thread breaking changes
by Vicente J. Botet Escriba 04 Jan '13

04 Jan '13

Hi, I would like to apply the following patch to trunk and release branch to avoid the Boost.Thread breaking changes. * [@http://svn.boost.org/trac/boost/ticket/6229 #6229] Rename the unique_future to future following the c++11. * [@http://svn.boost.org/trac/boost/ticket/6266 #6266] Breaking change: thread destructor should call terminate if joinable. * [@http://svn.boost.org/trac/boost/ticket/6269 #6269] Breaking change: thread move assignment should call terminate if joinable. This will let us the time to discuss the best way to manage with this breaking changes. Is someone against this late change? Best, Vicente svn diff boost/thread libs/thread Index: boost/thread/detail/config.hpp =================================================================== --- boost/thread/detail/config.hpp (revision 82295) +++ boost/thread/detail/config.hpp (working copy) @@ -78,9 +78,9 @@ #define BOOST_THREAD_RVALUE_REFERENCES_DONT_MATCH_FUNTION_PTR #endif -// Default version is 3 +// Default version #if !defined BOOST_THREAD_VERSION -#define BOOST_THREAD_VERSION 3 +#define BOOST_THREAD_VERSION 2 #else #if BOOST_THREAD_VERSION!=2 && BOOST_THREAD_VERSION!=3 && BOOST_THREAD_VERSION!=4 #error "BOOST_THREAD_VERSION must be 2, 3 or 4" Index: libs/thread/src/win32/thread.cpp =================================================================== --- libs/thread/src/win32/thread.cpp (revision 82295) +++ libs/thread/src/win32/thread.cpp (working copy) @@ -12,7 +12,7 @@ #ifndef WINVER #define WINVER 0x400 #endif -#define BOOST_THREAD_VERSION 3 +//#define BOOST_THREAD_VERSION 3 #include <boost/thread/thread.hpp> #include <boost/thread/once.hpp> Index: libs/thread/src/pthread/thread.cpp =================================================================== --- libs/thread/src/pthread/thread.cpp (revision 82295) +++ libs/thread/src/pthread/thread.cpp (working copy) @@ -6,7 +6,7 @@ // Distributed under the Boost Software License, Version 1.0. (See accompanying // file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) -#define BOOST_THREAD_VERSION 3 +//#define BOOST_THREAD_VERSION 3 #include <boost/thread/detail/config.hpp> #include <boost/thread/thread.hpp>

2 9

[1.53.0] Beta release candidates available
by Marshall Clow 04 Jan '13

04 Jan '13

Release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: d5a45d0e08a14d5fb0965fe675d76ac6 *boost_1_53_0_beta1_rc1.tar.gz 89a6084458cd9f0e136c4b5292265461 *boost_1_53_0_beta1_rc1.tar.bz2 2a8897e04c59ccaf39189568f6966d60 *boost_1_53_0_beta1_rc1.zip 4cdf5a71d46e1115ca0c413f5b139a54 *boost_1_53_0_beta1_rc1.7z Thanks, --The release managers

7 7

[atomic] building with --layout=system, mingw, bug #7482
by Tim Blechmann 04 Jan '13

04 Jan '13

hi, i need some help with resolving issue #7482: for some reason it seems to build a static libboost_atomic, although it has to be a shared library. could someone with more insights in this platform have a look, what's going wrong (and why the library is static)? unfortunately i neither have access to mingw, nor am i too familiar with the boost build infrastructure ... thanks, tim

3 3

Upgrade mailman to 2.1.15
by DongInn Kim 04 Jan '13

04 Jan '13

Dear All, If it is not too busy time tomorrow, can we upgrade mailman from 2.1.12 to 2.1.15? I am planning to upgrade it on Friday, Jan 4th, 2013 and it won't take long to upgrade it. Date: Friday, Jan 4th, 2013. Time: - 4:00am-4:10am Pacific US time - 5:00am-5:10am Mountain US time - 6:00am-6:10am Central US time - 7:00am-7:10am Eastern US time - 12:00pm-12:10pm GMT Please let me know if you have any questions or suggestions. Regards, -- - DongInn

1 1

Release managers: Boost.Thread breaking changes in 1.53
by Vicente J. Botet Escriba 04 Jan '13

04 Jan '13

Hi, there has been some threads about the following Boost.Thread breaking change in release 1.53. "Breaking changes when BOOST_THREAD_VERSION==3 (Default value since Boost 1.53): There are some new features which share the same interface but with different behavior. These breaking features are provided by default when BOOST_THREAD_VERSION is 3, but the user can however choose the version 2 behavior by defining the corresponding macro. As for the deprecated features, these broken features will be only available until boost 1.55. * [@http://svn.boost.org/trac/boost/ticket/6229 #6229] Rename the unique_future to future following the c++11. * [@http://svn.boost.org/trac/boost/ticket/6266 #6266] Breaking change: thread destructor should call terminate if joinable. * [@http://svn.boost.org/trac/boost/ticket/6269 #6269] Breaking change: thread move assignment should call terminate if joinable. " I would like to request advise from the release managers and of course the Boost community. Should I rollback the default to BOOST_THREAD_VERSION==3 for 1.53 and let the time to discuss the best way to manage with these breaking changes? Best, Vicente

21 40

[log] Most recent version
by Alexander Arhipenko 04 Jan '13

04 Jan '13

Hi, We're going to update boost.log sources in our code base. Could you please recommend what version to use? The code is taken from: https://boost-log.svn.sourceforge.net/svnroot/boost-log/. And currently I consider 3 options: branches/v1 branches/bleeding-edge trunk Thanks in advance. Regards

5 7