[tgb]

Love the bug and it's been a while since I've done anything in C++, but isn't your description slightly wrong? There would be one instance per .cpp file that #include'd Foo.h, not one per getInstance() call. I don't think that "inline by default" is an accurate description of what would happen, and I have to imagine that if inline-ing a function caused different behavior, then that would be considered a compiler bug. Rather, I assume you mean it was "inlined" into the file at the #include point (and not once per call). Not that any of that changes the bug qualitatively.

[AnimalMuppet]

No, inlining replaces it at the place of call. Every call, even if there's multiple of them in the same file. The idea is that, by putting the implementation in the .h file, you're signaling that you don't want to pay the overhead of the function call. (Same thing with the "inline" keyword.)

Now, if your function is sufficiently complicated, the compiler may choose to not inline it anyway (with the definition of "sufficient" being compiler-dependent).

It could be considered a compiler bug that a function with a static variable in the body could be inlined. As you say, that changes the behavior of the function. Or perhaps it could be considered a specification error - I don't know if the standard prohibits inlining in this circumstance, but perhaps it should.

[AstralStorm]

Now, C++ explicitly allows shouting yourself in the foot for performance reasons and for interesting features. You might actually want to have such code to programmatically create such static fields.

In a template tracking usage of the class is a common case. Another fine one would be to count separate instantiations. (How many times the function was used not inlined vs inlined.) Etc.

[FigBug]

> A static local variable in an extern inline function always refers to the same object. > 7.1.2/4 - C++98/C++14 (n3797)

(functions are by default extern, so, unless you specifically mark your function as static, this applies to that function)

What the OP did should be fine and not cause an issues. The only way it could cause issues if they also made the function static.

[AnimalMuppet]

Clarification: Are member functions by default extern?

If so, then it's a compiler bug, and I figured it out because the compiler did what I naively expected, rather than what the standard said.

[tgb]

Now I'm googling this and it looks like what you wrote would be a compiler error (assuming Foo.h was included into at least two files) unless the keyword inline was used so that the same function could be defined multiple times. That clears up my confusion with your "default inline" statement.