title: C++ look-up-table for modbus slave
body: <p>I have C firmware that implements a modbus slave. Once my RTU command (say func 03 "register read") is received I simply go to a LUT and fetch the data I need to return. My data structs are global. My array looks something like this:</p>
  
  <pre><code>int* modbusLUT[]={
                     &amp;motorControl_t.counter.degrees,
                     &amp;motorControl_t.counter.dir,
                     &amp;glueControl_t.nozzle.temp,
                     &amp;paintControl_t.hopper.level,
  ...
  };
  </code></pre>
  
  <p>and I build the modbus reply something like this:</p>
  
  <pre><code>temp = *modbusLUT[startAddr+j];
  ...
  </code></pre>
  
  <p>This <strong>single thread</strong> code works great and rather efficient. </p>
  
  <p>I'm now writing separate C++ "system manger" code that is essential headless and it too must act like a modbus slave. I intend to wrap the mechanics of the system into three classes. Each class is created on the heap and starts it's <strong>own thread</strong> awaiting events from main(). Something like this:</p>
  
  <pre><code>m_ptrMotorMachine = new CMotorMachine();
  m_ptrGlueMachine  = new CGlueMachine();
  m_ptrPaintMachine = new CPaintMachine();
  ...
  m_ptrGlueMachine-&gt;m_pThread-&gt;PostThreadMesageA(SW_PART_IN_PLACE,0,0);
  </code></pre>
  
  <p>I need parameters (member variable) from all three classes available so that my modbus handler can access and read/write them...  Ideally like the C array above.</p>
  
  <p>So, how can I safely do something like above in C++? Need locks? Pseudo code something like this:</p>
  
  <pre><code>class CModBusSlave{
  void initLUT()
     {
      int* modbusLUT[]={
                       &amp;m_ptrMotorMachine-&gt;velocity,
                       &amp;m_ptrMotorMachine-&gt;accel,
                       &amp;m_ptrGlueMachine-&gt;psi,
                       &amp;m_ptrPaintMachine-&gt;stroke,
                       ...
                       };
     };       
  };
  </code></pre>
  
  <p>Any thoughts or alternative designs is much appreciated.</p>