[CLN-list] modular polynomials

[Richard B. Kreckel]

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/>