Slow performance compared to C++, ideas?

Jonathan M Davis jmdavisProg at gmx.com
Sun Jun 2 13:44:33 PDT 2013


On Sunday, June 02, 2013 12:37:38 Andrei Alexandrescu wrote:
> On 6/2/13 9:59 AM, Manu wrote:
> > I've never said that virtuals are bad. The key function of a class is
> > polymorphism.
> > But the reality is that in non-tool or container/foundational classes
> > (which are typically write-once, use-lots; you don't tend to write these
> > daily), a typical class will have a couple of virtuals, and a whole
> > bunch of properties.
> 
> I've argued if no dispatch is needed just make those free functions.
> _Everything_ in a class is supposed to be overridable, unless inherited
> and explicitly "final"ized. It's sort of a historical accident that
> things got the way they are. But in D we know better because we have the
> module-level privacy model and UFCS. So we should break clean from history.

There are four problems with that:

1. Very few programmers think that way. The normal thing in most every OO 
language is to put all of the functions on the class, so pretty much no one is 
going to make them free functions. Do you really expect people to put 
properties (what would have been getters and setters in other languages) 
outside the class? It's not going to happen. And by default, everyone takes a 
performance hit as a result (folks like Manu and Don wcare about that 
performance hit more than many of us, but it's still there).

2. The class' functions are no longer encapsulated inside the class. For some 
programmers, this is a big deal. They want all of the class' functionality on 
the class where it's easy to find. Having UFCS makes using free functions less 
of a problem, but many programmers will absolutely hate the idea of putting 
their non-virtual functions outside of the class, so they won't do it, and 
they (and everyone using their code) will end up with virtual functions when 
the functions shouldn't be virtual.

3. In many cases, putting a function outside of the class is a royal pain. 
This is particularly true with templated classes. If you have

class C(T)
{
   private T _var;
}

and you want a property to give you var, you end up with something ugly like

@property auto var(U)(U this_)
    if(is(U V == C!W, W))
{
    return this_._var;
}

Do you really expect many programmers to be able to pull off complicated is 
expressions like that? _I_ have to look it up every time I use it. Sure, using 
free functions might work in simple cases, but it starts falling apart when 
you have to deal with stuff like templated types.

4. It causes more ambiguities and compilation errors. If a function is on the 
class, it always wins. If it's a free function, then you potentially have 
ambiguities due to overload sets. Making sure that the function takes the 
exact type significantly reduces the problem, but someone else could easily 
create a function with the same signature which now conflicts with the one 
which is effectively supposed to be a member function.


I also don't see what trying to turn all of these member functions into free 
functions to use with UFCS buys us. Given that we have virtual by default, 
it's one way to avoid the function being virtual, but it's just simpler to 
mark it final if that's what you're trying to do. I think that the view point 
that every function in a class is supposed to be overridable is demonstrably 
false. How many functions in your average class get overriden? How often does 
final get used (or virtual not get used in the case of C++)? I think that it's 
quite clear that a lot of programmers don't want all of their class functions 
to be virtual. It seems to me that your argument is based purely on the idea 
that the main reason to use a class is for polymorphism, but that's not the 
only reason to use a class, and just because you have a class doesn't mean 
that you want everything it does to be polymorphic. And you're saying that 
everything that isn't polymorphic doesn't belong in a class just because the 
main purpose of a class is polymorphism. I don't buy that at all, and the 
average programmer agreed with you, they would have been using free functions 
all along, but the vast majority of them put all of the functions on the 
class, and I don't think that UFCS is going to change that at all.

- Jonathan M Davis


More information about the Digitalmars-d mailing list