Automatic removal of RTTI (as well as automatic removal if method
virtuality) could have very unpleasant effects in modular
architectures.
Consider this use case:
// Base.dll
class Base
{
string method() { return "Base"; }
}
// Derived.dll
class Derived: Base
{
string method() { return "Derived"; }
}
Base baseFactory()
{
return new Drived;
}
// Main.exe
export Base createBase
void main()
{
Base b = baseFactory();
writeln(b.method());
}
When compiling Base.dll, the compiler doesn't see any class deriving
from it, so it can remove the method from vtbl,
In that case a Base. returned from Base.dll would be a completely
different class, then a Base, returned from Derived.dll, since their
vtbl would differ. This would lead to major problems with functions,
expecting a certain ABI, but getting a different ABI.
This is an unnecessary inconsistency. marking methods as final is
purely optimization technique in this case and performance should
never cost consistency.
The compiler could emit recommendations about potentially inconsistent
optimizations.
On Fri, Oct 21, 2011 at 11:35 AM, Marco Leise <marco.le...@gmx.de> wrote:
> Am 21.10.2011, 09:20 Uhr, schrieb Gor Gyolchanyan
> <gor.f.gyolchan...@gmail.com>:
>
>> Actually, the best idea would be to enable full reflection (much more
>> complete, then what we have now) by default and allow to remove it on
>> demand.
>> Just like the methods being virtual by default, but with ability to
>> make them final.
>
> As far as I know that is just what the programmer sees. If the compiler can
> verify that the method doesn't need to be virtual it will make it static by
> default. In terms of RTTI it would resemble to "add RTTI to a type only when
> we cannot be sure it isn't needed".
>
