stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: Run-Time Type Information
Date Wed, 20 Sep 2006 21:57:19 GMT
Farid Zaripov wrote:
>   MSVC (and ICC as well) have an option /GR
> -------------
> /GR (Enable Run-Time Type Information)
> This option (/GR) adds code to check object types at run time. When this
> option is specified, the compiler defines the _CPPRTTI preprocessor
> macro. The option is cleared (/GR-) by default.
> -------------
>   This option is turned off by default. But projects, which uses typeid
> or dynamic_cast operators must compiled with that option turned on.
>   I found using of typeid and dynamic_cast in 18.exception.cpp test and
> also dynamic_cast in include/loc/_locale.h (function __rw_get_facet())
> and in include/tr1/_smartptr.h (function dynamic_pointer_cast()).
>   Using of the function dynamic_pointer_cast() is found commented out in
> 2.smartptr.shared.cpp test.
>   Using of the function __rw_get_facet() is found in _locale.h (function
> has_facet()) but has_facet() used in many other places.
>   Should we enable this option by default to all projects or for the
> 18.exception project only?

I don't think we use dynamic_cast in the library sources. It is
true that dynamic_cast is being invoked in the library headers
but only in function templates that do not get instantiated in
the sources. So to get the dynamic_cast to work RTTI only needs
to be enabled in the sources (e.g., tests or examples) that make
use (i.e., call a specialization) of the template.

I also think that not enabling RTTI by default for compilers that
provide only optional support for the feature optional helps us
detect assumptions about it being always available.

IMO, the ideal solution would would be to enable RTTI only in
those tests (and examples) where it's needed and leaving it
turned off everywhere else (including the library sources). The
GNUmakefile infrastructure doesn't have a way to change compiler
options on a file-by-file basis (the Rogue Wave infrastructure
does but it's very clunky), but having that ability would be
useful. That said, the mechanism for this should be the same
for both the GNUmakefiles as well as for the Windows build
infrastructure. I'm not quite sure what the best solution
should be: should we introduce a separate (optional) file with
directives to enable/disable certain compiler or linker options
for each .cpp file? Or should we allow for these directives to
appear in a special section (e.g.) at the top of each .cpp file?
Are there other solutions? And what about the directives? What
level of complexity would they need to go into? They would at
least need to be able to distinguish different compilers, but
likely also compiler versions, as well as operating systems
and their versions. They would need to support conditionals.
And when would these directives be processed? At the time the
makefiles are generated or dynamically before each compilation?
The former would be faster, the latter more robust. Sounds like
a non-trivial feature...

Any suggestions?


View raw message