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