问题描述
我的程序中的命名空间之一分布在两个文件之间。一个提供引擎,另一个使用引擎来执行各种命令。所有初始化都在引擎端执行,包括从设置库获取的缓存参数。
One of the namespaces in my program is spread between two files. One provides the "engine", the other uses the "engine" to perform various commands. All of the initializations are performed on the "engine" side, including caching parameters fetched from setup library.
因此, engine.cpp
with:
So, there's engine.cpp
with:
#include <stdio.h>
#include "ns.h"
namespace MyNS
{
unsigned char variable = 0;
void init()
{
variable = 5;
printf("Init: var = %d\n",variable);
}
void handler()
{
// printf("Handler: var = %d\n",variable);
}
}
变量不会在 engine.cpp
,但它广泛用于 commands.cpp
。
The variable happens never to be used again in engine.cpp
but it's extensively used in commands.cpp
.
#include <stdio.h>
#include "ns.h"
namespace MyNS
{
extern unsigned char variable;
void command()
{
printf("Command: var = %d\n",variable);
}
}
编译和链接后, / p>
After compiling and linking, I'm getting:
现在,如果我取消注释 handler()中的printf()
,我会得到:
Now, if I uncomment the printf() in handler()
I'm getting:
什么是正确的方式强制GCC不优化它,以这样的方式访问它通过 extern
从其他文件将获取正确的值?优选地,不减少应用程序其余部分的 -O
级别?
What would be the "correct" way to force GCC not to optimize it away in such a way that accessing it through extern
from the other file would fetch the right value? Preferably without reducing the -O
level for the rest of the application?
(完整性情况下, main.h
和 ns.h
:)
(for completeness case, main.h
and ns.h
: )
#include "ns.h"
int main(int argc, char** argv)
{
MyNS::init();
MyNS::command();
MyNS::handler();
return 0;
}
namespace MyNS
{
void init();
void command();
void handler();
}
此最小化的测试用例不会显示此特定行为;它似乎需要这种情况发生在更复杂的环境发生...
This minimized testcase doesn't exhibit this particular behavior; it seems one needs this situation to occur in much more complex environment to happen...
推荐答案
相当微不足道。
我交换了变量的声明和定义的地方。
I exchanged places of the declaration and definition of the variable.
engine.cpp
:
extern unsigned char variable;
command.cpp
:
unsigned char variable = 0;
在编译命令
和在引擎
中必须达到现有实例时,对该变量存在的需求没有怀疑,它不能只是现场创建一个临时的。
That way the compiler has no doubts about need for this variable's existence while compiling commands
and in engine
it has to reach to the existing instance, it can't just create a temporary one on the spot.
编辑:现在我发现了另一个特性。值根据写入位置而变化。有问题的代码段是:
Now I've discovered another peculiarity. The value changes depending on where it's written to. The section of code in question is:
1: varso = SharedObject::Instance()->varso;
2: memset(det_map,0,sizeof(det_map));
3: memset(gr_map,0xFF,sizeof(gr_map));
4: memset(gr_ped,false,sizeof(gr_ped));
5: memset(&stan,0,sizeof(stan));
6: stan.SOTUstage = 1;
7: PR_SOTU = varso->NrPSOTU;
变量出现在几个数组用memset初始化的地方附近。有问题的变量是 PR_SOTU
(大写是继承自它仍然是一个宏,并且由于它与几个其他宏在一个非常相似的上下文中行动,它很可能
The variable occurs near a place where several arrays are initialized with memset. The variable in question is PR_SOTU
(the uppercase is inherited from when it was still a macro, and since it acts along with several other macros acting in a very similar context, it's likely to stay that way).
如果从第7行移动赋值并将其放在第1,2或3行之后,它会接收到正确的值 5
。放置在第4行之后,它获得值 18
。下面的任何内容,值为 1
。我把变量的定义移动到不同的地方(它是所有命名空间全局列表中的最后一个,现在它是第一个)排除在特定内存位置写入的可能性,但是行为仍然存在。
If move the assignment from its line 7 and place it after lines 1, 2 or 3, it receives the correct value 5
. Placed after line 4 it gets the value 18
. Anything below, and the value is 1
. I moved definition of the variable to a different place (it was the last on the list of all namespace-globals, now it's first) to exclude possibility something writes at that specific memory location, but the behavior remains.
这篇关于强制GCC不优化未使用的变量?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!