On Wednesday, September 29, 2010 12:55:40 Steven Schveighoffer wrote: > On Wed, 29 Sep 2010 15:46:19 -0400, Andrei Alexandrescu > > <[email protected]> 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
