Maybe you want make_vector() , make_list(). #include <vector> #include <list> #include <boost/range/algorithm.hpp> #include <boost/range/algorithm_ext/push_back.hpp> #include <boost/range/adaptor/reversed.hpp> // for test template<class T, class SinglePassRange> T make_container(const SinglePassRange& from) { T c; boost::push_back(c, from); return move(c); } template<class SinglePassRange> std::vector<typename SinglePassRange::value_type> make_vector(const SinglePassRange& from) { return make_container<std::vector<typename SinglePassRange::value_type>>(from); } template<class SinglePassRange> std::list<typename SinglePassRange::value_type> make_list(const SinglePassRange& from) { return make_container<std::list<typename SinglePassRange::value_type>>(from); } int main(int argc, _TCHAR* argv[]) { std::vector<char> vector1; vector1.push_back(1); vector1.push_back(2); vector1.push_back(3); std::list<char> list1; list1.push_back(1); list1.push_back(2); list1.push_back(3); auto vector2 = make_container<std::vector<char>>(vector1 | boost::adaptors::reversed); auto vector3 = make_vector(vector1 | boost::adaptors::reversed); auto vector4 = make_vector(vector1); auto list2 = make_container<std::list<char>>(list1 | boost::adaptors::reversed); auto list3 = make_list(list1 | boost::adaptors::reversed); auto list4 = make_list(list1); return 0; }
------------------------------
Message: 2 Date: Mon, 06 Jun 2011 11:00:29 -0500 From: "John M. Dlugosz" <mpbecey7gu@snkmail.com> To: boost-users@lists.boost.org Subject: [Boost-users] Ranges to Collections Message-ID: <15775-1307376032-823667@sneakemail.com> Content-Type: text/plain; charset=UTF-8; format=flowed
I like "ranges". When I first read the introduction to the ideas that would become STL, I did not like the use of begin/end iterators. Primarily, there is a possibility of getting them mixed up and the proposed library was explicitly not robust in the face of being passed bad parameters, such as not belonging to the same collection or not having the end after the begin. This was in direct contrast to the code I was promoting, which stressed API design that prevented errors from being possible, and strongly checking for everything else. The fact that they are not "functional" was harder to grasp exactly at the time, but it bothered me "in my gut".
When I read about the Boost Range library and the C++0x adoption of the range concept, I felt this to be a long sought improvement and would dramatically improve my use of STL.
Suffice to say, I'm a fan of Ranges. In new work, and in refactoring and improving code, I expect ranges to be one of the pillars of improvement. I'm sad to see that the draft standard dropped most of the range stuff (presumably it needs Concepts) but left in the intrinsic for-each loop. Anyway, the concrete compiler I have to work with, Visual Studio 2010, doesn't include it. So Boost.Range to the rescue! Except... the standard containers like vector don't have constructors that take ranges.
Consider something like: vector<string> retval (rangefunc | rangefilter);
It really gets in the way to introduce a temporary variable of "some range type", but I see that the 'auto' feature comes to the rescue. I'm not used to having that available, so perhaps I'm over reacting.
But, is there a way to bridge the gap?
I take it patching the STL headers to add the missing constructors is frowned upon. But some syntactic sugar might get pretty close to that. First of all, what are people doing now? Maybe this has all be gone over before?
I can see creating a derived class from each STL container. The sole purpose of that class is to have the range constructor, and then the resulting instance is used as the base class, passed somewhere or copied. So you might write, for the previous example: range_vector retval (rangefunc | rangefilter);
and other code won't care about your derived class since it only existed district from the base class in order to add a constructor. In fact, a template might systematically do this to any class that has a constructor that takes two iterators: rangeit<vector<string>> retval (rangefunc | rangefilter);
This is less than desirable in cases where you were not going to state the type. Say, a return statement or parameter, where you would ideally have an implicit conversion from a range to the collection: return (rangefunc | rangefilter); // give a "range" where collection is expected
Could a helper template be written that has a simple name and doesn't need to be told the types involved? return range_to_collection (rangefunc | rangefilter);
Perhaps this produces a temporary object that supports a templatized conversion operator, so it can continue when that is told the type desired. I can see a few approaches, depending on what the compiler would swallow. But, has anyone already done this?
?John
I use this: template <typename Range> struct RangeWrapper { const Range& r; template <typename Container> operator Container() const { return Container(begin(r), end(r)); } }; template <typename Range> RangeWrapper<Range> range_to_container(const Range& r) { return RangeWrapper<Range>{r}; } Simple but effective. Regards, Nate. ----------------------------------------
Date: Tue, 7 Jun 2011 10:31:29 +0800 From: qiaozhiqiang@leadcoretech.com To: boost-users@lists.boost.org CC: mpbecey7gu@snkmail.com Subject: Re: [Boost-users] Ranges to Collections
Maybe you want make_vector() , make_list().
#include #include #include #include
#include // for test
template T make_container(const SinglePassRange& from) { T c; boost::push_back(c, from); return move(c); }
template std::vector make_vector(const SinglePassRange& from) { return make_container>(from); }
template std::list make_list(const SinglePassRange& from) { return make_container>(from); }
int main(int argc, _TCHAR* argv[]) { std::vector vector1; vector1.push_back(1); vector1.push_back(2); vector1.push_back(3);
std::list list1; list1.push_back(1); list1.push_back(2); list1.push_back(3);
auto vector2 = make_container>(vector1 | boost::adaptors::reversed); auto vector3 = make_vector(vector1 | boost::adaptors::reversed); auto vector4 = make_vector(vector1);
auto list2 = make_container>(list1 | boost::adaptors::reversed); auto list3 = make_list(list1 | boost::adaptors::reversed); auto list4 = make_list(list1);
return 0; }
------------------------------
Message: 2 Date: Mon, 06 Jun 2011 11:00:29 -0500 From: "John M. Dlugosz" To: boost-users@lists.boost.org Subject: [Boost-users] Ranges to Collections Message-ID: <15775-1307376032-823667@sneakemail.com> Content-Type: text/plain; charset=UTF-8; format=flowed
I like "ranges". When I first read the introduction to the ideas that would become STL, I did not like the use of begin/end iterators. Primarily, there is a possibility of getting them mixed up and the proposed library was explicitly not robust in the face of being passed bad parameters, such as not belonging to the same collection or not having the end after the begin. This was in direct contrast to the code I was promoting, which stressed API design that prevented errors from being possible, and strongly checking for everything else. The fact that they are not "functional" was harder to grasp exactly at the time, but it bothered me "in my gut".
When I read about the Boost Range library and the C++0x adoption of the range concept, I felt this to be a long sought improvement and would dramatically improve my use of STL.
Suffice to say, I'm a fan of Ranges. In new work, and in refactoring and improving code, I expect ranges to be one of the pillars of improvement. I'm sad to see that the draft standard dropped most of the range stuff (presumably it needs Concepts) but left in the intrinsic for-each loop. Anyway, the concrete compiler I have to work with, Visual Studio 2010, doesn't include it. So Boost.Range to the rescue! Except... the standard containers like vector don't have constructors that take ranges.
Consider something like: vector retval (rangefunc | rangefilter);
It really gets in the way to introduce a temporary variable of "some range type", but I see that the 'auto' feature comes to the rescue. I'm not used to having that available, so perhaps I'm over reacting.
But, is there a way to bridge the gap?
I take it patching the STL headers to add the missing constructors is frowned upon. But some syntactic sugar might get pretty close to that. First of all, what are people doing now? Maybe this has all be gone over before?
I can see creating a derived class from each STL container. The sole purpose of that class is to have the range constructor, and then the resulting instance is used as the base class, passed somewhere or copied. So you might write, for the previous example: range_vector retval (rangefunc | rangefilter);
and other code won't care about your derived class since it only existed district from the base class in order to add a constructor. In fact, a template might systematically do this to any class that has a constructor that takes two iterators: rangeit> retval (rangefunc | rangefilter);
This is less than desirable in cases where you were not going to state the type. Say, a return statement or parameter, where you would ideally have an implicit conversion from a range to the collection: return (rangefunc | rangefilter); // give a "range" where collection is expected
Could a helper template be written that has a simple name and doesn't need to be told the types involved? return range_to_collection (rangefunc | rangefilter);
Perhaps this produces a temporary object that supports a templatized conversion operator, so it can continue when that is told the type desired. I can see a few approaches, depending on what the compiler would swallow. But, has anyone already done this?
?John
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Seeing as everyone seems to have a version, we have a demonstrated need.
On 6/6/2011 11:33 PM, Nathan Ridge wrote:
I use this:
template<typename Range> struct RangeWrapper { const Range& r;
template<typename Container> operator Container() const { return Container(begin(r), end(r)); } };
template<typename Range> RangeWrapper<Range> range_to_container(const Range& r) { return RangeWrapper<Range>{r}; }
Simple but effective.
Regards, Nate.
Yes, simple indeed. What compiler are you using? I'm pretty sure Microsoft's doesn't support uniform initialization syntax. But in this case, writing (r) instead and adding the constructor to RangeWrapper should work just fine. It's just less simple <g>. —John
From: mpbecey7gu@snkmail.com
What compiler are you using? I'm pretty sure Microsoft's doesn't support uniform initialization syntax. But in this case, writing (r) instead and adding the constructor to RangeWrapper should work just fine. It's just less simple .
I use gcc 4.5 which supports uniform initialization. But as you say, you can just replace it with a constructor if necessary. Regards, Nate.
Not all containers I use have a (begin, end) constructor: #include <boost/range.hpp> #include <algorithm> #include <boost/numeric/ublas/vector.hpp> #include <boost/multi_array.hpp> #include <pyublas/numpy.hpp> namespace detail { template<typename cont_t, typename range> struct construct_from_range_impl { cont_t operator() (range const& r) { return cont_t (boost::begin (r), boost::end (r)); } }; template<typename T, typename range> struct construct_from_range_impl<boost::numeric::ublas::vector<T>, range> { typedef typename boost::numeric::ublas::vector<T> ret_t; ret_t operator() (range const& r) { ret_t v (boost::size (r)); std::copy (boost::begin (r), boost::end (r), v.begin()); return v; } }; template<typename T, typename range> struct construct_from_range_impl<boost::multi_array<T,1>, range> { typedef typename boost::multi_array<T,1> ret_t; ret_t operator() (range const& r) { ret_t v (r); return v; } }; template<typename T, typename range> struct construct_from_range_impl<pyublas::numpy_vector<T>, range> { typedef typename pyublas::numpy_vector<T> ret_t; ret_t operator() (range const& r) { ret_t v (r); return v; } }; } template<typename cont_t, typename range> cont_t inline construct_from_range (range const& r) { return detail::construct_from_range_impl<cont_t,range>() (r); }
On 6/6/2011 9:31 PM, 乔志强 qiaozhiqiang-at-leadcoretech.com wrote:
Maybe you want make_vector() , make_list().
template<class T, class SinglePassRange> T make_container(const SinglePassRange& from) { T c; boost::push_back(c, from); return move(c); }
I think it would be better to make use of the two-iterator form of the constructor rather than calling push_back. That way it can allocate storage for all elements in advance if the kind of range allows for finding the difference easily. { return T (from.begin(), from.end()); } I guess your way optimizes for the case where it needs to slowly traverse the range in order to find the end() first. I suppose boost::push_back does something similar if it can, but it still constructs as zero size and then resizes.
template<class SinglePassRange> std::vector<typename SinglePassRange::value_type> make_vector(const SinglePassRange& from) { return make_container<std::vector<typename SinglePassRange::value_type>>(from); }
The make_container needs to be told the exact container type in the call, and your make_vector et al. is a different name for each possible container. I would think you could use a template template argument and pass in the container species only, and have it obtain the value_type for itself. I think that would be good enough, as the details of the value types is the hard part. But, I speculate that a simple expression could figure out the complete type by itself via using a templatized conversion operator.
participants (4)
-
John M. Dlugosz -
Nathan Ridge -
Neal Becker -
乔志强