February 2013 - Boost - lists.preview.boost.org

[smart_ptr] !defined(BOOST_NO_CXX11_SMART_PTR) does not imply !defined(BOOST_NO_CXX11_RVALUE_REFERENCES)
by Michel Morin 10 Feb '13

10 Feb '13

`!defined(BOOST_NO_CXX11_SMART_PTR)` does not necessarily mean that the compiler support of rvalue references is available. For example, when I use shared_ptr (on trunk) with clang + libc++ in a C++03 mode, I get warnings something like boost/smart_ptr/shared_ptr.hpp:556:51: warning: rvalue references are a C++11 extension [-Wc++11-extensions] shared_ptr & operator=( std::unique_ptr<Y, D> && r ) Regards, Michel

3 4

[preprocessor] enabling variadics support
by Gennadiy Rozental 09 Feb '13

09 Feb '13

Hi, It appears PP variadics support is disabled on wide range of compilers where it is in fact working (at least It seems to be). This includes Clang and PGI. Can we enable it now? Gennadiy

3 2

[variant] Please vote for behavior (Was: Basic rvalue and C++11 features seupport)
by Antony Polukhin 08 Feb '13

08 Feb '13

Current implementation of recursive_wrapper move constructor is not optimal: recursive_wrapper<T>::recursive_wrapper(recursive_wrapper&& operand) : p_(new T(std::move(operand.get()) )) { } During descussion were made following proposals: I: Leave it as is - bad performance - can not provide noexcept guarantee II: Set operand.p_ to NULL, add BOOST_ASSERT in get operations + good performance + provides noexcept guarantee for move constructor + optimization will be used even if varinat has no type with trivial default constructor + easy to implement - triggers an assert when user tries to reuse moved object - adds an empty state to the recursive_wrapper III: Make recursive_wrapper and variant cooperate, enable move for varinat in the presence of recursive_wrappers only when there is at least one type that is nothrow-default-constructible, regardless of whether it's current. It is easyer to understand by example: typedef variant<int, recursive_wrapper<foo>> V; V v1( std::move(v2) ); This move-constructs v1 from v2 and leaves int() into v2. + good performance + provides noexcept guarantee for rcursive_wrapper + does not adds an empty state - optimization won't trigger if varinat has no type with trivial default constructor - hard to implement - user may be obscured by the fact, that v2 from the example now contains int IV: After move away, delay construction of type held by recursive_wrapper till it will be be required. +/- good performance? but more checks + provides noexcept guarantee for rcursive_wrapper + does not adds an explicit empty state + optimization will be used even if varinat has no type with trivial default constructor +/- not hard to implement --- additional requirement for type T of recursive_wrapper: it must be default constructible - less obvious behavior for user (for example get() function would construct values, allocate memory and can possibly throw) Please, vote for solution or propose a better one. P.S.: As I know Joel de Guzman votes for solution II (and totally agains solution I, because it is too slow). I wanted to leave as is (solution I) or use solution IV, but Joel talked me to solution II. P.P.S.: More info can be obtained from ticket #7718 https://svn.boost.org/trac/boost/ticket/7718 and previous series of letters. -- Best regards, Antony Polukhin

23 126

[asio] socks and http connect proxy support
by ecyrbe 08 Feb '13

08 Feb '13

Hi, I made a boost asio client stream to handle tcp proxy support (both socks v4/v5 and http connect). I think boost asio lack this type of support, so i'm asking if there is any interest to integrate such a feature in boost.Asio? I'm mainly asking this question to boost.Asio maintainers. if you want i can come with a patch for a proxyfied_stream<Stream> template class. Regards, ecyrbe.

1 0

[Git] Tracking conversion milestones and issues
by Beman Dawes 08 Feb '13

08 Feb '13

To track the Git and modular Boost conversion milestones and issues, see github.com/ryppl/boost-svn2git/issues/milestones github.com/ryppl/boost-svn2git/issues --Beman

1 0

