Workaround for typeid access violation

[rsw0x via Digitalmars-d]

On Tuesday, 16 June 2015 at 20:30:50 UTC, Etienne wrote:
> On Tuesday, 16 June 2015 at 20:08:36 UTC, rsw0x wrote:
>> You're attempting to use GC for a problem that they don't 
>> solve because you don't have other tools to fix it. When all 
>> you have is a hammer, everything looks like a nail.
>
> Well no, I have plenty of tools. I use a memory library that 
> does a wide range of everything I need 
> https://github.com/etcimon/memutils .. It's not like I'm 
> reliant only on it, like it's my hammer and I only see nails..
>
> It's simply easier to manage the lifetime of objects through 
> the GC because sometimes I have them referred to as delegates 
> at a lower level. I like having finalizers because those 
> objects may hold thread-local containers.

A GC is not for managing an object's lifetime. There are no 
guarantees from the GC.

>
> Isn't that what we'd want? To use the GC only when it's 
> important and manual memory management at other times? What 
> happens when you need the two and your manually allocated 
> objects are tracked by a GC-allocated object?

The correct answer would be for the GC object to be upgraded to 
an RCO because the resource's lifetime is now bound to the GC 
object.

>
> I think you're the one who's actually looking at everything 
> like a nail wrt improving performance in benchmarks.

No, I'm looking at correctness and not piling hack upon hack that 
will fall apart at the first sneeze to the GC codebase. 
Performance just happens to be a side effect of correctness.