title: Alternative id generators for types
body: <p>In <a href="https://github.com/skypjack/entt" rel="nofollow noreferrer">a project of mine</a>, I have an <a href="https://github.com/skypjack/entt/blob/master/src/entt/core/family.hpp" rel="nofollow noreferrer">ID generator</a> for types that looks similar to this:</p>
  
  <pre><code>class Family {
      static std::size_t identifier;
  
      template&lt;typename...&gt;
      static std::size_t family() {
          static const std::size_t value = identifier++;
          return value;
      }
  
  public:
      template&lt;typename... Type&gt;
      inline static std::size_t type() {
          return family&lt;std::decay_t&lt;Type&gt;...&gt;();
      }
  };
  
  std::size_t Family::identifier{};
  </code></pre>
  
  <p>Usage:</p>
  
  <pre><code>const auto id = Family::type&lt;FooBar&gt;();
  </code></pre>
  
  <p>It works just fine for my purposes, but it has some limitations. The most annoying one (purpose of the question) is that it fails when used by an executable that links to shared libraries if all of them try to create identifiers. The result is usually that the n-th identifier is assigned to different types across boundaries because each shared library maintains their own separate <code>Family::identifier</code>.</p>
  
  <p>Some <em>shared library guys</em> pointed out that a more reliable solution would be appreciated, but failed to suggest one that didn't ruin the performance (almost all of them introduce containers, find functionalities and memory allocation).</p>
  
  <p>Is there any alternative approach that works around the aforementioned limitations without losing the performance of the current design?</p>
  
  <p>I searched through SO and found some interesting answers. Many of which were several years old. I'd like to explore solutions up to the latest revision of the standard instead, as long as the interface of the existing class remains intact.<br>
  <a href="https://stackoverflow.com/a/7692147/476681">This one</a> is the most interesting one. It uses addresses of static members to achieve the same, but it doesn't fit with the idea of sequentially generated identifiers</p>
  
  <p><strong>Note</strong>: using RTTI isn't an option unfortunately.</p>
  
  <p><strong>Note</strong> : ids must be generated sequentially and starting from 0 as in the solution presented above.</p>