Jarrett Billingsley wrote:
On Mon, Feb 2, 2009 at 3:11 PM, Chris Nicholson-Sauls
<ibisbase...@gmail.com> wrote:
Or he's caching some very big/complex parameters in the code he's actually
writing... maybe. That said: do we have any assurance that, were the functor
class tagged as 'final', the call would cease to be virtual? If so, then
the only extra cost on the call is that of the hidden "this" sitting in ESI.
I still don't care for the memory allocation involved, personally, but if
these are long-lived functors that may not be a major problem. (Ie, if he
calls foo(?,X) a million times, the cost of allocating one object is
amortized into nearly nothing.)
Oh, I suppose I should also point out that if you made these functors'
methods final, they wouldn't be able to implement interfaces, since
interface implementations must be virtual. So, at that point, you're
using a final scope class - might as well use a struct anyway.
As far as I know, interface methods can still be final methods in a
class. final methods are only disallowed to be overridden further. But
it's perfectly fine to mark a method final, that overrides a method from
a super class. final so to say only works in one direction.
Then the compiler can optimize calls, if they are statically known to be
final. If not, it still has to do a vtable lookup on a method call, even
if the actually called method is final.
So it can still make sense to use a class instead of a struct.
