[CLN-list] modular polynomials
Richard B. Kreckel
kreckel at ginac.de
Sat Sep 27 21:20:03 CEST 2008
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
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
What do you think?
Richard B. Kreckel
More information about the CLN-list