nmatrix
nmatrix copied to clipboard
Namespace-safe API for accessing dtype and stype enums in C API
Currently the data type enums are defined like this.
When including nmatrix.h in a C file, the macro expands to something like:
enum nm_dtype_t {
BYTE = 0,
INT8 = 1,
// ...
} nm_dtype_t;
it so happens that to call these enums in a file that includes nmatrix.h, one just needs to say INT8 and the relevant enum value (1 in this case) will be properly selected.
The problem is that INT8 does not preserve the nmatrix namespace in anyway.
Prefixing all the enums in the link above with NM_ when compiling with a C compiler might solve the problem.
@cjfuller @mohawkjohn thoughts? I think this is pretty important before we create a plug-in system and formalize APIs etc.
No it doesn't. Look at lines 166 and 198. These resolve differently for C and C++.
For a C compiler its not enclosed in any namespace and its not possible to call something like nm_dtype_t::FLOAT32.
Thus the enums ultimately resolve to:
enum nm_dtype_t {
BYTE = 0,
INT8 = 1,
INT16 = 2,
INT32 = 3,
INT64 = 4,
FLOAT32 = 5,
FLOAT64 = 6,
COMPLEX64 = 7,
COMPLEX128 = 8,
RATIONAL32 = 9,
RATIONAL64 = 10,
RATIONAL128 = 11,
RUBYOBJ = 12
} nm_dtype_t;
I used FLOAT32 in code. I did not need to use NM_FLOAT_32
That's odd. I was sure they used to be prefixed with NM_. Thanks for pointing this out. @cjfuller, do you have any recollections on this topic?
Huh, odd, I could have sworn they were prefixed too, but clearly not!
I guess this could be solved kind of analogously to the fix in #326 (possibly even replacing the fix there?) by defining a macro PFX (for "prefix") that adds a prefix in C and not in C++ mode?
so something like:
#ifdef __cplusplus
#define PFX(symbol) symbol
#else
#define PFX(symbol) NM_ ## symbol
#endif
and then e.g. lines 217-220 would be:
/* Storage Type -- Dense or Sparse */
NM_DEF_ENUM(stype_t, PFX(DENSE_STORE) = 0,
PFX(LIST_STORE) = 1,
PFX(YALE_STORE) = 2);
... pretty ugly, though.
I presume that there is no way to iterate over __VA_ARGS__ in a variadic preprocessor macro so that NM_DEF_ENUM can add prefixes automatically?
@v0dro Can you check the version history for this file and confirm that the prefixes didn't used to be there? I'm almost sure they were, and maybe it's just a matter of seeing how we did it before.
@mohawkjohn Couldn't find any evidence of presence of prefixes in the history of the file.
In that case, please do submit a patch. They should be NM_BYTE, etc.