CoCoA » CoCoALib

JAA is currently assessing how useful/necessary RefRingElem is; the hope is that they can simply be eliminated (along with the associated difficulties -- see #221).

I am considering eliminating the type RefRingElem. To do this I must find out where the type is used.

The type RefRingElem appears in many function signatures because the guidelines were to use it whenever a modifiable "ring elem" was to be passed; the understanding being that a true RingElem is automatically converted to RefRingElem by C++ automatically passing to a base class. If the class RefRingElem is eliminated then all these formal parameters would naturally be replaced by ones of type RingElem&.

The crucial question is where are true RefRingElem objects created?
And in each case can a reasonable alternative implementation be found?

• A ModuleElem::operator[] for non-const values; also the myCompt member fn
• B <matrix>::myRefEntry
• C RefLC for DistrMPolyClean and DistrMPolyInlPP
• D RingWeyl::myMulByPP and RingWeyl::myReductionStep

Case A is probably a mistake in design; it is not used anywhere in CoCoALib/CoCoA-5, so can easily be eliminated (and probably replaced by a SetEntry procedure as for matrices).

Case B the result of myRefEntry is used only inside BlockMatrix::mySetEntry and ConcatVerImpl::mySetEntry; a member fn similar to myRefEntry is fairly essential, but it could return simply a RingElemRawPtr. Overall: it would not be too problematic to eliminate use of RefRingElem in this case.

Case C the result of RefLC is used in just two places, and in fact only the RingElemRawPtr is used. It would be easy to redefine RefLC to produce a RingElemRawPtr.

Case D the two uses of RefRingElem can be eliminated, but will lead to a slight uglification of the code.

I have modified the source code in the 4 areas indicated in my previous post. It all compiles and the tests pass.

Case A: I simply commented out the code; no further changes were needed as the troublesome functions were never called anywhere.

Case B: I replaced all myRefEntry mem fns with myRawEntry; the only uses are in some mySetEntry mem fns, and I'm undecided whether the modified code is better or worse than before -- it is slightly harder to read, but also more explicit.

Case C: I replaced RefLC with RawLC which gives a raw ptr to the LC -- an ugly workaround. I'm hoping to find a cleaner solution.

Case D: the fn RingWeylImpl::myMulByPP is no better or worse than before; RingWeylImpl::myReductionStep is a little less readable than before (but still just about acceptable).

I have implemented a reasonably clean solution to case C; it is exception safe but does make a "wasteful copy".

I have commented out the class RefRingElem and replaced it with a typedef for RingElem&. There were a few further manual changes too. Everything compiles, and the tests all pass. Some dodgy code was highlighted by the compiler -- this shows that the 3 layer hierarchy ConstRefRingElem to RefRingElem to RingElem was in fact flawed!

Next step is to text-replace RefRingElem with RingElem& (and hope that everything still compiles afterwards).

confirm: all compiles and runs smoothly :-)