There are several instances of using namespace X at namespace level which pulls in probably unexpected classes. Such things should be restricted to individual classes and/or at class level so the scope of this is limited.
Although one could argue, that a using namespace PMacc in the picongpu namespace makes sense as both are very related, I would refrain from doing so. It recently led to a strange issue encountered by @Heikman where PMacc::FrameType (an enum) is unexpectedly used for FrameType (actual particle frame)
I therefore suggest removing all using namespace X at namespace level, replacing class usages by fully qualified ones. If required, (local) namespace aliases or local namespace imports shall be used. This should also go into the coding conventions.
There are several instances of
using namespace X
at namespace level which pulls in probably unexpected classes. Such things should be restricted to individual classes and/or at class level so the scope of this is limited. Although one could argue, that ausing namespace PMacc
in the picongpu namespace makes sense as both are very related, I would refrain from doing so. It recently led to a strange issue encountered by @Heikman wherePMacc::FrameType
(an enum) is unexpectedly used forFrameType
(actual particle frame)However this (https://github.com/ComputationalRadiationPhysics/picongpu/blob/4482d0bdc599e86bca2770c879b25030bf087aec/src/picongpu/include/plugins/hdf5/restart/RestartFieldLoader.hpp#L174-L175) is actually a sin! :smiling_imp: It pulls in
PMacc
intopicongpu::hdf5
where it certainly does not belong.I therefore suggest removing all
using namespace X
at namespace level, replacing class usages by fully qualified ones. If required, (local) namespace aliases or local namespace imports shall be used. This should also go into the coding conventions.