AMDG On 11/20/2017 02:12 PM, Richard Hodges via Boost wrote:
None of these make copies. polymorphic_value is not called XXX_ptr precisely because its semantics are different from a pointer.
shared_ptr, unique_ptr and reference_wrapper are all "different" from a pointer, but they all share 4 common traits:
1. The all manage/observe lifetime of another _single_ object in some defined but distinct way.
This is stated in an overly general way to artificially make it cover cloning_ptr. Copying objects is in no way an extension of deleting objects when they are no longer needed.
2. They all allow access to that object through operator*
3. They don't propagate const.
4. they don't have any pointery arithmetic behaviour
Looking at the design history of polymorphic_value it seems that it originally came from a desire to complete the circle by providing another XXX_ptr which supported copying.
You shouldn't think of it as a pointer. polymorphic_value is not a pointer that copies automatically. It's a value that allows runtime polymorphism.
This aim is _eminently useful_ as is evidenced by the numerous implementations of things like it on github (and in my own code).
I also have an interest is such an object as standard because I always seem to end up needing one.
I do not have a use case for a const-propagating one. Never have. I can specify const in the angle-brackets. I've done that probably once.
This situation doesn't make sense for polymorphic_value.
To you perhaps. However I have 3 projects on the go right now which could use polymorphic_value immediately as a retro-fit for home-made solutions *if it did not propagate const*.
The concept of propagating const I can deal with trivially. To incorporate it into this class mixes concerns to the detriment of its usefulness (to me).
So If it came to a vote and my voice had any weight, I would say:
* with implicit const-propagation - NO
* remove the const propagation - absolute YES
additionally, ideally rename it back to cloned_ptr, (or indirect if you must). Because what it is absolutely not is a value.
How is it not a value?
It is logically the same as the other 4 non-pointers listed above, it's just that it have different owned-object lifetime behaviour.
I completely understand the value-centric argument. I am a strong proponent of it.
My argument is that this is (or ought to be) a tool for *building* value types. It is not in of itself a value type, and neither can it ever be. It does not exhibit any "value" behaviour (equality and the like).
I don't understand what you mean. The most important feature of a "value" is that copies are disjoint, which is precisely what copying the stored object guarantees. In Christ, Steven Watanabe