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.
--
Michel Fortin
[email protected]
http://michelf.com/
