Project

General

Profile

Design #1168

ideal: does const ourGetPtr really need to be private?

Added by Anna Maria Bigatti about 6 years ago. Updated about 2 months ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Data Structures
Target version:
CoCoALib-0.99900
Start date:
15 Mar 2018
Due date:
% Done:

40%

Estimated time:
8.00 h
Spent time:
5.50 h

Description

To be able to call this

const SparsePolyRingBase::IdealImpl* const ptrI =
      SparsePolyRingBase::IdealImpl::ourGetPtr(I);

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

History

#1 Updated by John Abbott about 6 years 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 about 6 years 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 about 6 years 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.

#4 Updated by John Abbott 10 months ago

  • Target version changed from CoCoALib-1.0 to CoCoALib-0.99850

#5 Updated by Anna Maria Bigatti about 2 months ago

  • Target version changed from CoCoALib-0.99850 to CoCoALib-0.99900

Also available in: Atom PDF