extern

Why does initializing an extern variable inside a function give an error?

◇◆丶佛笑我妖孽 提交于 2019-11-27 20:29:24
This code compiles fine: extern int i = 10; void test() { std::cout << "Hi" << i << std::endl; } While this code gives an error: void test() { extern int i = 10; std::cout << "Hi" << i << std::endl; } error: 'i' has both 'extern' and initializer I read this in C++ Primer : Any declaration that includes an explicit initializer is a definition. We can provide an initializer on a variable defined as extern, but doing so overrides the extern. An extern that has an initializer is a definition. It is an error to provide an initializer on an extern inside a function . Can someone provide an

Is extern “C” only required on the function declaration?

孤街醉人 提交于 2019-11-27 19:19:18
I wrote a C++ function that I need to call from a C program. To make it callable from C, I specified extern "C" on the function declaration . I then compiled the C++ code, but the compiler (Dignus Systems/C++) generated a mangled name for the function. So, it apparently did not honor the extern "C" . To resolve this, I added extern "C" to the function definition . After this, the compiler generated a function name that is callable from C. Technically, the extern "C" only needs to be specified on the function declaration. Is this right? (The C++ FAQ Lite has a good example of this.) Should you

作用域、链接属性、存储类型

人盡茶涼 提交于 2019-11-27 18:42:44
标识符: 首先,在讨论这三种东西之前,详细说明一下C语言中的标识符。 标识符是用户编程为变量、常量、函数、语句等指定的名字,就好比人名一样的东西。 标识符的命名规则如下: 1.只能由字母、数字、下划线组成,并且首字符不能是数字; 2.不能把C语言的关键字作为标识符; 3.对大小写敏感; 其次,需要明确,作用域和链接属性是在标识符范畴内讨论的,存储类型是在标识符中的 变量范畴 内讨论的。 作用域: 标识符的作用域就是程序中该标识符可以被使用的区域,由它的 声明位置决定 。 分为以下四类: 1.文件作用域  2.代码块作用域  3.原型作用域  4.函数作用域 1.文件作用域:   任何在所有代码块之外声明的标识符(变量、常量、函数名、语句等)具有,这表示这个标识符从它声明的位置到这个源文件结尾处都可以访问。   注意:在任何代码块之外声明的 函数名 也具有文件作用域,因为这个函数名本身并不属于任何代码块。 2.代码块作用域:   位于{}之间的所有语句称为代码块,在代码块内声明的标识符,其作用域为从其声明位置开始到这段代码块结束,它可以被这个区间内的语句访问。   注意:处于嵌套状态的代码块,当内层和层声明了相同的标识符时, 外层这个标识符在内层不再起作用 。编程中应该尽量避免出现这种情况。 3.原型作用域:   只适用于在函数原型中声明的参数名,作用域为函数原型中的()内

Is extern keyword really necessary?

筅森魡賤 提交于 2019-11-27 18:23:34
问题 ... #include "test1.h" int main(..) { count << aaa <<endl; } aaa is defined in test1.h ,and I didn't use extern keyword,but still can reference aaa . So I doubt is extern really necessary? 回答1: extern has its uses. But it mainly involves "global variables" which are frowned upon. The main idea behind extern is to declare things with external linkage. As such it's kind of the opposite of static . But external linkage is in many cases the default linkage so you don't need extern in those cases.

Can local and register variables be declared extern?

好久不见. 提交于 2019-11-27 16:23:11
问题 I have been wondering whether an extern can be declared locally and a register variable. If it can be what would be the restrictions imposed? 回答1: Can local variables be declared extern? No. But a global variable can be declared extern locally. // file1.c int Count; // file2.c void foo(void) { extern int Count; Count++; } Can register variables be declared extern? No. A variable may not be extern and register . C11 dr 6.7.1 Storage-class specifiers 1 storage-class-specifier: typedef extern

When to use UIKIT_EXTERN vs just extern

為{幸葍}努か 提交于 2019-11-27 13:54:30
问题 I'm guessing I would only use UIKIT_EXTERN if there is a chance of C++ code in my project that may use the variable. If this is the case wouldn't it just be safe to declare all your externally available constants with UIKIT_EXTERN? How come I don't see this more? 回答1: I'm guessing I would only use UIKIT_EXTERN if there is a chance of C++ code in my project that may use the variable. Right. This is the primary reason. This happens because C and C++ symbols use different naming conventions.

What is the use of Static local variable when we can get a global variable at the same cost?

白昼怎懂夜的黑 提交于 2019-11-27 12:32:04
问题 In C ,what is the use of static storage class when an external variable can serve its purpose at the same cost ie. both occupy storage space in the data segment of the executable. I have much better scope with external variable.If i want the scope of external variable to be specific file i do not declare this variable else where.i see a lot of flexibility with a global variable that static local variable And we can refer to local static variable outside the function if we have the address of

“Unable to find an entry point named [function] in dll” (c++ to c# type conversion)

冷暖自知 提交于 2019-11-27 12:17:25
问题 I have a dll which comes from a third party, which was written in C++. Here is some information that comes from the dll documentation: //start documentation RECO_DATA{ wchar_t Surname[200]; wchar_t Firstname[200]; } Description: Data structure for receiving the function result. All function result will be stored as Unicode (UTF-8). Method: bool recoCHN_P_Name(char *imgPath,RECO_DATA *o_data); Input: char * imgPath the full path of the image location for this function to recognize RECO_DATA *

Okay to declare static global variable in .h file?

流过昼夜 提交于 2019-11-27 10:58:58
问题 static keyword keeps the scope of a global variable limited to that translation unit. If I use static int x in a .h file and include that .h file every other file, won't they all belong to the same translation unit? Then, won't x be visible everywhere? So what is the role of static now? Also, is there any use of static const int x ,where x is a global variable? Aren't all const global variables static by default? And is a const variable's scope limited to the TU even if it confined in a for

“FOUNDATION_EXPORT” vs “extern”

六月ゝ 毕业季﹏ 提交于 2019-11-27 10:17:08
I would like to ask what's the reason behind using FOUNDATION_EXPORT instead of extern in Objective C projects. I've checked this question and using FOUNDATION_EXPORT has earned whopping 340 points (1st place) whereas using extern only 74 points (2nd place). Could anybody explain why? Is there any practical reason for using FOUNDATION_EXPORT instead of extern ? Thanks! If you look in NSObjCRuntime.h (in Foundation) you will see that FOUNDATION_EXPORT compiles to extern in C, extern "C" in C++, and other things in Win32. So, it's a bit more compatible. For most projects, this won't make any