- Boost - lists.boost.org

[any] Move semantic
by Klaim - Joël Lamotte 17 May '12

17 May '12

Hi, My current understanding of the new rules of 5 tells me that boost::any isn't "move aware". First, am I correct? Second, I think that adding the move constructor and move operator is trivial. Again, am I correct or is there some tricks to know before adding them? Third, I want to use boost::any in a value-semantic type. Sometime it would keep a unique_ptr. If I understand correctly move semantic and unique_ptr implementation, the current boost::any implementation don't forbid me to use unique_ptr as a value type. Am I correct? Joel Lamotte

2 1

[result_of, phoenix] Inconsistency between result_of and tr1_result_of
by Michel Morin 17 May '12

17 May '12

To support nullary-callable polymorphic function objects in C++03 `result_of`, we have to specialize `result_of` for the zero-argument case. (If we don't provide specializations, the type determined by C++03 `result_of` for zero-argument function calls is defaulted to void. See the rationale in N1454.) Library authors have implemented the specialization for `result_of` to support the zero-argument case. But, in most cases, they have not specialized `tr1_result_of`. I checked a few Boost libraries: * Boost.Phoenix and Boost.Functional/Forward Only `result_of` is specialized; `tr1_result_of` is not specialized. (* Boost.Lambda Neither `result_of` nor `tr1_result_of` is specialized. So `result_of` and `tr1_result_of` for nullary function calls always evaluate to `void`.) This results in inconsistency between `result_of` and `tr1_result_of`. For example, boost::result_of< decltype(boost::phoenix::val(3))() >::type evaluates to `int const&`. But boost::tr1_result_of< decltype(boost::phoenix::val(3))() >::type evaluates to `void`. Shouldn't we provide specializations for both `result_of` and `tr1_result_of` to make result_of and tr1_result_of equivalent? (Additional question: Should we avoid the specialization of result_of when we use decltype-based result_of?) Regards, Michel

2 2

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

17 May '12

From: Ion Gazta?aga <igaztanaga(a)gmail.com> > It's easy to implement, I've just erased several trailing spaces in my > local copy, but it's hard to believe it can actually improve much > compilation times or file sizes. This is probably the easiest way to improve Boost. I hope authors will add this to their list of finishing touches. I know it won't make a big difference, but still think it's worthwhile. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net

2 1

Boost.PropertyTree custom allocator?
by Klaim - Joël Lamotte 17 May '12

17 May '12

Hi, Is there any plan to add custom allocators to boost.property_tree ? Joel Lamotte

2 1

[fusion] Trouble using BOOST_FUSION_ADAPT_ADT with boost::fusion::operator<
by GOODHART, TAYLOR 17 May '12

17 May '12

Hi all, I'm attempting to adapt a third-party struct into a fusion sequence using BOOST_FUSION_ADAPT_ADT to get access to a nice operator<. Unfortunately compilation fails and I'm not sure if it's a bug or me using the library incorrectly. As best I can read the error message, it looks like the code is attempting to compare adt_attribute_proxy structs instead of the values represented by these. Below is some code that demonstrates the problem. Can anybody help me out? Thanks, Taylor #include <boost/fusion/adapted/adt/adapt_adt.hpp> #include <boost/fusion/adapted/struct/define_struct.hpp> #include <boost/fusion/adapted/struct/adapt_struct.hpp> #include <set> #include <string> #include <boost/fusion/sequence/comparison/less.hpp> struct test1 { std::string s; const std::string & getS() const { return s; } void setS( const std::string & s_) { s = s_; } }; BOOST_FUSION_ADAPT_ADT( test1, (const std::string &, const std::string &, obj.getS(), obj.setS(val)) ) BOOST_FUSION_DEFINE_STRUCT( , test2, (std::string, s) (int, a) ) struct test3 { std::string s; }; BOOST_FUSION_ADAPT_STRUCT( test3, (std::string, s) ) using boost::fusion::operator<; int main( int argc, char * argv[]) { //Fails /*std::set<test1> destinations1; destinations1.insert(test1());*/ std::set<test2> destinations2; destinations2.insert(test2()); std::set<test3> destinations3; destinations3.insert(test3()); return 0; }

3 7

[type_erasure] RFC: New version
by Steven Watanabe 15 May '12

15 May '12

AMDG I've just committed an updated version of my type_erasure library to the sandbox at http://svn.boost.org/svn/boost/sandbox/type_erasure. Highlights of this version: * Simplified primitive concept definitions. Now, all it takes is: template<class T = _self> struct incrementable { static void apply(T& t) { ++t; } }; * Support for associated types and same_type. This allows defining iterator concepts in a uniform way: typedef mpl::vector< forward_iterator<>, same_type<forward_iterator<>::value_type, _a>, copy_constructible<_a>, typeid_<_a> > concept; std::vector<int> vec(10); for(any<concept> first(vec.begin()), last(vec.end()); first != last; ++first) { std::cout << any_cast<int&>(*first) << std::endl; } Now, _a automatically binds to int. The core library is now feature complete. Once I finish updating the iterator concepts, I think this should be ready for a formal review. Any thoughts, comments, or criticism is greatly appreciated. In Christ, Steven Watanabe

4 7

[Intrusive] Cleaning up trailing white space
by Brian Wood 14 May '12

14 May '12

>From what I can tell a lot of Boost libraries would benefit from this, but in particular I want this for the Intrusive library. It helps to improve compile times and reduce the space needed by Boost. I used grep " $" * to help with that here. Shalom, Brian Wood Ebenezer Enterprises http://webEbenezer.net

3 2

ice_and/or vs. mpl::and_/or_
by Nathan Ridge 14 May '12

14 May '12

Hi, Is there any difference between boost::type_traits::ice_and (ice_or) and boost::mpl::and_ (or_)? Should one be preferred over the other in the implementation of other Boost libraries? Thanks, Nate

3 3

[config] 4 new C++11 macros added
by John Maddock 14 May '12

14 May '12

A long time back I was asked for a bunch of new config macros which have finally now been added: BOOST_NO_CXX11_ALLOCATOR The standard library does not provide a C++11 version of `std::allocator` in <memory>. BOOST_NO_CXX11_ATOMIC_SP The standard library <memory> does not support atomic smart pointer operations. BOOST_NO_CXX11_HDR_FUNCTIONAL The standard library does not provide a C++11 compatible version of <functional>. BOOST_NO_CXX11_SMART_PTR The standard library header <memory> has no shared_ptr and unique_ptr. Enjoy, John.

6 11

[ICL] #6853: boost::icl::contains(NaN) returns true
by Andrew Hundt 13 May '12

13 May '12

I had submitted a bug report for icl, and the response I included below seemed indicate this is more for the list than a bug report. It deals with an issue where boost::icl::contains(NaN) returns true, where any NaN value cannot actually be contained within an interval, and so should return false. I'm dealing with data that comes from a physical device, so each measurement the system returns is not guaranteed to be valid. We set those invalid measurements to NaN. However, when the data is valid it falls into certain intervals that I found icl well suited for, despite not falling into the original use case of time scheduling I find it to be a reasonable representation to work with. While IEEE floating point numbers is not required by the C++ standard, it is a standard that does seem to have fairly wide use in C++. It seems, at least in my use case, that NaN is a very reasonable value to use and fits well with the functionality icl provides. However, I wanted to open this to wider opinions to learn about the state of the issue. Cheers! Andrew Hundt ---------- Forwarded message ---------- From: Boost C++ Libraries <noreply(a)lists.boost.org> Date: Fri, May 4, 2012 at 6:50 AM Subject: Re: [Boost C++ Libraries] #6853: [ICL] boost::icl::contains(NaN) returns true To: Cc: boost-bugs(a)lists.boost.org #6853: [ICL] boost::icl::contains(NaN) returns true -----------------------------------------------+---------------------------- Reporter: Andrew Hundt <ATHundt@…> | Owner: jofaber Type: Bugs | Status: closed Milestone: To Be Determined | Component: ICL Version: Boost 1.49.0 | Severity: Problem Resolution: invalid | Keywords: icl -----------------------------------------------+---------------------------- Changes (by jofaber): * status: new => closed * resolution: => invalid Comment: Hi Andrew, icl code is not intended to be NaN complete. NaN is a weird animal that breaks concepts the icl is based on. Completing icl for NaN would make the code unnecessarily clumsy for cases that are hardly ever used. If you desire to complete your code for NaN cases you will have to do it in your code or write your own NaN layer around the icl. Regards, Joachim -- Ticket URL: <https://svn.boost.org/trac/boost/ticket/6853#comment:1> Boost C++ Libraries <http://www.boost.org/> Boost provides free peer-reviewed portable C++ source libraries.

7 15