On 09/02/13 10:15, Ralph Tandetzky wrote:
2. For a property tree, that looks in essence like this:
class PropertyTree : public AbstractProperty { public: /* implementation of the public interface */
private: std::list<cow_ptr<AbstractProperty>> properties; };
Instead of std::list<cow_ptr<AbstractProperty>> you might as well use cow_ptr<std::list<AbstractProperty>> instead.
The latter wouldn't allow polymorphism, which would be a problem. I suppose you meant cow_ptr< std::list< cow_ptr<AbstractProperty> > >. That kind of usage however does allow to share subtrees, and I can see how this can be really useful if you do a lot of out-of-place tree transformations (which is, AFAIK, the most popular approach for tree transformations).
I would really like to get feedback on the design of cow_ptr<T> <https://github.com/ralphtandetzky/cow_ptr.git> rather than discussing, if copy-on-write is a useful pattern in general.
This utility of yours is very similar to things that have existed in the C++ world for a good 10 years. There has been many other implementations, many other slightly different designs and there are also proposals for standardization. Furthermore COW does not appear to be strictly necessary to provide the required behaviour, so it seems there is unnecessary coupling here. I advise you to start by solving the issues with API and cloning requirements first. Once that's done, you can choose to use COW or not as a backend, but that's mostly transparent to the user and a QoI issue. I don't know the status of the proposal, but you also have to recognize that doing the same thing as a standard proposal but in an incompatible way is not something very positive, unless you can point out why the standard proposal is wrong and take steps to have it corrected.