extern const

[sethjackson]

Why do we need extern const?

IE:

Code

#ifndef APPGLOBALS_H
#define APPGLOBALS_H

#include <wx/string.h>

extern const wxString APP_VENDOR;
extern const wxString APP_NAME;
extern const wxString APP_VERSION;
extern const wxString APP_ACTUAL_VERSION_VERB;
extern const wxString APP_ACTUAL_VERSION;
extern const wxString APP_URL;
extern const wxString APP_CONTACT_EMAIL;
extern const wxString APP_PLATFORM;
extern const wxString APP_WXANSI_UNICODE;
extern const wxString APP_BUILD_TIMESTAMP;

#endif // APPGLOBALS_H

Then in appglobals.cpp set the wxString's to something? Why is this needed? Why can't you set the strings to something in the header? Sorry if this is the most stupid question ever, but I'm not understanding. 

I read this on MSDN...

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/basic_17.asp

[thomas]

Because it does not work otherwise, we tried

[sethjackson]

Because it does not work otherwise, we tried

Oh wonder why? Do you know?

[yop]

AFAIK you can't initialize non integral data (or POD) in a header. This applies to staitc const members of a class but I don't think that there would be a different initialization mechanism for const (non static) non-POD variables. The difference is only that if they are class members they have to be declared static to avoid multiple copies between instances of the same class, if they are not members then the const identifier is enough but the same restrictions apply. I don't have Meyer's book around but there is a topic about initialization of such variables (where he talks about not using #define and generaly preprocessor macros) that answers this topic specificaly.

[Ceniza]

Then in appglobals.cpp set the wxString's to something? Why is this needed?

Declarations in header files and definitions in source files?

Those macros are just to protect against re-declaring them for the same Translation Unit, but if more than one Translation Unit includes the same header file and instead of declarations it finds definitions you'll get problems linking.

[grv575]

Then in appglobals.cpp set the wxString's to something? Why is this needed?

Declarations in header files and definitions in source files?

Those macros are just to protect against re-declaring them for the same Translation Unit, but if more than one Translation Unit includes the same header file and instead of declarations it finds definitions you'll get problems linking.

but the header has just declarations... you can later define them in a specific source file.  tried a simple gcc project and it didn't look like extern was needed (non-local/function vars are global i.e. extern scope by default)

[Ceniza]

If you remove the "extern" but keep the "const", all those wxString will be initialized with an empty string and remain "const". Including that header (without "extern") in more than one TU (Translation Unit) and compiling it won't give you problems. If those weren't const neither extern linking would complain, 'cause it would find "multiple definitions" for every wxString there. The only thing that makes it "work" is that "const" makes it have internal linkage, so it'd mean multiple definitions with the same name but without clashing, if every definition occurs in only one TU.

With "extern", it gives the compiler enough info about their type to compile a TU, knowing their definition will be somewhere else (it's now the linker's job to 'link' the definition when linking).