[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] [PATCH] Remove unnecessary definitions of pure virtual functio

From: Vadim Zeitlin
Subject: Re: [lmi] [PATCH] Remove unnecessary definitions of pure virtual functions
Date: Wed, 15 Mar 2017 13:59:49 +0100

On Wed, 15 Mar 2017 10:29:31 +0000 Greg Chicares <address@hidden> wrote:

GC> Interestingly, though, this example shows that, given Base::foo()=0, if any
GC> Derived::foo() returns, then an implementation of Base::foo() cannot be
GC> marked [[noreturn]] even if it cannot return...

 Sorry, why do you think this? Base::foo() could be marked as [[noreturn]],
according to my reading of the Standard (although, admittedly, this is
another of those not totally clear things about the attributes...), the
attribute only applies to the Base method and is not inherited by the
derived classes. So, in principle, this is possible.

 Notice that MSVC gives a warning about using [[noreturn]] with a non-void
function, so if we ever need to do something like this, we'd need to
suppress this warning for it. But it's "just" a warning and, in fact, I had
started by doing it like this before realizing that these pure virtual
methods definitions could be just removed and it did work (although I
didn't test that patch with gcc).

GC> so the language is acquiring more weird corner cases. I just read that
GC> "[[" is forbidden except as part of an attribute-specifier--7.6.1/6
GC> says this
GC>   y[[] { return 2; }()] = 2;
GC> is an error even though it couldn't possibly be an attribute. We just got
GC> the ability to write ">>" in "template<T, U<T>>", and now we've lost the
GC> (admittedly less useful) "[[".

 Yes, I'm not too worried about this one, ">>" was a real annoyance, while
this one seems to be a highly theoretical curiosity.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]