[log] v2 Initialisation, default sink behaviour and filtering documentation
by Mats Taraldsvik 08 Feb '13

08 Feb '13

Hi, I'm in the process of adopting a logging library, so the timing of the Boost.Log v2 "status report" - for me - could not have been better. :) This library is awesome, thank you for making it! -- I am in the process of moving beyond the default sink now, and had some issues. I tried to add the sinks after my logger object had been default initialized, and this caused some problems (partial streams/corruption, mostly). Currently I'm calling core->remove_all_sinks() to remove the default sink. Are there any "best practices" here? Perhaps it would be a good idea to add these "requirements" to the documentation, if they are not there already and I missed them? :) -- I also noticed that the severity filter examples are : logging::core::get()->set_filter ( logging::trivial::severity >= logging::trivial::info ); >From "Setting up sinks", and sink->set_filter(expr::attr< int >("Severity") >= 2); (i.e. comparing the Severity with an int) when moving to the more advanced section in "Sink frontends". Could you adjust one of the examples in "Sink frontends" to use the severity_level type (that the documentation introduces in the tutorial "Adding more information to log: Attributes") directly? For example: sink->set_filter(expr::attr< severity_level >("Severity") >= warning); Or explaining this in "Log record formatting". I had trouble understanding this at first, but I might be the only one :). Thought I'd mention it anyway. -- Regards, Mats Taraldsvik Norkart AS norkart.no

2 5

[bind] Request: use result_of instead of result_type for functors
by Jason 07 Feb '13

07 Feb '13

One of the drawbacks of using functors with Boost.Bind is that the result type of the functor must be specified either as a typedef inside the functor's definition or as a template argument when building the binding. As the documentation states it: "In the general case, the return type of the generated function object's operator() has to be specified explicitly (without a typeof operator the return type cannot be inferred)" It seems that result_of() would be a good implementation of the "typeof" operator referenced in the above, instead of relying upon a single result_type typedef inside the functor struct/class. This would allow the use of functors whose result type depends upon the arguments passed to the functor. It looks like there was a proof-of-concept patch submitted for this a couple years ago: https://svn.boost.org/trac/boost/ticket/4542 It doesn't appear to have received any attention, however. Is this something that might happen? -- View this message in context: http://boost.2283326.n4.nabble.com/bind-Request-use-result-of-instead-of-re… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 11

[log] missing file in trunk?
by Michael Caisse 07 Feb '13

07 Feb '13

boost/log/filters.hpp seems to be missing from https://boost-log.svn.sourceforge.net/svnroot/boost-log/trunk/boost-log revision 827. Ideas? michael -- Michael Caisse ciere consulting ciere.com

2 3

[bbv2] pdf doc missing?
by Michael Marcin 07 Feb '13

07 Feb '13

http://www.boost.org/doc/libs/1_53_0/tools/build/v2/index.html links to http://www.boost.org/doc/libs/1_53_0/tools/build/v2/doc/userman.pdf Which appears to be broken 404 Not Found File "/home/grafik/www.boost.org/archives/live/boost_1_53_0/tools/build/v2/doc/userman.pdf" not found. In fact the last working one seems to be http://www.boost.org/doc/libs/1_37_0/tools/build/v2/doc/userman.pdf

1 0

[Function] : Memory allocation upon bind()
by Harry van Haaren 06 Feb '13

06 Feb '13

Hi All, Summary: Boost::bind() allocates memory on the heap. In my situaion it is necessary to use manual memory pool instead of heap allocation, to conform with real-time timing requirements. (no malloc() calls allowed in real-time code) A solution might be writing a custom allocator for the boost::bind()'s data, and use a pre-allocated memory pool with the "placement" new( void* ) to write directly into it. I've found that there was a discussion on std::allocator support for std::bind and std::function here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2308.html I'm not very familiar with the internals of bind() and Function in general, hence advice is appreciated. What is the status of boost::bind() and custom allocators? Is there a chance this could work? Am I missing some "easy" workaround or solution? Thanks for reading, -Harry

2 2