Richard, thanks for the detailed reply. Const correctness is noted for my next submission (which will be to you), as well as testing. I understand from your comments that, while factor() will go into CLN, divisors() won't.
Now I do have two questions: What do you mean by adapting CLN's memory scheme to STL?
As far as I understand, CLN doesn't use new/delete and its objects are allocated using malloc_hook. OTOH, it may not be sufficient to malloc_hook sizeof(std::vector<...>) and give that to the caller since STL might itself allocate space using its own (default) allocator in the process. If that is really of concern, the solution could be to write an allocator (STL object) using malloc_hook for that and other cases. That was what I meant. Meanwhile, I favor moving the burden of space allocation to the caller via working on a referenced vector of pairs of cl_Is.
The user-visible side of the bridge constitute perfectly copyable objects with value semantics and are hence suited for STL, right?
CLN's objects are suited for STL, of course, since STL uses the object's interface. I was sceptical about the reverse, i.e., if STL deletes everything(!) it creates with its normal malloc. The user relies on garbage collection of an STL container with CLN objects that is returned by CLN. But the point is moot, anyway, with factor having the interface int factor (const cl_I& n, std::vector<std::pair<cl_I,cl_I> >& pv);
Just have a look at the Bernoulli number cache in GiNaC. Second, is std::list< factor_exponent_pair_or_whatever > really a wise decision?
I used the word 'list' not careful enough, sorry. I meant 'container'.
Well, sorry for the late answer.
I would have waited for it but nothing in CLN indicates who is its maintainer, so I was unsure if I mailed to the right address. Regards, ralf