On Fri, 21 May 2010 14:00:42 -0400, Andrei Alexandrescu
<[email protected]> wrote:
On 05/20/2010 05:34 AM, Steven Schveighoffer wrote:
I understand these points, but I'm already using interfaces to copy
data between containers. I don't have to, I could have used generic
code, but this way, only one function is instantiated to copy data
from all the other containers. The problem with using generic code
is that the compiler will needlessly duplicate functions that are
identical.
There is a copy() function that copies any range to any other range. It
might need a revisit, but I think the way to go about copying is generic.
This implies the space for the elements already exists in the target
range. Copying data from a list to a set for instance can't just allocate
space in the set and then use some generic copy function to copy the data
in.
If generic copying is to be used, it would be a copy function defined by
the collection, not a standard one.
Using interfaces is not as viral as you think. My interfaces can be
used in generic code, as long as the generic code uses functions in
the interfaces. If a library returns an interface, the author is
saying "I don't want you using any functions outside this interface,"
so why is that a bad thing?
Forcing people to *not* use interfaces has its drawbacks too.
Dcollections gives the most flexible design I could muster, while
still being useful.
I'm not saying I'm against removing the interfaces until some later
date, but I don't see any convincing arguments yet, especially since
I've already seen benefits from having them.
What are the benefits that you have noticed? I think you'd need to back
up the copying argument with some data if you want to frame it as a
benefit.
When I mean see benefits, the benefits are not data-related but design
related -- more designs are possible with interfaces and generic
programming combined than with generic programming alone.
-Steve
