1

I'm currently developing a project which has multiple c++ programs communicating over IPC to each other. Each of these programs will rely on some parameters to run and these may be common to several programs, e.g.parameters for camera calibration, minNeighbours, scaling factor, etc.

I am wondering what the best practices are for achieving this. Solutions being considered at this stage are:

  1. Hardcoding the values in - obviously not good if I should ever want to change the values of the parameters.

  2. Include a constants.hpp file containing const [int] variable definitions - my current solution.

  3. A config.txt file which can be parsed by each program at its start-up - can multiple programs safely open and read files concurrently.

  4. Preprocessor directives, i.e. #define.

I can implement any solution, I'm really looking for guidance on best practices.

4
  • Do these parameters need to have the same value across all programs? Do they change often? Do you need to store the results somewhere? Along with the parameters? These are important constraints to consider for your design.
    – user44761
    Commented Aug 24, 2017 at 12:49
  • The parameters will be global and will have the same value across every program in the entire system. Generally speaking, they will not change throughout the lifetime of the program however a few may change very rarely - would it then be better to have the changeable parameters in a file and constant parameters defined in code? Results will be stored elsewhere, we are only concerned with the inputs to the programs at this stage.
    – AndyM
    Commented Aug 24, 2017 at 13:00
  • 2
    This question is too broad. A good answer would fill a book, or the better part of a class. Think about your specific situation, and narrow your question to something more specific. What is currently your most pressing design concern? Commented Aug 24, 2017 at 14:52
  • Are all programs running on the same computer? And what operating system? Commented Aug 25, 2017 at 5:00

2 Answers 2

2

Only load a constant from a config-file or other runtime-config-source if it actually makes sense to execute the program with different values for the parameter.
Consider supporting a default if not provided by the config where it makes sense.

Needlessly exporting a compile-time-constant into a run-time-config makes for more complicated and less efficient code which can go wrong in more ways than before. Desist.

When should you name a compile-time-costant?

  • If it has some semantic meaning beside it happening to have a specific value, meaning you should have a good semantic instead of descriptive name for it.
  • If you use it to tune your code. These constants nearly always also fall under the other point.
0

Put the config in a dbase / shared location or just give each file a copy of the config. Eg when deploying it just copy the same file over and over

There should be no problem in more than one application reading the file (your only reading from it) just open it for shared usage.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.