On Friday, 20 September 2013 at 13:32:47 UTC, Dmitry Olshansky
wrote:
20-Sep-2013 15:01, Szymon Gatner пишет:
On Friday, 20 September 2013 at 10:47:52 UTC, Dmitry Olshansky
wrote:
20-Sep-2013 14:00, Jacob Carlborg пишет:
On 2013-09-20 11:37, Szymon Gatner wrote:
If only std algorithms took containers (by that I mean
things that
container for accepts too) as arguments (and not
iterators)... even in
the form of new functions like foreach_all, transform_all
etc.
Can't a container be a range as well?
For Christ sake no, no and no. For starters range skips/drops
elements
when iterating, and thusly iteration has its own state that
is useless
for a container otherwise.
Iteration is a stateful process, ranges are related to the
process of
iteration not to containers. As you say state is useless for
containers
but is necessary to iteration and its context.
A text-book example of self-destruction(?).
Ranges (in particular Input/Forward) are not much above
encapsulation of iteration, hence must contain that state
required to iterate said elements. Which leads to the point
that indeed containers have no business being ranges by
themselves.
The bottom line is:
sort(container[]);
vs
sort(container);
Where I hardly see how coupling containers with algorithms can
bring even slightest benefit.
OK so it seems we agree. I never said that containers should be
ranges. Ranges are abstraction on iterators and that is it.
Single container can have multiple ranges existing at the same
time. State is attached to ranges not containers. And most
importantly ranges are mutable always, even if underlying
container isn't. Ranges are meant to have state. No idea what you
mean by self destruction.
