You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GiNaCDE defines variables controlling its behavior in its header files. After including the headers, these variables are publicly available. At first, this is confusing because variables can be set that have never been explicitly defined in the user code. But there is the even greater problem of unintended variable shadowing:
#include<GiNaCDE/GiNaCDE.h>intmain()
{
output = maple; // Fine, setting the output for GiNaCDEint output = mathematica; // Shadowed variable, GCC 11 does not issue a warning!// Now we lost all access to the GiNaCDE output...
output = maple; // Sets local `output`, not the one of GiNaCDE
}
One way of making such errors less likely is creating a separate namespace for GiNaCDE, so that the user code becomes more explicit:
#include<GiNaCDE/GiNaCDE.h>intmain()
{
GiNaCDE::output = GiNaCDE::maple; // Fine, setting the output for GiNaCDEint output = GiNaCDE::mathematica; // Setting a local variable without shadowing
}
However, the problem remains that seemingly unrelated variables in the headers are changing the global behavior of the GiNaCDE library:
#include<GiNaCDE/GiNaCDE.h>voiddo_something_else()
{
// ...
output = mathematica;
}
intmain()
{
output = maple; // Fine, setting the output for GiNaCDEdo_something_else(); // Accidentally changed the global output
}
Proposal
I think the variables and commands for controlling the behavior of GiNaCDE could be encapsulated into one or several classes. This would make the public interface more intuitive and avoid unintentional resets or shadowing of interface variables. One (incomplete!) example would be
Description
GiNaCDE defines variables controlling its behavior in its header files. After including the headers, these variables are publicly available. At first, this is confusing because variables can be set that have never been explicitly defined in the user code. But there is the even greater problem of unintended variable shadowing:
One way of making such errors less likely is creating a separate
namespace
for GiNaCDE, so that the user code becomes more explicit:However, the problem remains that seemingly unrelated variables in the headers are changing the global behavior of the GiNaCDE library:
Proposal
I think the variables and commands for controlling the behavior of GiNaCDE could be encapsulated into one or several classes. This would make the public interface more intuitive and avoid unintentional resets or shadowing of interface variables. One (incomplete!) example would be
Related issues
openjournals/joss-reviews#3885
The text was updated successfully, but these errors were encountered: