One problem with the code.

Hi,

I am trying to go through the code. When I read about the following code:

#define COMMAND_CLASS
#define CommandStyle(key,Class)
(*command_map)[#key] = &command_creator;
#include “style_command.h”
#undef CommandStyle
#undef COMMAND_CLASS

I can’t find the style_command.h file in src directory. Also there are .h files containing CommandStyle.

Since there is undef at the end of the this code, will the CommandStyle in like balance.h files be executed?

Thanks very much!

Best!

Hao

Hi,

I am trying to go through the code. When I read about the following code:

#define COMMAND_CLASS
#define CommandStyle(key,Class)
(*command_map)[#key] = &command_creator;
#include “style_command.h”
#undef CommandStyle
#undef COMMAND_CLASS

I can’t find the style_command.h file in src directory. Also there are .h files containing

All style_xxx.h files are automatically generated and updated when you call make.

CommandStyle.

Since there is undef at the end of the this code, will the CommandStyle in like balance.h files be executed?

Yes, it is a preprocessor macros that is used to build a factory pattern, which in turn will create instances of the desired command classes as needed, mapping the command name to the specific derived class.

Axel

Thanks very much!

I am also wondering why there is #include “style_command.h”. When I check the style_xxx.h file in the hpc, I found that there are some other files like style_xxx.h file. Why not include these files? Thanks very much!

Best!

Hao

Thanks very much!
I am also wondering why there is #include "style_command.h". When I check
the style_xxx.h file in the hpc, I found that there are some other files
like style_xxx.h file. Why not include these files? Thanks very much!

as i already mentioned, those files are automatically generated during
the compilation.
they *must* not be included, because their contents depend on which
optional components are used in this specific compilation.

axel.

Thanks very much! I would go on learning the code.

Thanks very much! I would go on learning the code.

this really hasn't much to do with the code itself, but is mostly
about the build system and how this is all set up to minimize the
effort of the maintainers and developers when adding new features. on
the implementation side, LAMMPS makes extensive use of polymorphism
for this. to complement this, the build system uses preprocessor
macros, makefiles (with vpath-assisted pattern rules) and shell
scripts as well as the automatic dependency generation of most
compilers. the style_xxx.h files (among other things) are updated by
the Make.sh script, for example. this has grown over the years in
complexity, but on the other hand it has now reached a level of
sophistication, that casual developers don't need to worry about most
of that and experienced developers have less maintenance work. things
get even more complex, when you consider the many derived special
purpose variants (GPU, KOKKOS, USER-CUDA, USER-OMP) that depend on
their corresponding general purpose versions.

axel.