sorting hidden data.

[Steven Schveighoffer]

On Wed, 29 Sep 2010 15:46:19 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 9/29/10 10:43 PDT, Steven Schveighoffer wrote:
>> What I mean is, why is it automatically assumed that if front does not
>> return a ref, the only way to swap is via moveX? If T == int, why must
>> we have a moveFront to deal with it? IMO, all algorithms should default
>> to copying unless alternatives exist.
>
> Good point. We should arrange things such that all types without  
> elaborate copy constructors allow swapping by copying.

Well, this isn't exactly what I said, but it makes sense.  If there is an  
elaborate copy constructor, then you shouldn't be calling it frequently.   
But then at the same time, isn't front() expected to be a fast operation?   
It's kind of the basis of most algorithms anyways, no?

So if you build a range that returns T by value in front(), are you to not  
expect that people will call front() frequently?  How does foreach perform  
on such an "elaborate copy constructor" range?

I think there's a broken concept here somewhere...

>
> Could you please bugzillize this so it's not forgotten?

I will, I'll just wait a bit in case there are more responses.

-Steve