<< split from this dead thread - http://cboard.cprogramming.com/showthread.php?t=1115 >>
<< read the rules about thread bumping! >>
So int x has to be global all the time??
<< split from this dead thread - http://cboard.cprogramming.com/showthread.php?t=1115 >>
<< read the rules about thread bumping! >>
So int x has to be global all the time??
Last edited by Salem; 01-03-2008 at 01:15 AM. Reason: Split from a thread dated back from 2001
Erm, well, I suppose you could look at it that way, but it doesn't have to be.
It's just that unless a variable is global, another source file can't access that variable unless you pass it through a function.
Works.Code:// a.cpp int x = 5; // b.cpp extern int x; int main() { x = 7; }
Does not work since x is local in the function (you'll get a linking error here).Code:// a.cpp void foo() { int x = 5; } // b.cpp extern int x; int main() { x = 7; }
Although, in C++, it could also be a static class variable, though I'm not sure if declaring it extern works. You should include the class header instead.
Variables can also be placed inside namespaces, in which it's still global, only inside a namespace.
For completeness, the other use of extern is to declare and use functions and objects from other languages - usually c. The following declares 2 C functions for use in a c++ program:
Extern "C++" is also valid, though redundant.Code:extern "C" void func1(); extern "C" { void func2(); }
It is too clear and so it is hard to see.
A dunce once searched for fire with a lighted lantern.
Had he known what fire was,
He could have cooked his rice much sooner.
Not really.
Extern can be used to export classes, data and function from a DLL. However, it is perfectly valid to use just extern or extern "C++" if the DLL is going to be used from C++; otherwise extern "C" is probably used to avoid name mangling.
If that is in reference to the redundant comment, then yes, really. Plain 'extern' and 'extern "C++"' have exactly the same meaning unless embedded in an extern "C" block.Not really.
Also, extern cannot be used for exporting classes, data or functions from a DLL. Point 1 is that C++ has no concept of DLLs. Point 2 is that it simply doesn't work that way even in the real world.
*nix shared objects export every symbol with external linkage by default. There are linker commands to change that, but that's not the issue here. Since external linkage is the default for global variables and functions, they all get exported.
Windows DLLs export nothing by default IIRC. You can get the linker to export things either by using a .def file, or by using the MS __declspec(dllexport) extension. Either will work. The former is more compatible with other languages, the latter more efficient. You can also combine the two.
Classes don't exist on the binary level, so they're not exported. Their member functions and static member variables can be exported. It's up to the compiler to correctly generate linking information based on the class definitions in the header files.
The extern keyword will get another new meaning in C++09, to do with template specializations.
Oh, and C still does name mangling. Just a considerably simpler method. To avoid mangled names, give the exported symbols other names in the .def file.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
In a higher meaning, it's possible. With some compiler magic, it is definitely possible to export and create classes from a DLL. All it does is export all functions and members variables (AFAIK) and if you include the header, the compiler will generate correct code, since it's not the compiler's job to do the correct jump--that's the linker's job. And it doesn't matter if it's local or in a DLL, since it will be in the virtual memory of the process, and thus, the linker can generate the correct call instruction to call the functions of the class's inside the DLL.
And this is different from what I said, how?
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law