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 19 Dec 2009 03:58

"Robby" wrote:

Hi Robby,

I am not a fan of global variables at all. To use them is a last resort as
it implies a code design problem. In all my 25+ years of C programming I
have hard ever had to resort to using a global variable. I suggest you look
at the code once more and decide if the variable could be passed as a
parameter as needed.

>
> Objective:
> The data in the MQ array has to be accessible and available in many
> functions of several .c files, and therefore should appear to have global
> scope.

I disagree, pass the variable as a parameter to the functions that require
access to the variable. Yes *all* of them.


> Resolution:
> As shown in code above, I declared an array as "extern" and then defined
> it
> in one .c file and where ever other .c files require access to MQ[], I
> have
> to include the KERNEL.h file. Is this an okay practice to do with all
> other
> global variables, arrays and arrays of structures?
>

I have seen some programmers follow this approach. IMO over time the code
may become harder to read and you need to consider if any programmers other
than yourself will be maintaining the code. I always assume (even for my
private projects) that I will not be the only programmer reading the code.

My preferred approach is to declare the variable at the top of the .c module
in which it is first created and usually (but not always) populated. Then
for each .c module that requires access to the variable I place "extern
variable name" at the top of that module with a comment indicating why I am
using it. To make the code more readable I use the naming convention of
modulename_variablename to help identify where the declaration is located.
So in your case it would be api_MQ.

Of concern is that your choice of module name and variable names are not
really that meaningful. api.c and kernel.c are not useful names if you think
about it. Which API is api.c referring to. Also MQ also has little meaning.
Before you get to far down the road you might like to revisit your naming
conventions. My main software project comprises of approximately 400 .c
modules and it is easy to forget the finer details when you revisit code 12
to 18 months later. So trust me when I say you will be thankful you used
meaningful names.

hth
leslie.



From: Leslie Milburn on 19 Dec 2009 04:03

"Barry Schwarz" wrote
>
> While this is obviously the right (tm) way to define a global variable
> exactly once and declare it extern everywhere it is needed, it begs
> the question of whether global variables are the right choice. Since
> they have a tendency to confound debugging, there is a school of
> thought that strongly recommends passing the array as an argument to
> those functions that need it.

Exactly.


From: Tim Roberts on 20 Dec 2009 21:03
"Leslie Milburn" <CDB4W(a)NOSPAM.bigpond.com> wrote:
>
>I am not a fan of global variables at all. To use them is a last resort as
>it implies a code design problem. In all my 25+ years of C programming I
>have hard ever had to resort to using a global variable. I suggest you look
>at the code once more and decide if the variable could be passed as a
>parameter as needed.

Although I agree that his current implementation has an almost unlimited
number of problems, the big issue he's facing is that he's writing for an
embedded processor. On many embedded processors, such as the PIC series
that he's targeting, the stack is your enemy. It can be very expensive to
use parameters and stack local variables, so you end up using globals more
than you ordinarily would.
--
Tim Roberts, timr(a)probo.com
Providenza & Boekelheide, Inc.
From: Barry Schwarz on 21 Dec 2009 00:03
On Sun, 20 Dec 2009 18:03:53 -0800, Tim Roberts <timr(a)probo.com>
wrote:

>"Leslie Milburn" <CDB4W(a)NOSPAM.bigpond.com> wrote:
>>
>>I am not a fan of global variables at all. To use them is a last resort as
>>it implies a code design problem. In all my 25+ years of C programming I
>>have hard ever had to resort to using a global variable. I suggest you look
>>at the code once more and decide if the variable could be passed as a
>>parameter as needed.
>
>Although I agree that his current implementation has an almost unlimited
>number of problems, the big issue he's facing is that he's writing for an
>embedded processor. On many embedded processors, such as the PIC series
>that he's targeting, the stack is your enemy. It can be very expensive to
>use parameters and stack local variables, so you end up using globals more
>than you ordinarily would.

Then he would be better off making it static in main and still passing
it as an argument.

But if stack space is the problem, why is he using long instead of
short or int.

--
Remove del for email
From: Leslie Milburn on 21 Dec 2009 03:09

"Tim Roberts" <timr(a)probo.com> wrote:

> Although I agree that his current implementation has an almost unlimited
> number of problems, the big issue he's facing is that he's writing for an
> embedded processor. On many embedded processors, such as the PIC series
> that he's targeting, the stack is your enemy. It can be very expensive to
> use parameters and stack local variables, so you end up using globals more
> than you ordinarily would.

Then the static keyword is your friend as it is allocated the once and it
can then be passed as a parameter as required. IMO this is much cleaner !!
Leslie.


First  |  Prev  |  Next  |  Last
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