Project

General

Profile

Feature #639

Shadow CoCoA namespace to help guarantee portability (without ambiguity)

Added by John Abbott over 9 years ago. Updated over 9 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Safety
Target version:
Start date:
28 Oct 2014
Due date:
% Done:

0%

Estimated time:
Spent time:

Description

Some problems of ambiguity in the CoCoALib source code have recently arisen. They have appeared because recent versions of C++ have introduced functions in the ::std namespace with the same name as functions in the CoCoA namespace.

To help avoid future problems of ambiguity suddenly appearing we could, for each function in the CoCoA, define an (empty) function in a shadow CoCoA namespace having the same name. If our CoCoALib code is not ambiguous when the shadow namespace is visible then I think ambiguity cannot arise in the CoCoALib code whatever functions may be added to the ::std namespace.

Action: implement a "shadow" CoCoA namespace with declarations of functions (and classes?) having names the same as those in CoCoALib.


Related issues

Related to CoCoALib - Design #619: Modulus (for CRTMill) ambiguousClosed2014-09-09

Related to CoCoALib - Bug #631: Ambiguous: rank for matrix (in ex-matrix1.C)Closed2014-09-26

History

#1 Updated by John Abbott over 9 years ago

  • Priority changed from Normal to Low

I don't know if this would really be worth the trouble.

I'm not even entirely sure that it would give the guarantees I want: in issue #619 the problem was a template class whose name coincided with a function name in CoCoALib (so not simply the presence of another homonymous function in another namespace).

#2 Updated by John Abbott over 9 years ago

Perhaps it is not so crucial to do this; or, at least, there may be a good compromise.

It is irritating when an ambiguity pops up, but an ambiguity does not lead to incorrect program behaviour (a grave problem). Of course, new ambiguities will trigger source code maintenance.

Perhaps we could create the shadow namespace containing just copies of whatever was in ::std which caused the problem; this could be useful for developers using old C++ compilers (and old versions of the STL). This would be far less onerous than adding "fake" declarations of every CoCoALib function, and probably just as useful...

Also available in: Atom PDF