extern for global variable: C Question
in [Visual C]
|
Prev: Reference to an undefined assignment operator of a base class in a derived class.
Next: How to convert a Borland C++ App to Visual Studio App
From: Leslie Milburn on 22 Dec 2009 20:06 "Igor Tandetnik" <itandetnik(a)mvps.org> wrote in message news:%23t%23D3l2gKHA.3888(a)TK2MSFTNGP02.phx.gbl... > How do you propose to declare a global variable then, so that it can be > shared between source files? Firstly I never propose to use a global variable :-) Secondly read my previous posts for the answer to how you should declare a global variable and how it is used from other modules. > If you can't have declarations in headers, what _can_ you have in headers? By declarations I meant variables. Looking at my header files I only have the following in my header files #defines, typedefs, function declarations and not much else really. That was the original intention of header files after all. Code should be place into .c modules always. Leslie.
From: Igor Tandetnik on 22 Dec 2009 20:26 Leslie Milburn <CDB4W(a)NOSPAM.bigpond.com> wrote: > "Igor Tandetnik" <itandetnik(a)mvps.org> wrote in message > news:%23t%23D3l2gKHA.3888(a)TK2MSFTNGP02.phx.gbl... >> How do you propose to declare a global variable then, so that it can >> be shared between source files? > > Firstly I never propose to use a global variable :-) > Secondly read my previous posts for the answer to how you should > declare a global variable and how it is used from other modules. Ah. Basically, you say - instead of putting a line of code into a header and then including that header where needed, let's duplicate this line in every source file. Then, if you ever need to change the declaration, you'll have to hunt down all copies. In other words, let's create precisely the problem that include files are supposed to solve. I don't quite see how this is an improvement. >> If you can't have declarations in headers, what _can_ you have in >> headers? > > By declarations I meant variables. Looking at my header files I only > have the following in my header files #defines, typedefs, function > declarations and not much else really. I'm not sure I see the difference between a function declaration and a variable declaration that would make the former acceptable in a header and the latter unacceptable. I understand that one shouldn't place variable definitions into headers, anymore than one would function definitions. But declarations? > That was the original > intention of header files after all. Code should be place into .c > modules always. extern int x; // [1] extern int f(); // [2] typedef int I; // [3] What makes [1] "code" but [2] and [3] "not code"? -- With best wishes, Igor Tandetnik With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
From: Leslie Milburn on 22 Dec 2009 20:47 "Igor Tandetnik" <itandetnik(a)mvps.org> wrote: > Ah. Basically, you say - instead of putting a line of code into a header > and then including that header where needed, let's duplicate this line in > every source file. > Then, if you ever need to change the declaration, you'll have to hunt down > all copies. Yes. It works for me because the variable name itself tells me in which module it was declared so there is no hunting for the decaration as I can go straight to the module where it lives, no problems. > In other words, let's create precisely the problem that include files are > supposed to solve. I don't quite see how this is an improvement. No what I am saying is that I do not want my header files to look like the Windows Platform SDK header file. My header files are clean and readable and have worked well for years. > I'm not sure I see the difference between a function declaration and a > variable declaration that would make the former acceptable in a header and > the latter unacceptable. I understand that one shouldn't place variable > definitions into headers, anymore than one would function definitions. But > declarations? My mistake I meant function definitions. > extern int x; // [1] > extern int f(); // [2] > typedef int I; // [3] > What makes [1] "code" but [2] and [3] "not code"? 3 is a type definition and therefore not code. There is no way to use this in other .c modules without duplication so it goes in a header file. 1 and 2 can be placed in a .c module and therefore should be. Thats the difference. Just to make a guess here , but I bet you place code for member functions of C++ classes into header files with the along with the class definition. Yes ? If so then we will not agree on this subject. Leslie.
From: Igor Tandetnik on 22 Dec 2009 21:17 Leslie Milburn <CDB4W(a)NOSPAM.bigpond.com> wrote: > "Igor Tandetnik" <itandetnik(a)mvps.org> wrote: > >> Ah. Basically, you say - instead of putting a line of code into a >> header and then including that header where needed, let's duplicate >> this line in every source file. >> Then, if you ever need to change the declaration, you'll have to >> hunt down all copies. > > Yes. It works for me because the variable name itself tells me in > which module it was declared so there is no hunting for the > decaration as I can go straight to the module where it lives, no > problems. You mean, the module where it is _defined_, not declared. According to your description, it's declared anew in every source file that refers to it. >> In other words, let's create precisely the problem that include >> files are supposed to solve. I don't quite see how this is an >> improvement. > > No what I am saying is that I do not want my header files to look > like the Windows Platform SDK header file. My header files are clean > and readable and have worked well for years. Well, if you keep your header files empty, they will be even cleaner and more readable. I don't quite see how taking a line from one file and duplicating it in several other files improves overall readability, while it clearly adds to maintenance burden. As to Platform SDK, I can't seem to recall off the top of my head any global variables declared there. If they are unreadable, it's not because of variable declarations. >> I'm not sure I see the difference between a function declaration and >> a variable declaration that would make the former acceptable in a >> header and the latter unacceptable. I understand that one shouldn't >> place variable definitions into headers, anymore than one would >> function definitions. But declarations? > > My mistake I meant function definitions. Wait a minute. Are you saying you have function definitions in your headers? How do you get that to build? >> extern int x; // [1] >> extern int f(); // [2] >> typedef int I; // [3] > >> What makes [1] "code" but [2] and [3] "not code"? > > 3 is a type definition and therefore not code. There is no way to use > this in other .c modules without duplication so it goes in a header > file. 1 and 2 can be placed in a .c module and therefore should be. > Thats the difference. I don't follow. You can place [3] in as many .c source files as you want, just as you can [1] and [2]. Or, you can place all three in a header and include that into several .c files. What again is the difference? > Just to make a guess here , but I bet you place code for member > functions of C++ classes into header files with the along with the > class definition. Yes ? No. Member function definitions go into .cpp files. Declarations, of course, go into header files. I'm beginning to wonder - do you understand the difference between a declaration and a definition? // This is function declaration void f(); // This is function definition void f() { } // This is variable declaration extern int x; // This is variable definition int x; A variable or function (with external linkage) needs to be declared in every translation unit before it is used (possibly by #including the header file containing the declaration), but it must be defined exactly once in the whole program. -- With best wishes, Igor Tandetnik With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925
From: Pavel A. on 22 Dec 2009 22:50
All this just confirms the old Russian proverb - that one user can ask a question that 100 admins won't answer. --pa "Igor Tandetnik" <itandetnik(a)mvps.org> wrote in message news:urOXIY3gKHA.2164(a)TK2MSFTNGP02.phx.gbl... > Leslie Milburn <CDB4W(a)NOSPAM.bigpond.com> wrote: >> "Igor Tandetnik" <itandetnik(a)mvps.org> wrote: >> >>> Ah. Basically, you say - instead of putting a line of code into a >>> header and then including that header where needed, let's duplicate >>> this line in every source file. >>> Then, if you ever need to change the declaration, you'll have to >>> hunt down all copies. >> >> Yes. It works for me because the variable name itself tells me in >> which module it was declared so there is no hunting for the >> decaration as I can go straight to the module where it lives, no >> problems. > > You mean, the module where it is _defined_, not declared. According to > your description, it's declared anew in every source file that refers to > it. > >>> In other words, let's create precisely the problem that include >>> files are supposed to solve. I don't quite see how this is an >>> improvement. >> >> No what I am saying is that I do not want my header files to look >> like the Windows Platform SDK header file. My header files are clean >> and readable and have worked well for years. > > Well, if you keep your header files empty, they will be even cleaner and > more readable. I don't quite see how taking a line from one file and > duplicating it in several other files improves overall readability, while > it clearly adds to maintenance burden. > > As to Platform SDK, I can't seem to recall off the top of my head any > global variables declared there. If they are unreadable, it's not because > of variable declarations. > >>> I'm not sure I see the difference between a function declaration and >>> a variable declaration that would make the former acceptable in a >>> header and the latter unacceptable. I understand that one shouldn't >>> place variable definitions into headers, anymore than one would >>> function definitions. But declarations? >> >> My mistake I meant function definitions. > > Wait a minute. Are you saying you have function definitions in your > headers? How do you get that to build? > >>> extern int x; // [1] >>> extern int f(); // [2] >>> typedef int I; // [3] >> >>> What makes [1] "code" but [2] and [3] "not code"? >> >> 3 is a type definition and therefore not code. There is no way to use >> this in other .c modules without duplication so it goes in a header >> file. 1 and 2 can be placed in a .c module and therefore should be. >> Thats the difference. > > I don't follow. You can place [3] in as many .c source files as you want, > just as you can [1] and [2]. Or, you can place all three in a header and > include that into several .c files. What again is the difference? > >> Just to make a guess here , but I bet you place code for member >> functions of C++ classes into header files with the along with the >> class definition. Yes ? > > No. Member function definitions go into .cpp files. Declarations, of > course, go into header files. > > I'm beginning to wonder - do you understand the difference between a > declaration and a definition? > > // This is function declaration > void f(); > > // This is function definition > void f() { > } > > // This is variable declaration > extern int x; > > // This is variable definition > int x; > > A variable or function (with external linkage) needs to be declared in > every translation unit before it is used (possibly by #including the > header file containing the declaration), but it must be defined exactly > once in the whole program. > -- > With best wishes, > Igor Tandetnik > > With sufficient thrust, pigs fly just fine. However, this is not > necessarily a good idea. It is hard to be sure where they are going to > land, and it could be dangerous sitting under them as they fly > overhead. -- RFC 1925 > |