Michel Fortin wrote:
On 2010-01-01 14:10:40 -0500, Jason House <[email protected]>
said:
With save() in tow, class ranges and struct ranges can be used the same
way. True, if someone forgets to say
auto copy = r.save();
and instead says:
auto copy = r;
the behavior will indeed be different for class ranges and struct
ranges.
Or if they completely forgot that bit of convention and omit creating
a variable called save... Also, doesn't use of save degrade
performance for structs? Or does the inliner/optimizer remove the copy
variable altogether?
I don't think this will be a problem for the optimizer.
But I say dump save(): it's more trouble than it's worth.
I'm sure it will be a problem for most programmers, as most will learn
and test algorithms with arrays and struct ranges and not classes.
"save()" is a detail too easy to miss. The benefit of supporting classes
by asking everyone to remember adding save() seems tiny considering you
can easily create a struct wrapper if you really need your range to be a
class.
I know that the struct wrapper would probably force more copies of a
range than necessary. But there are many ways this could be alleviated.
For instance, the struct wrapper could use copy-on-write with a
reference counter to detect when a copy is necessary. So while it'd be a
little harder to design a range from a class, it'd be easier for
everyone to use ranges correctly.
save() is not only for classes. It also distinguishes input ranges from
forward ranges. It's the primitive that STL didn't define but should have.
Andrei
