wxWidgets/docs/doxygen/overviews/cpprttidisabled.h
Vadim Zeitlin 3f66f6a5b3 Remove all lines containing cvs/svn "$Id$" keyword.
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.

If nothing else, this will make an eventual transition to Git simpler.

Closes #14487.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2013-07-26 16:02:46 +00:00

84 lines
3.2 KiB
C

/////////////////////////////////////////////////////////////////////////////
// Name: cpprttidisabled.h
// Purpose: topic overview
// Author: wxWidgets team
// Licence: wxWindows licence
/////////////////////////////////////////////////////////////////////////////
/**
@page overview_cpp_rtti_disabled Caveats When Not Using C++ RTTI
@tableofcontents
@note C++ RTTI is usually enabled by default in most wxWidgets builds. If you
do not know if your build has C++ RTTI enabled or not, then it probably
is enabled, and you should not worry about anything mentioned in this
section.
While in general wxWidgets standard @ref overview_rtti is used throughout the
library, there are some places where it won't work. One of those places
is template classes.
When available, C++ RTTI is used to address this issue. If you have built the
library with C++ RTTI disabled, an internal RTTI system is substituted.
However, this system is not perfect and one proven scenario where it may break
is a shared library or DLL build. More specifically, a template class instance
created in one physical binary may not be recognized as its correct type when
used in another one.
@see @ref overview_rtti, wxEvtHandler::Bind(), wxAny
@section overview_cpp_rtti_disabled_bind Bind() Issues
wxWidgets 2.9.0 introduced a new @ref overview_events_bind system, using
wxEvtHandler::Bind<>() and Unbind<>(). This functionality uses templates
behind the scenes and therefore is vulnerable to breakage in shared library
builds, as described above.
Currently only Unbind<>() needs the type information, so you should be immune
to this problem simply if you only need to use Bind<>() and not Unbind<>().
Also, if you only bind and unbind same event handler inside same binary, you
should be fine.
@section overview_cpp_rtti_disabled_wxany wxAny Issues
wxAny is a dynamic type class which transparently uses templates to generate
data type handlers, and therefore is vulnerable to breakage in shared library
builds, as described above
You should be fine if you only create and use wxAny instances inside same
physical binary. However, if you do need to be able to use wxAny freely
across binary boundaries, (and for sake of code-safety, you probably do),
then specializations for wxAnyValueTypeImpl<> templates need to be defined in
one of your shared library (DLL) files. One specialization is required for
every data type you use with wxAny. Easiest way to do this is using macros
provided in wx/any.h. Note that you @b do @b not need to define
specializations for C built-in types, nor for wxString or wxDateTime, because
these are already provided in wxBase. However, you @b do need to define
specializations for all pointer types except char* and wchar_t*.
Let's define a specialization for imaginary type 'MyClass'. In your shared
library source code you will need to have this line:
@code
WX_IMPLEMENT_ANY_VALUE_TYPE(wxAnyValueTypeImpl<MyClass>)
@endcode
In your header file you will need the following:
@code
wxDECLARE_ANY_TYPE(MyClass, WXIMPORT_OR_WXEXPORT)
@endcode
Where WXIMPORT_OR_WXEXPORT is WXEXPORT when being included from the shared
library that called the WX_IMPLEMENT_ANY_VALUE_TYPE() macro, and WXIMPORT
otherwise.
*/