On Mon, 24 May 2010 08:06:29 -0400, Steven Schveighoffer
<[email protected]> wrote:
On Thu, 20 May 2010 12:46:59 -0400, Robert Jacques <[email protected]>
wrote:
On Thu, 20 May 2010 06:34:42 -0400, Steven Schveighoffer
<[email protected]> wrote:
[snip]
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.
This sounds like a failure of design. Why aren't you using ranges to do
this?
Why are ranges necessarily better? I'm using the container's opApply,
which I'd probably still use even if there were no interfaces. opApply
allows much more possibilities in traversal than ranges which cannot use
stack recursion without heap activity.
Ranges are not necessarily better and may have some minor amount of
overhead over a well optimized opApply. Then again, the opposite may be
true. The point is that if the difference between opApply and a range is
more than trivial, you've probably had a failure of design occur.
Honestly, I'm having trouble thinking of a container which allows stack
recursion for transversal and doesn't have an efficient range/loop
variant. For that matter, a range using heap activity is also a clear
indication of a design failure.
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?
Well, needlessly duplicated functions for one. :) More importantly, the
example I gave was about third party libraries which I have no control
over. So this solution explicitly doesn't work. And even if everyone
used templates everywhere in order to be compatible with both
interfaces and classes, isn't that a viral effect of having both?
If a 3rd party library uses interfaces, it's probably for good reason.
They most likely want to remain binary compatible with other libs,
and/or want to abstract the implementation of some custom container
type. If you don't like their requirements, don't use the library.
-Steve
No, if a 3rd party library _needs_ to use interfaces it's probably for a
good reason. The problem is, if they exist, people are going to use them
even if they don't need them. Which therein lies the problem.
