Hi! Alexei Sheplyakov wrote:
You can introduce a new class, say, cl_UP_coefficients or cl_UP_embryo, that has a set_coeff method and a finalize method that returns a cl_UP. cl_UP will lose these methods, but have a constructor that takes a cl_UP_coefficients argument.
Folks, please correct me, if I am wrong: Aren't C++ developers aware of the costs of deep copying and are accustomed to passing arguments as references, do acrobatic exercises with const_iterator's and all this? Many such idioms are becoming the de-facto lingua franca, precisely because of the costs of operator= and the copy ctor. It may not be as syntactically elegant as it could be, but only a few percent of C++ programmers are aware of this. (Case in point: GiNaC has shallow copying and COW semantics. I once did an experiment and passed all arguments as const ex instead of const ex&. It made it noticably slower. The reason is the overhead induced by maintaining the refcount.)
Changing the coefficients is a common operation (think of division, GCD, etc). So this crippled^W immutable cl_UP is next to useless.
2) The other option is to keep the current design and have set_coeff and finalize throw an exception when the reference count is > 1. And, of course, document the behaviour
I think this is the only sane option.
and provide a separate function for "deep copying" of a polynomial.
What about a copy constructor?
I do not really understand: Are we really discussing the option to have deep copying, but name it strangely, ie. other than operator=? (Of course, we should implement operator= and the copy ctor in a symmetrical way. If they are really frowned upon, then we should just declare them private and not implement them. This should guarantee that the refcount is never incremented. But I'm far from convinced this is a good idea.) What do you think? Bye! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>