Boost logo

Boost Users :

Subject: [Boost-users] Ranges to Collections
From: John M. Dlugosz (mpbecey7gu_at_[hidden])
Date: 2011-06-06 12:00:29

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?


Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at