git.saurik.com Git - wxWidgets.git/blame_incremental - docs/doxygen/overviews/cpprttidisabled.h

... / ...

Commit	Line	Data
	1	/////////////////////////////////////////////////////////////////////////////
	2	// Name: cpprttidisabled.h
	3	// Purpose: topic overview
	4	// Author: wxWidgets team
	5	// Licence: wxWindows licence
	6	/////////////////////////////////////////////////////////////////////////////
	7
	8	/**
	9
	10	@page overview_cpp_rtti_disabled Caveats When Not Using C++ RTTI
	11
	12	@tableofcontents
	13
	14	@note C++ RTTI is usually enabled by default in most wxWidgets builds. If you
	15	do not know if your build has C++ RTTI enabled or not, then it probably
	16	is enabled, and you should not worry about anything mentioned in this
	17	section.
	18
	19	While in general wxWidgets standard @ref overview_rtti is used throughout the
	20	library, there are some places where it won't work. One of those places
	21	is template classes.
	22
	23	When available, C++ RTTI is used to address this issue. If you have built the
	24	library with C++ RTTI disabled, an internal RTTI system is substituted.
	25	However, this system is not perfect and one proven scenario where it may break
	26	is a shared library or DLL build. More specifically, a template class instance
	27	created in one physical binary may not be recognized as its correct type when
	28	used in another one.
	29
	30	@see @ref overview_rtti, wxEvtHandler::Bind(), wxAny
	31
	32
	33
	34	@section overview_cpp_rtti_disabled_bind Bind() Issues
	35
	36	wxWidgets 2.9.0 introduced a new @ref overview_events_bind system, using
	37	wxEvtHandler::Bind<>() and Unbind<>(). This functionality uses templates
	38	behind the scenes and therefore is vulnerable to breakage in shared library
	39	builds, as described above.
	40
	41	Currently only Unbind<>() needs the type information, so you should be immune
	42	to this problem simply if you only need to use Bind<>() and not Unbind<>().
	43
	44	Also, if you only bind and unbind same event handler inside same binary, you
	45	should be fine.
	46
	47
	48
	49	@section overview_cpp_rtti_disabled_wxany wxAny Issues
	50
	51	wxAny is a dynamic type class which transparently uses templates to generate
	52	data type handlers, and therefore is vulnerable to breakage in shared library
	53	builds, as described above
	54
	55	You should be fine if you only create and use wxAny instances inside same
	56	physical binary. However, if you do need to be able to use wxAny freely
	57	across binary boundaries, (and for sake of code-safety, you probably do),
	58	then specializations for wxAnyValueTypeImpl<> templates need to be defined in
	59	one of your shared library (DLL) files. One specialization is required for
	60	every data type you use with wxAny. Easiest way to do this is using macros
	61	provided in wx/any.h. Note that you @b do @b not need to define
	62	specializations for C built-in types, nor for wxString or wxDateTime, because
	63	these are already provided in wxBase. However, you @b do need to define
	64	specializations for all pointer types except char* and wchar_t*.
	65
	66	Let's define a specialization for imaginary type 'MyClass'. In your shared
	67	library source code you will need to have this line:
	68
	69	@code
	70	WX_IMPLEMENT_ANY_VALUE_TYPE(wxAnyValueTypeImpl<MyClass>)
	71	@endcode
	72
	73	In your header file you will need the following:
	74
	75	@code
	76	wxDECLARE_ANY_TYPE(MyClass, WXIMPORT_OR_WXEXPORT)
	77	@endcode
	78
	79	Where WXIMPORT_OR_WXEXPORT is WXEXPORT when being included from the shared
	80	library that called the WX_IMPLEMENT_ANY_VALUE_TYPE() macro, and WXIMPORT
	81	otherwise.
	82
	83	*/