Can someone explain "extern" to me (again)?

<< split from this dead thread - http://cboard.cprogramming.com/showthread.php?t=1115 >>
<< read the rules about thread bumping! >>

Quote:

---

Originally Posted by sh0x

ANSWER #1:
extern is used to reassure the compiler that just because a variable is not resolved in the source file or #included headers, that it will be resolved at link time (after compile time). If I declare:

int x;

in main.c and I reference it in secondary.c, I must put the line:

extern int x;

in secondary.c so the compiler knows that this variable is originally declared in a separate source file. You cannot simply declare "int x" again in secondary.c because this would create a separate variable, not a shared one.

---

So int x has to be global all the time??

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.

Code:

---

// a.cpp
int x = 5;

// b.cpp
extern int x;
int main()
{
        x = 7;
}

---

Works.

Code:

---

// a.cpp
void foo()
{
        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).

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.

Quote:

---

Originally Posted by Elysia

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.

Code:

---

// a.cpp
int x = 5;

// b.cpp
extern int x;
int main()
{
        x = 7;
}

---

Works.

Code:

---

// a.cpp
void foo()
{
        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).

---

Gotya!! THank you!!

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:

Code:

---

extern "C" void func1();
extern "C" {
void func2();
}

---

Extern "C++" is also valid, though redundant.

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.

Quote:

---

Not really.

---

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.

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.

Quote:

---

Originally Posted by CornedBee

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.

---

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?

It was not clear in your original reply that you could export classes. You mentioned it didn't work, and while technically true, it's possible to do it alright.