全局 static 内联变量，可能跨翻译单元重新定义 class - 这种特殊情况是 C++17 中的未定义行为吗？

Question

First of all: I want to state, that I (suppose to) understand in general the C++17 changes for inline variables and how they work.

For my concrete totally simplified use case, I have some kind of a definitions.inl file, that looks like this:

MY_STRUCT_BEGIN(PotentiallyUB)
MY_STRUCT_END(PotentiallyUB)

And the according macros are defined here inside a header:

#define MY_STRUCT_BEGIN(myStructName) \
static inline constexpr struct myStructName##Type\
{ \
  static inline constexpr unsigned long MyValue1 = __COUNTER__ + 1; \
  static inline constexpr unsigned long MyValue2 = __COUNTER__ + 1; \
  static inline constexpr unsigned long MyTranslationUnitIndependentDiff = MyValue2 - MyValue1;

#define MY_STRUCT_END(myStructName) \
} myStructName {};

I'm totally aware of the fact, that the usage of the built-in COUNTER might be questioned here in general, that's another possible issue I do not want to address here. Here it is required to emphasize my concerns. I also know, that static constexpr variables are implicitly inlined since C++17, just added it to make things clear on first sight.

Now my question: Is this potentially undefined behavior as soon as the.inl file gets (accidentally or desired) processed across multiple translation units? In terms of undefined behavior here, I meant the invariant usage of the difference of MyValue2 - MyValue1 in the definition of MyTranslationUnitIndependentDiff especially.

The standard states

There may be more than one definition of an inline function or variable (since C++17) in the program as long as each definition appears in a different translation unit and (for non-static inline functions and variables (since C++17)) all definitions are identical. For example, an inline function or an inline variable (since C++17) may be defined in a header file that is #include'd in multiple source files.

And

If an inline function or variable (since C++17) with external linkage is defined differently in different translation units, the behavior is undefined.

Especially with focus on the last phrase, I'd currently say, the code shouldn't lead to potential undefined behavior. But I feel like I might have missed something here.

Appendix: What I want to achieve

I actually want instances of these Macro defined structs as constexpr objects available across all translation units, if possible via external linkage. I doubt that the external linkage is really possible in the way the declaration of these objects could be handled in a constexpr context project-wide. If it would be possible, the question about UB should actually not differ since the macro solely affects value initialization and not the definition.

Answer 1

You can put all the code in an anonymous namespace:

namespace
{
    ...
}

Then each translation unit will have its own separate namespace which are guaranteed not to collide.