[C++-sig] Re: RTTI and image size
dave at boost-consulting.com
Sun Oct 19 23:01:50 CEST 2003
"Niall Douglas" <s_sourceforge at nedprod.com> writes:
> On 18 Oct 2003 at 9:17, David Abrahams wrote:
>> > How well does BPL work if RTTI is disabled?
>> It doesn't. RTTI is an integral part of how Boost.Python works.
> Sorry, I should have been clearer - does BPL need to obtain derived
> polymorphic information from base classes or is it fine with just
> static type info ie; the static type of whatever it has?
> I'm assuming from your mention of luabind that the answer is yes.
The answer is no. Quite a few Boost.Python features depend on the use
of dynamic_cast. You should not expect inheritance relationships or
shared_ptr conversions to work properly without dynamic RTTI... at
least. I'm not sure what else may depend on it.
The only thing I can recommend is that you use separate compilation
for the C++ guts of your project, and turn RTTI off there, then turn
it on for the compilation units that use Boost.Python. No
guarantees, of course, but it seems more likely to work than just
shutting it off altogether.
>> > I /really/ wish RTTI info was filterable ...
>> When and if Daniel Wallin and I get the Luabind/Boost.Python
>> integration done, there will be some support for users to plug in
>> their own hand-rolled type identification mechanisms... but don't
>> expect it to be pretty. You'll have to supply some C++ code. For
>> example, using Pyste to generate bindings using 100% Pure Python won't
>> be an option.
> Sounds to me like GCCXML is again the answer - where it sees calls to
> some luabind function with some type, it outputs the type into a file
> from where luabind can assign it a unique id.
I assume you mean Boost.Python, not luabind.
Anyway, you're essentially assuming that someone can figure out how to
generate smaller RTTI information than MSVC does already. "Don't
assume you can do the job better than the compiler already does" is a
cardinal rule for embedded programmers using C++; I don't see why it
shouldn't apply here just as well.
> I've noticed that on MSVC, if you disable RTTI it in fact only
> disables the polymorphic support bit - static type queries still work
> fine. Thus if BPL didn't need to know derived classes, you could
> safely leave it off and all those volumes of worst case scenario data
> could be left out because MSVC would only include info for those
> types queried (I've inspected assembly outputs under the various
> cases and this seems to be true).
> GCC as far as I understand it totally disables RTTI completely when
> you say so. I'm already having nightmarish visions of 50Mb .so's ...
GCC generates gigantic .so's if you leave debug info in them. Have
you tried MSVC with optimizations and no debug info?
More information about the Cplusplus-sig