View mode: basic / threaded / horizontal-split · Log in · Help
November 27, 2009
Should operator overload methods be virtual?
Making them not virtual would also make them not overridable, they'd all 
be implicitly final.

Is there any compelling use case for virtual operator overloads? Keep in 
mind that any non-virtual function can still be a wrapper for another 
virtual method, so it is still possible (with a bit of extra work) for a 
class to have virtual operator overloads. It just wouldn't be the default.
November 27, 2009
Re: Should operator overload methods be virtual?
On Sat, 28 Nov 2009 02:32:21 +0300, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Making them not virtual would also make them not overridable, they'd all  
> be implicitly final.
>
> Is there any compelling use case for virtual operator overloads? Keep in  
> mind that any non-virtual function can still be a wrapper for another  
> virtual method, so it is still possible (with a bit of extra work) for a  
> class to have virtual operator overloads. It just wouldn't be the  
> default.

I thought operator overloading was going to be implemented via templates.  
As such, they are non-virtual by default, which is okay, in my opinion.
November 28, 2009
Re: Should operator overload methods be virtual?
== Quote from Walter Bright (newshound1@digitalmars.com)'s article
> Making them not virtual would also make them not overridable, they'd all
> be implicitly final.
> Is there any compelling use case for virtual operator overloads? Keep in
> mind that any non-virtual function can still be a wrapper for another
> virtual method, so it is still possible (with a bit of extra work) for a
> class to have virtual operator overloads. It just wouldn't be the default.

What would making them non-virtual accomplish?  I don't think making them
non-virtual would hurt too much in practice, but it would introduce an
inconsistency into the language relative to "regular" methods.  Therefore, I don't
think it should be done without a very good reason.
November 28, 2009
Re: Should operator overload methods be virtual?
Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:

> Making them not virtual would also make them not overridable, they'd all
> be implicitly final.
> 
> Is there any compelling use case for virtual operator overloads? Keep in
> mind that any non-virtual function can still be a wrapper for another
> virtual method, so it is still possible (with a bit of extra work) for a
> class to have virtual operator overloads. It just wouldn't be the
> default.

Is this again one of those features that is supposed to hide the fact 
that dmd & optlink toolchain sucks? At least gcc can optimize the calls 
in most cases where the operator is defined to be virtual, but is used in 
non-polymorphic manner.
November 28, 2009
Re: Should operator overload methods be virtual?
== Quote from retard (re@tard.com.invalid)'s article
> Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
> > Making them not virtual would also make them not overridable, they'd all
> > be implicitly final.
> >
> > Is there any compelling use case for virtual operator overloads? Keep in
> > mind that any non-virtual function can still be a wrapper for another
> > virtual method, so it is still possible (with a bit of extra work) for a
> > class to have virtual operator overloads. It just wouldn't be the
> > default.
> Is this again one of those features that is supposed to hide the fact
> that dmd & optlink toolchain sucks? At least gcc can optimize the calls
> in most cases where the operator is defined to be virtual, but is used in
> non-polymorphic manner.

If so, I think it's a bad idea.

1.  Eventually, we will get a better optimizer.  GDC has been resurrected, and
after D2 is finalized and all of the more severe bugs are fixed, hopefully Walter
will have some time to focus on performance issues.

2.  This optimization can trivially be done manually by declaring the overloads
final.  What would we gain by introducing the inconsistency with "normal" methods?
November 28, 2009
Re: Should operator overload methods be virtual?
On Fri, 27 Nov 2009 22:58:00 -0500, retard <re@tard.com.invalid> wrote:

> Fri, 27 Nov 2009 15:32:21 -0800, Walter Bright wrote:
>
>> Making them not virtual would also make them not overridable, they'd all
>> be implicitly final.
>>
>> Is there any compelling use case for virtual operator overloads? Keep in
>> mind that any non-virtual function can still be a wrapper for another
>> virtual method, so it is still possible (with a bit of extra work) for a
>> class to have virtual operator overloads. It just wouldn't be the
>> default.
>
> Is this again one of those features that is supposed to hide the fact
> that dmd & optlink toolchain sucks? At least gcc can optimize the calls
> in most cases where the operator is defined to be virtual, but is used in
> non-polymorphic manner.

Yes and no. Yes, DMD doesn't have link time optimization (LTO), which is  
what enables this. No, because LTO can't do this optimization in many  
cases, such as creating/using a DLL/shared object. (Static libraries might  
also have some issues, but I'm not sure.)
November 28, 2009
Re: Should operator overload methods be virtual?
dsimcha:
> but it would introduce an
> inconsistency into the language relative to "regular" methods.

Right, it's an exception to a rule of the language, so it increases the language complexity.

Bye,
bearophile
November 28, 2009
Re: Should operator overload methods be virtual?
== Quote from retard (re@tard.com.invalid)'s article
> Sat, 28 Nov 2009 08:16:33 -0500, bearophile wrote:
> > dsimcha:
> >> but it would introduce an
> >> inconsistency into the language relative to "regular" methods.
> >
> > Right, it's an exception to a rule of the language, so it increases the
> > language complexity.
> I guess the systems programming language users more often think that
> 'more executable bloat when compiled with the currently available
> practical real world tools, the more complex the language in practical
> real world use'. So if there's some tiny little feature that saves you
> 1-2 cpu cycles in practical real world systems programming applications
> or makes building a practical real world non-academic commercial compiler
> a bit easier and thus provides more practical value to the paying
> customer, the language should include that feature.

Ok, well then how does making operator overloads implicitly final improve over
being consistent with the rest of the language and making them explicitly final if
you want them final?

Note:  I'm not against making overloading non-virtual if it's implemented with
templates, because this is non-arbitrary and consistent with the rest of the
language.  I'm only against it if it's done arbitrarily by treating operator
overload functions as "special" in this regard.
November 28, 2009
Re: Should operator overload methods be virtual?
Denis Koroskin wrote:
> I thought operator overloading was going to be implemented via 
> templates. As such, they are non-virtual by default, which is okay, in 
> my opinion.

Yes, that's the rationale. I'm looking for a hole in it.
November 28, 2009
Re: Should operator overload methods be virtual?
retard wrote:
> Is this again one of those features that is supposed to hide the fact 
> that dmd & optlink toolchain sucks? At least gcc can optimize the calls 
> in most cases where the operator is defined to be virtual, but is used in 
> non-polymorphic manner.

The gnu linker (ld) does not do any optimizations of virtual call => 
direct call. Optlink has nothing to do with it.

  struct C {
    virtual int foo() { return 3; }
  };

  void bar(C* c) {
    c->foo();   <== no virtual call optimization here (1)
  }

  int main() {
    C* c = new C();
    c->foo();   <== virtual call optimization here (2)
    bar(c);
    return 0;
  }

What D doesn't do is (2). What D does do, and C++ does not, is allow one 
to specify a class is final or a method is final, and then both (1) and 
(2) will be optimized to direct calls.

Doing (2) is entirely a function of the front end, not the linker.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home