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: David Wilkinson on 24 Dec 2009 08:00
Robby wrote:

> I just don't see how we are not supposed to declare extern's in our header
> file. I know theres a dispute going on here, I didn't read it til the to see
> how it ends up, but how can we say that
>
> extern int x;
>
> is code ?????
>
> I include this in many .c files and I don't get any variable duplication
> errors ???

I think the argument is about whether you should be using global variables at
all. If you are going to use them, IMHO absolutely the right way to do it is

1. declare each variable using extern in some .h file

2. define it just once in a single .c file

3. #include the .h file in every .c file that uses the variable

This way, if you want to change from (say)

long MQ[2];

to (say)

long MQ[10];

you only have to change your code in two places (the extern declaration in the
..h file, and the definition in the .c file).

--
David Wilkinson
Visual C++ MVP
From: sasha on 24 Dec 2009 13:51
David Wilkinson wrote:

> I think the argument is about whether you should be using global variables at
> all. If you are going to use them, IMHO absolutely the right way to do it is
>
> 1. declare each variable using extern in some .h file
>
> 2. define it just once in a single .c file
>

One may go even further and use something like this:

#if !defined VAR_DEFINITION
extern
#endif

long MQ [2];

Have the VAR_DEFINITION defined in one .cpp file among all that include
the .h file.

This way there is only one place to change.
From: Ron Francis on 25 Dec 2009 23:36
"Barry Schwarz" <schwarzb(a)dqel.com> wrote in message
news:sva4j5pobsv6k18n326thanrr2e59us9jf(a)4ax.com...
> On Wed, 23 Dec 2009 23:24:02 +1030, "Ron Francis"
> <ronfrancis(a)adam.com.au> wrote:
>>That is why David said ...
>>"You have
>>extern long MQ[10]; // declaration
>>long MQ[2] = {1,2]; // definition"
>>Because you have included KERNAL.h within KERNAL.c, it becomes one file
>>and so you have made a
>>declaration and definition within the same file.
>>I'm surprised that it compiles but I don't know much about how compilers
>>work.
>
> The issue being raised was not that the declaration and definition
> were in the same translation unit but that they were inconsistent
> within that unit, along with the obvious typographical error.
>

Oh God, that was so obvious and I missed it!
Thanks Barry.

Ron.


From: Ron Francis on 26 Dec 2009 00:20
"Robby" <Robby(a)discussions.microsoft.com> wrote in message
news:281073CD-90FC-4DC2-8EF6-50170EE321D2(a)microsoft.com...
> "Ron Francis" wrote:

<snip>

>> That is why David said ...
>> "You have
>> extern long MQ[10]; // declaration
>> long MQ[2] = {1,2]; // definition"

My mistake here.
You have declared an array of 10 elements and defined an array of 2
elements.

<snip>

> Yes, but if you try to do this:
>
> ==============Kernel.c
> #include <stdio.h>
> #include "API.h"
>
> extern long MQ[2];
> long MQ[2] = {1,2};
>
> int main()
> {
> return 0;
> }
> =================
>
> It should compile without errors! My point is that we should be able to
> declare a variable and then define it down stream of our program... so
> what
> is the difference if we declare it in a header and include that header in
> a
> .c file and define that variable then.
>
> In other words, what is the harm if we do this:
> ===============KERNEL.h
> extern long MQ[2]; // *** DECLARED ***
>
> ===============KERNEL.c
> #include <stdio.h>
> #include "KERNEL.h"
> #include "API.h"
> long MQ[2] = {1,2}; // *** DEFINED ***
>
> int main()
> {return 0; }
> ==================

Yes, that should compile and run without errors, and the only reason that I
can see for not doing it is that the declaration may not be easy to find, as
discussed below.

>> Getting back to hiding the declaration, in my case, I put all my externs
>> in their
>>own header file for readability. Someone looking through a file wouldn't
>>see an
>>extern keyword, but I thought the next best thing would be to see extern.h
>>and
>>hopefully assume that it would contain declarations.
>
> I like this proposition more and more to declare all the externs in a
> seperate header file and define each extern in exactlty one .c file and
> include the extern header file in every other .c file as required. This
> makes
> the best sence since when a user looks at a .c file and sees the inclusion
> of
> the extern.h file, he knows that this .c file uses global variables. But
> now,
> we have Leslie that discourages the use of extern in a header file... if I
> am
> mistaken... or I think this was resolved as allowable to do so. I don't
> know
> anymore... too many ways of doing a simple task.

Leslie would have to answer this, but I suspect that readability has a lot
to do with it.
I imagine that anyone seeing an unknown variable would look first at the top
of the file for its definition or declaration.
If you have many *.h files then the reader has no idea where to look.
Yes, it can be searched for, but then it has to be remembered or at least a
comment added.

By far, the most readable would be
extern long MQ[2];
near the top of the file.

One reason that I have used extern.h files is for easy editing.
What if I wanted to change it to
extern long MQ[3];
If I had 50 extern declarations, I would have to change them all, plus the
definition.
But if it was embedded in an extern.h file then I would only have edit it in
two places.
Keep in mind that any loops etc would have to change too.
You are right that there are lots of ways to do the same thing, and although
confusing, it is also a blessing because it is less limiting.
Probably a more sensible approach is something like:
=====kernal.h
#define MQ_SIZE 2
long MQ[MQ_SIZE] = {1,2};

=====extern.h
extern long MQ[MQ_SIZE];
//extern declarations could also be at the top of each
//and they wouldn't have to be edited

Any loops etc would then be
for(int i=0; i<MQ_SIZE; i++){
//whatever
}
Then only the definition MQ_SIZE would have to be changed.

But as I said earlier, I really don't know if this is good coding practice
or not.

<snip>

> Regards
> Rob

Cheers,
Ron Francis
www.RonaldFrancis.com



First  |  Prev  | 
Pages: 1 2 3 4 5 6 7 8
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