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
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,
> 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
> - 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
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk