Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Thu, 12 Nov 2009 16:23:22 +0300, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Thu, 12 Nov 2009 08:22:26 -0500, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 10 Nov 2009 18:49:54 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> wrote:
I think the best option for toString is to take an output range and
write to it. (The sink is a simplified range.)
Bad idea...
A range only makes sense as a struct, not an interface/object. I'll
tell you why: performance.
Ranges are special in two respects:
1. They are foreachable. I think everyone agrees that calling 2
interface functions per loop iteration is much lower performing than
using opApply, which calls one delegate function per loop. My
recommendation -- use opApply when dealing with polymorphism. I
don't think there's a way around this.
Oops, I meant 3 virtual functions -- front, popNext, and empty.
-Steve
Output range has only one method: put.
I'm not sure, but I don't think there is a performance difference
between calling a virtual function through an interface and invoking a
delegate.
But I agree passing a delegate is more generic. You can substitute an
output range with a delegate (obj.toString(&range.put, fmt)) without
any performance hit, but not vice versa (obj.toString(new
DelegateWrapRange(&myput), fmt) implies an additional allocation and
additional indirection per range.put call).
I think that, on the contrary, working with a delegate is less generic.
A delegate is cost-wise much like a class with only one (non-final)
method. Since we're taking that hit already, we may as well define
actual interfaces and classes that have multiple methods. That makes
things more flexible and more efficient.
How? It seems to introduce more requirements on the implementation, but
I'm not seeing any benefit in exchange.
FWIW, with regard to performance, I can easily imagine the compiler
being able to perform the equivalent of a "named return value"
optimisation on a delegate return, giving some chance of inlining.
That's a lot less obvious with an interface.
