Design #1168

ideal: does const ourGetPtr really need to be private?

Added by Anna Maria Bigatti 4 months ago. Updated 4 months ago.

In Progress
Data Structures
Target version:
Start date:
15 Mar 2018
Due date:
% Done:


Estimated time:
8.00 h
Spent time:


To be able to call this

const SparsePolyRingBase::IdealImpl* const ptrI =

many functions need to be //friend//.
Can we make this public?
Or is it too dangerous?


#1 Updated by John Abbott 4 months ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

If many functions have to be friend that is not a good sign.
I'm too busy to think about it now, so suggest making it public with a comment that this is makeshift solution that has to be properly considered at some point in the future.

#2 Updated by Anna Maria Bigatti 4 months ago

  • % Done changed from 10 to 40
  • Estimated time set to 8.00 h

After discussing with John, I made it public.
Indeed the rest of the code is clenear, i.e. we do not need so many friend functions, so the new files SparsePolyOps-ideal/involutive.H make take the heavy content of SparsePolyRing.H.
On the bad side, this exposes an implementation detail (the pointer) and this, says John, shows that the design is not quite correct.

#3 Updated by Anna Maria Bigatti 4 months ago

It is very convenient having it public :-) :-)

... but today I used it to set the radical/maximal/... flags at the end of the function IdealOfPoints and I didn't need to make it friend.
Convenient, but dangerous.

Also available in: Atom PDF