Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-06-13 10:06:07

Hi All, Dave,

> OOP => different sized objects being handled through the same interface
>    => dynamic allocation   (- complicated)
>    => memory management    (- hard)
> and => reference semantics  (- hard to reason about)
>    => shared state         (- hard to reason about)
>    => MT synchronization
>    => deadlocks, races, and inefficiency
>
> In a nutshell, concept-based-runtime-polymorphism/type-erasure allows
> you to have runtime polymorphism while preserving value semantics.  The
> value of that win is very commonly underestimated.

(Sorry for being late, I had a lot to learn when reading about concept
based polymorphism, I hope I got them right)

Overall, I think you over dramatise the situation.

Dynamic allocation and memory management are one and the same drawback.
I guess that with <memory> C++03 has done huge steps forward to make
this easier. Granted, it's not perfect yet (I've seen many articles
recommending caution with shared_ptr), but I don't think it justifies
introducing value types everywhere.

Moreover, when using polymorphic value types implemented this way, you
are still paying for one dynamic allocation and one deletion per copy
of the object (this may be implementation–specific). Since those
objects are supposed to be copied frequently, I wonder whether this
will be a good trade of.

Shared state, synchronisation, deadlocks and races are, again, one
single aspect of the same problem. Though I'd agree that it is a good
thing to have more value types and go toward more functional
programming, I think the problem will not go away with (polymorphic)
value types alone: you'll need as well higher level parallelism
concepts (à la TBB) if you want to avoid shared state completely.

I have tried to see where I could use such types in the code I have
been writing recently. I have found a good candidate where I need to
pass a value across thread and library boundaries at the same time.
The thread boundary implies that I want to copy the object, the
library boundary that I'll loose type information (in that case).
While this may not be the perfect use case, it helped me realise two
things:
 - boost::variant is a good approximation of polymorphic value types,
less convenient but may be faster (no dynamic memory management) and
probably simpler to use.
 - I have no idea when and where one should use this paradigm. I had
implied that the scope of TypeErasure was to replace inheritance–based
polymorphism whenever possible. Now I think it may be more modest,
though it is unclear to me what is the actual field of application.
Could anyone tell me how they intend to use type erasure ?

Regards,

Julien