Ruling out arbitrary cost copy construction?

[Steven Schveighoffer]

On Fri, 29 Oct 2010 09:06:24 -0400, Bruno Medeiros  
<brunodomedeiros+spam at com.gmail> wrote:

> On 06/10/2010 17:34, Andrei Alexandrescu wrote:
>>
>>
>> or similar. However, a sealed range does not offer references, so trying
>> e.g.
>>
>> swap(r1.front, r2.front);
>>
>> will not work. This is a problem.
>
> Why doesn't a sealed range offer references? Is it to prevent modifying  
> the elements being iterated?
> (I searched google and TDPL but couldn't find any info on sealed ranges)

Because a sealed range then has complete power over memory allocation of  
its elements (really, I think sealed ranges is a misnomer, it's really  
ranges on sealed containers).

Example: dcollections has a default allocator that allocates nodes in the  
collection as chunks (large numbers of nodes that fit into a page) to  
avoid over-using the GC.  It also uses free-lists to further avoid GC  
allocations.

If a range on such a container returned a reference, then someone could  
keep that reference indefinitely.  When the container removed that element  
and re-used it for another, the reference now would refer to the same  
element.

Although the range essentially is still a pointer, you can use mechanisms  
to prevent abuse, such as using a mutation counter on the container/range  
to track changes (dcollections doesn't do this, but it is possible).   
These kinds of things are impossible if the range offers references.  Once  
a reference gets out, you have lost control over the memory.

-Steve