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 ex
On Sat, 28 Nov 2009 02:32:21 +0300, 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 an
== Quote from Walter Bright (newshou...@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
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 anot
== Quote from retard (r...@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
> > m
On Fri, 27 Nov 2009 22:58:00 -0500, retard 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-vir
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
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
== Quote from retard (r...@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
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.
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 opt
Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
> 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 us
On Fri, 27 Nov 2009 18:32:21 -0500, 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 an
Steven Schveighoffer wrote:
On Fri, 27 Nov 2009 18:32:21 -0500, 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
Leandro Lucarella wrote:
Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
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
vir
Walter Bright, el 1 de diciembre a las 11:17 me escribiste:
> Leandro Lucarella wrote:
> >Walter Bright, el 28 de noviembre a las 13:31 me escribiste:
> >>retard wrote:
> >>>Is this again one of those features that is supposed to hide the
> >>>fact that dmd & optlink toolchain sucks? At least gcc
On Tue, 01 Dec 2009 13:53:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 27 Nov 2009 18:32:21 -0500, 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 virtu
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> If the compiler could somehow
> optimize out all instances of the template function to reduce bloat, I
> think that would make it a little less annoying.
What is the sudden obsession with code bloat here lately? Check out this
S
On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha wrote:
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
If the compiler could somehow
optimize out all instances of the template function to reduce bloat, I
think that would make it a little less annoying.
What is the sudden obses
== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha wrote:
> > == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
> >> If the compiler could somehow
> >> optimize out all instances of the template function to reduce bloat
Steven Schveighoffer wrote:
On Tue, 01 Dec 2009 13:53:37 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Fri, 27 Nov 2009 18:32:21 -0500, Walter Bright
wrote:
Making them not virtual would also make them not overridable, they'd
all be implicitly final.
Is there any com
Tue, 01 Dec 2009 16:48:34 -0500, Steven Schveighoffer wrote:
> On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha wrote:
>
>> == Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article
>>> If the compiler could somehow
>>> optimize out all instances of the template function to reduce bloat, I
>
On Wed, 02 Dec 2009 01:36:54 -0500, retard wrote:
If it leaks 200 MB per day, people can already run it for a month on a
typical home PC before the machine runs out of physical memory (assuming
8GB physical RAM like most of my friends have these days on their
$500-600 systems).
Notice I said
Wed, 02 Dec 2009 13:15:33 -0500, Steven Schveighoffer wrote:
> I don't know what typical users you know, but the typical users I know
> do not reboot their computer unless it requires it. Most of the people
> I know have installed so much bloatware on their system that it takes 20
> minutes to bo
24 matches
Mail list logo
