Re: [boost] Formal Review Request: TypeErasure

Subject: Re: [boost] Formal Review Request: TypeErasure
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-06-13 13:45:08

on Wed Jun 13 2012, Julien Nitard <julien.nitard-AT-m4tp.org> wrote:

> 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.

Not if you account for the possibility of GC or shared pointers.

> 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, 

Says who?

> 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. 

Not if you account for the possibility of transactional memory.

> 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.

Of course.  And I don't want to avoid shared state completely.  I want
to avoid sharing state all over the place "by default."  By the way,
this affects single-threaded code too.  If you haven't heard of
"defensive copying" in the Java world, look it up.

> 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.

Not if you account for the need to have runtime-polymorphic functions.
Dispatching over a variant is still harder than overriding a virtual
function, and the set of choices is closed to extension.

>  - I have no idea when and where one should use this paradigm. I had
> implied 

Inferred?

> that the scope of TypeErasure was to replace inheritance–based
> polymorphism whenever possible. 

That's definitely one useful way to apply it.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com