Quote:Original post by Zahlman
You know, I'm starting to think that the language doesn't really need move
constructors as much as it needs better support for *swapping*. :)
Isn't that what overloading std::swap is for?
Sorting an std vector
Isn't that what overloading std::swap is for?
Some of you are forgetting that he is using objets whose x positions change, and since x is the sort key, you don't want to use a container such as a set as it would require removal, modification, and reinsertion of each item. Each object shouldn't have to know that it is even in a set, which it would clearly need to know here.
The best thing would be to use a vector and an algorithm that works very well on almost sorted data. Obviously a good choice is std::sort, and if profiling suggests you need something faster, then an algorithm more suited to an almost sorted array could be implemented, such as Insertionsort.
There are plenty of other good algorithms for this purpose too. Inserting items into a splay tree for example, is another fast way (at least in terms of comparisons) of sorting almost sorted data, or data with obvious patterns. Unfortunately it takes quite a bit of extra RAM.
The thing is, you don't want to go to all that extra trouble of implementing something else if you already have an option with sufficient performance.
The best thing would be to use a vector and an algorithm that works very well on almost sorted data. Obviously a good choice is std::sort, and if profiling suggests you need something faster, then an algorithm more suited to an almost sorted array could be implemented, such as Insertionsort.
There are plenty of other good algorithms for this purpose too. Inserting items into a splay tree for example, is another fast way (at least in terms of comparisons) of sorting almost sorted data, or data with obvious patterns. Unfortunately it takes quite a bit of extra RAM.
The thing is, you don't want to go to all that extra trouble of implementing something else if you already have an option with sufficient performance.
Quote:Original post by KylotanAh yes, but the syntax to call that isn't nearly as nice asQuote:Original post by Zahlman
You know, I'm starting to think that the language doesn't really need move
constructors as much as it needs better support for *swapping*. :)
Isn't that what overloading std::swap is for?
a = b;If there was a swap operator, then things would be a whole lot different.
Quote:Original post by iMalcQuote:Original post by KylotanAh yes, but the syntax to call that isn't nearly as nice asQuote:Original post by Zahlman
You know, I'm starting to think that the language doesn't really need move
constructors as much as it needs better support for *swapping*. :)
Isn't that what overloading std::swap is for?a = b;
If there was a swap operator, then things would be a whole lot different.
Indeed. Further, if we add a simple heuristic like "if there's a specialized swap for this object, it must be because swapping is faster than assigning or copying; therefore, if the RHS of an assignment of those objects is dead, do a swap instead", then we sidestep all that (N)RVO analysis business quite nicely, and potentially optimize in other contexts as well.
Of course, a move constructor would presumably perform a little better in general than a "swap construction" consisting of default-construction and a swap, but this seems like most of the gain for much less work. (Plus we don't have to hack around in the compiler to skip the dtor of the constructed-from, dead object; nor in the client code to clean up any old stuff in an assigned-to object, in the assignment case.)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
