Re:Ask HN: What is the funniest bug you encountered?
by AstralStorm on Monday November 27, 2017 @04:38PM
(#15791683)
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.
Re:Ask HN: What is the funniest bug you encountered?
by FigBug on Monday November 27, 2017 @04:45PM
(#15791761)
> 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.
Re:Ask HN: What is the funniest bug you encountered?
by AnimalMuppet on Monday November 27, 2017 @05:00PM
(#15791920)
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.
Re:Ask HN: What is the funniest bug you encountered?
by tgb on Monday November 27, 2017 @06:51PM
(#15792905)
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.
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.