May 2012 - Boost - lists.preview.boost.org

repository
by Frédéric Bron 18 May '12

18 May '12

I would like to work on a fix for the operator traits applied to STL containers but I have changed my computer and do not remember what is the official repository. Is there an official git repository that can be used? or have we to use the svn repository? What is the address to clone (git) or checkout (svn)? Regards, Frédéric

3 3

[Trac] No notification email when adding an attachment to a ticket
by Michel Morin 17 May '12

17 May '12

It is inconvenient that no notification email is sent when adding an attachment to a ticket. Alas, it's a limitation of trac for a long time. http://trac.edgewall.org/ticket/2259 Is there any plugin to automatically send notification email when attaching a file to a ticket? If not, probably we should change the message (which is displayed when we attach a file to a ticket) to explicitly say "No notification email will be sent by attaching a file. To automatically send a notification email, please leave some comment in the ticket!" Regards, Michel

1 0

[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