[cfe-dev] MSVC RTTI implementation status

David Majnemer david.majnemer at gmail.com
Tue Feb 25 00:44:00 PST 2014


The code that actually performs the dynamic_cast is not actually emitted by
the compiler.  The behavior you are seeing is not coming from the compiler
but from the __RTDynamicCast function.

Clang's job is to call __RTDynamicCast with the correct arguments, nothing
more.

The Itanium ABI, utilized by OS X and Linux, specifies that this cast is
performed by __dynamic_cast.  Again, all we do is provide the necessary
argument to this function and let the underlying runtime do the rest.

This behavior is not really up to us to emulate.

Also note that the ability to handle these kinds of memory exceptions
happens under the aegis of SEH, making an already heavyweight operation
even heavier.

On Mon Feb 24 2014 at 1:33:35 AM, Domagoj Saric <
domagoj.saric at littleendian.com> wrote:

> On 24.2.2014. 7:53, David Majnemer wrote:
> > I don't think it would be unreasonable for us to maintain a list of
> things we do
> > and do not claim to support.
>
> FWIW, MSVC's RTTI implementation has one nice property (which I'd like if
> Clang
> could also 'emulate'): it (dynamic_cast) does not crash on objects w/o an
> RTTI
> record (while Clang under OSX always crashed for me in those cases).
> Such a case, for example, often arises if you use a (lame) GUI library
> which
> requires RTTI (because it relies on dynamic_cast and cross-casting) so you
> enable RTTI for its sources but disable it for others/your own sources (in
> order
> to minimize bloat and the leaking of internal implementation details as
> plain
> text in the final binary). Then when the GUI lib calls dynamic_cast on one
> of
> your own objects (because you, for example, added it to some widget
> container)
> it will simply get a nullptr result with MSVC (while, as I mentioned,
> you'll get
> a crash with Clang)...
>
>
>
> --
> Domagoj Saric
> Software Architect
> www.LittleEndian.com
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140225/7781df46/attachment.html>


More information about the cfe-dev mailing list