The last changes to range

[Steven Schveighoffer]

On Sat, 29 May 2010 12:45:54 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> I plan to make two more (hopefully the last two) changes to the range  
> abstraction this morning.
>
> 1. First, I want to define this:
>
> // inside range type SomeRange
> @property SomeRange save();
>
> That simply returns a copy of the range. Most implementations look like  
> this:
>
> // inside range type SomeRange
> @property SomeRange save() { return this; }
>
> If SomeRange is a class or interface, you'd write:
>
> // inside range type SomeRange
> @property SomeRange save() { return this->clone(); }
>
> The idea is that save() provides a guaranteed means to take a snapshot  
> in a range's state. The notable absents are input ranges - they are  
> unable to define save(), and therefore some algorithms won't apply to  
> them.

In fact, I'd say you'd want to not define save unless it is the trivial  
case (your example for classes/interfaces shouldn't exist either).  The  
reason being, ranges may be copied multiple times in algorithms, it's  
generally expected that the copying does not figure into the complexity of  
an algorithm.  I assume that a non-trivial save will be expensive.  Expect  
to see your algorithm blow up in runtime if save is not trivial.

-Steve