title: Best C++ practice for retrieving variables from config files
body: <p>The use case is quite common: I have a few variables that should be accessible globally (by various classes) and initialized from a configuration file. I can't decide the best way to do this.</p>
  <ol>
  <li>Options struct is owned by someone and passed around:</li>
  </ol>
  <pre><code>struct Opts {
          int op1;
          double op2;
  };
  
  int main() {
          Opts o = {3, 0.5};
          // Pass this around as const reference, or potentially copying
          return 0;
  }
  </code></pre>
  <ol start="2">
  <li>Use static vars for some Options struct.</li>
  </ol>
  <pre><code>struct Opts {
          inline static int op1;
          inline static double op2;
  };
  
  int main() {
          Opts::op1 = 3;
          Opts::op2 = 0.5;
          // No passing around, but use Opts::op1 instead
          return 0;
  }
  </code></pre>
  <ol start="3">
  <li>Use static vars, but sorta differently (not really).</li>
  </ol>
  <pre><code>struct Opts {
          static int op1;
          static double op2;
  };
  int Opts::op1;
  double Opts::op2;
  
  int main() {
          Opts::op1 = 3;
          Opts::op2 = 0.5;
          // No passing around, but use Opts::op1 instead
          return 0;
  }
  </code></pre>
  <p>What should I actually do here? I thought the best case would be static const vars to make sure no one changes these, but the values can only be obtained from some file (so seems like it has to be run time instead of compile time), even though they won't change at after initializing.</p>
  <p>I <em>could</em> make it const refs if I don't make it static, but that just forces me to pass this around among many classes. I also wanted the class that <em>owns</em> these options to be different from the class that <em>parses</em> them. This would just be even uglier with either moving unique_ptr or copying.</p>
  <p>Is there a way to get best of both worlds:</p>
  <ol>
  <li>not having to pass things around excessively (hence the semantics of &quot;static&quot;)</li>
  <li>making sure that these can't be modified after initialization, at least indicating that is the case (hence the semantics of &quot;const&quot;)?</li>
  </ol>