sorting hidden data.

[Jonathan M Davis]

On Wednesday, September 29, 2010 12:55:40 Steven Schveighoffer wrote:
> 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...

The real problem then is in any structs with elaborate copy constructors, isn't 
it? Essentially, it's foolish to put something which is expensive to copy in a 
situation where it's going to be copied much, if at all. So, essentially, any 
user who creates such a struct and then tries to use it with ranges is shooting 
themselves in the foot performance-wise. And Andrei thinks that this is a big 
enough issue to give them a way not to shoot themselves in the foot. I'm not 
sure that I agree, but I don't know that he's wrong either. Worrying about it is 
certainly complicating ranges though.

- Jonathan M Davis