News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

extern const

Started by sethjackson, January 07, 2006, 12:26:11 AM

Previous topic - Next topic

sethjackson

Why do we need extern const?

IE:


#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 ;)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

sethjackson

Quote from: thomas on January 07, 2006, 01:08:18 AM
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.
Life would be so much easier if we could just look at the source code.

Ceniza

Quote from: sethjacksonThen 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

Quote from: Ceniza on January 10, 2006, 12:09:30 AM
Quote from: sethjacksonThen 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).