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