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