Closed bdorney closed 4 years ago
@mexanick should probably comment on the restrictions with the way this code has to be written to accommodate pure C
stuff vs. OO C++
stuff (I vaguely recall some discussion of the finer points of this in the past but definitely not enough to )
Well, the restriction is in the way how the module functions are exposed to module manager. So in principle namespaces eventually can be used, but I feel like it is an overkill and our project can be written in C.
Naturally implemented with the templated RPC methods.
Brief summary of issue
As we are increasing our CTP7 modules we should probably start to think about namespaces (or more aptly we should have thought about this from the beginning...?).
Right now the libraries include a lot of each and it might be time to further compartmentalise things.
Types of issue
Expected Behavior
Having namespaces something like:
amc::
forinclude/amc.h
vfat3::
forinclude/vfat3.h
,Maybe this is overkill?
Current Behavior
No namespaces are used in this repo.
Context (for feature requests)
Longer term maintenance and preventing compile issues from say global variable declaration.
For example relating to https://github.com/cms-gem-daq-project/ctp7_modules/issues/65. If we copy/paste necessary functions from
cmsgemos
several constants are declared in multiple of the required functions, namely:Perhaps they should be declared "globally" in
include/amc.h
and we introduce a namespaceamc::
but I'm not sure the best structure to use (e.g. ideally for maintainability we would want a similarly or at least logical structure that's used incmsgemos
or simply a structure that follows from the filename in question...?).