Private imports and Objects

[Jonathan M Davis]

On Thursday, November 30, 2017 10:54:44 helxi via Digitalmars-d-learn wrote:
> On Thursday, 30 November 2017 at 06:44:43 UTC, Jonathan M Davis
>
> wrote:
> > On Thursday, November 30, 2017 06:29:43 helxi via
>
> > Digitalmars-d-learn wrote:
> []
>
> > I don't understand the question. You're asking whether casting
> > from a base class to a derived class creates overhead? Or are
> > you asking whether having a base class for all classes creates
> > overhead? Or something else?
> >
> > Object exists primarily because D didn't originally have
> > templates, and when you don't have templates, having a single
> > base class is the only way to have a function accept any class,
> > and for something like a container, you'd pretty much be forced
> > to use void* without Object if you don't have templates.
> > However, once templates were added to D, the benefits of Object
> > were significantly reduced, and it's arguably not a
> > particularly good idea to be writing code that operates on
> > Object. However, it's far too late in the game to get rid of
> > Object.
> >
> > At one point, it was decided to remove Object's member
> > functions, because having them on Object needlessly locks in a
> > particular set of attributes for those functions, and if we did
> > that, then there really wouldn't be much reason to use Object
> > directly, but that change has never happened, and it's not
> > clear that it's going to happen, since there are a number of
> > technical issues that make it a bit of a pain to do
> > (particularly if we don't want to break a lot of code). One of
> > the bigger issues is that the AA implementation in druntime
> > needs to be templated so that it doesn't need to operate on
> > Object, and that's proven to be a bit of a challenge.
> >
> > https://issues.dlang.org/show_bug.cgi?id=9769
> > https://issues.dlang.org/show_bug.cgi?id=9770
> > https://issues.dlang.org/show_bug.cgi?id=9771
> > https://issues.dlang.org/show_bug.cgi?id=9772
> >
> > - Jonathan M Davis
>
> I was actually referring to both. Override functions such as
> opCmp, opEquals, toString, toHash etc --wouldn't they be
> inherently expensive? I thought they are virtual functions. Also,
> with regards to casting, wouldn't this be an extra legwork? Both
> of these seem to be a performance handicap to me. But I'm no
> expert on this matter. Maybe the compiler optimises it away since
> normally you'd cast to a constant subclass.

Virtual functions do have a cost but not a huge one, and to a point, they're
kind of the whole point of classes. If you don't need inheritance, then use
a struct. D separates structs and classes so that classes have inheritance
and are always reference types (like in Java), whereas structs don't have
inheritance. Classes in D cost about what they would cost in C++ or Java.
Unlike C++, they do have an invisible monitor member to enable synchronized
to work, and public member functions are virtual by default, but in general,
calling a function on a class in D costs what it would to call a virtual
function in C++ - and if you don't need virtual functions, then why use a
class? You can mark individual member functions as final to devirtualize
them (assuming that they're not overriding a base class member), but if you
don't need any virtual functions, then you don't need inheritance, and you
don't need a class.

As for casting, I don't know what the concern is. You typically construct a
class object and then either reference it through a class reference of its
actual type or through a class reference of a base type, just like you would
in C++, Java, C#, etc. You don't typically need explicit casting, and
implicit casting is only going to happen if you assign the object to another
reference of a base type of the current reference. Casting class objects
shouldn't be any more expensive in D than it is in other languages.

Having Object exist doesn't really affect much of any of this. It just
provides a common base class. The functions that are on it don't need to be
there, and if we were doing things from scratch, they certainly wouldn't be,
but it doesn't make functions or casting more expensive. Any extra cost
that's there is inherent to inheritance in general, and that's the whole
reason that classes exist.

- Jonathan M Davis