スレッドローカル変数envptr
と、スレッドローカルではない変数もあり、envptr
. 後者の変数は、実行中のコードがスレッド ローカル変数の宣言を認識しない単一のスレッドでのみ使用されます。スレッド ローカル変数はさまざまなスレッドで使用されますが、それぞれのスレッドは非スレッド ローカル変数の宣言を参照したり参照する必要はありません。
このシナリオは可能であり、定義された動作を生成しますか? x86でLinux 32ビットと64ビットを使用しています。
スレッドローカル変数envptr
と、スレッドローカルではない変数もあり、envptr
. 後者の変数は、実行中のコードがスレッド ローカル変数の宣言を認識しない単一のスレッドでのみ使用されます。スレッド ローカル変数はさまざまなスレッドで使用されますが、それぞれのスレッドは非スレッド ローカル変数の宣言を参照したり参照する必要はありません。
このシナリオは可能であり、定義された動作を生成しますか? x86でLinux 32ビットと64ビットを使用しています。
Are they the same variable, or not? In other words, what is their linkage?
If it is external, then no. If it is internal, then it's OK unless the two definitions both occur in the same file.
If there is no linkage, then there is no problem.
Unless I've overlooked something, thread_local
has no impact on linkage, so the usual rules apply (and defining the variable thread_local
in one translation unit, and not in another, is a violation of the one-definition rule).
I think there's a bug in the standard here, however. The standard (§7.1.1/1) says that "If thread_local appears in any declaration of a variable it shall be present in all declarations of that entity." There's no explicit statement that a diagnostic is not required, or that violation of this rule is undefined behavior, so a compiler is required to diagnose the error. Except that, of course, if you define at namespace scope:
thread_local int i;
in one translation unit, and:
int i;
in another, then the compiler probably can't diagnose the error (and I'm fairly sure the committee didn't want to require it). My guess is that the intent here is undefined behavior.
あなたの説明から、それらは2つの異なる変数であるように聞こえます(どちらももう一方をシャドウイングすることはありません)。その場合、技術的な観点からは完全に問題ないようです。
とはいえ、これを行うことを提案することは決してありません。なぜなら、誰かが将来のメンテナンスの意味について混乱し、コードを理解しようとするとさらに問題が発生する可能性が高いからです。
変数は 2 つの異なる変数であるため、これは機能し、正しい動作を生成するはずです。
ソフトウェアの保守性が低下するだけなので、これを行わないことを強くお勧めします。この動作が正しいかどうかは、コードがどれほど理解しやすいかという点でそれほど重要ではないように思われます。動作が大きく異なる 2 つのデータ セットに同じ変数名を使用すると、問題が生じるようです。