Function question

Trying to teach myself functions. Possible dumb question alert!

If I declare the variables to be used by a function as global, do I still need to explicitly pass them to a function in the call or will they be picked up automatically?

TIA

Bob

Global variables can be accessed within a function without the need to pass them as parameters.

...R

If you declare global variables, you will be able to use them in your function without passing them.

It might be worth passing them anyway though as that will make your function more flexible i.e. you will be able to use it in some other part of your code with different parameters. May not matter in your particular case but it would still be slightly cleaner.

Global variables are a sloppy way to pass function parameters and it is bad practice to create globals if their only use is to get parameters into a function. They make the code more fragile and harder to read.

Thanks All.

To date I’ve been getting in a muddle with functions and ultimately I will have a number of functions all processing the same arrays so I think I will be better off with one global declaration of the array space.

Much appreciated
Bob

I agree with the other posters here. Globals go against the idea of encapsulation, where the programmer limits access to the variable as much as possible. For a more in depth explanation, see Nick Gammon's Useful Links post at the top of this Forum, and look for C++ Programming --> Scope.

Data defined with global scope makes debugging harder because every line of code in the source code file has access to that global data. I like the following analogy: Defining a variable with global scope is like defining a prostitute at the top of the file and then giving every assignment statement in the program a $100 bill. It makes it difficult to determine who is the father of the bug. If you define your data within a function, at least you have a defined starting point for the search.

9fingers:
Thanks All.

To date I've been getting in a muddle with functions and ultimately I will have a number of functions all processing the same arrays so I think I will be better off with one global declaration of the array space.

Much appreciated
Bob

Then consider putting your arrays and functions in a class.

econjack:
I agree with the other posters here. Globals go against the idea of encapsulation, where the programmer limits access to the variable as much as possible. For a more in depth explanation, see Nick Gammon's Useful Links post at the top of this Forum, and look for C++ Programming --> Scope.

Data defined with global scope makes debugging harder because every line of code in the source code file has access to that global data. I like the following analogy: Defining a variable with global scope is like defining a prostitute at the top of the file and then giving every assignment statement in the program a $100 bill. It makes it difficult to determine who is the father of the bug. If you define your data within a function, at least you have a defined starting point for the search.

So give an alternative! What is OP's option? Global namespaces (i.e Java)?

It is easy to make broad statements like this; harder to offer alternatives, I guess.

PS: so, I guess your analogy meant that the prostitute had a baby bug?

I have a lot more sympathy for the aversion to global variables in a PC program. But in the limited memory of an Arduino they don't seem to be much of a sin.

They can also make debugging much easier if you have a showDebugData() function as it can access the global variables without needing any complicated parameter passing.

I also have several programs with functions that need access to the same variables. It seems mad to try to cascade parameters and return values down and up through a series of function calls.

...R

9fingers:
Thanks All.

To date I’ve been getting in a muddle with functions and ultimately I will have a number of functions all processing the same arrays so I think I will be better off with one global declaration of the array space.

Much appreciated
Bob

At some point you might consider teaching you self object oriented programming with classes and objects.

Instead declaring the arrays as globals you could declare them as class data members and then a series of class functions to manipulate those arrays. Since all class functions have access to data members, sort of like global variables, you don’t have to pass them as parameters but the arrays still remain encapsulated.

So in your ino file you might need to declare a single instance of you class as a global variable.

Here is a simple example:

class foo
{
    public:
        foo()
        {
             initArray();
        };
         initArray()
         {
            for (int i = 0; i < MAX; i++)
              m_array[i] = 0;
          };
     protected:
        int m_array[MAX];
};

So in you ino file you would do this

foo f;

void setup()
{
    f.initArray();
}

You will find that encapsulating your data, along with all the functions you need to manipulate it, in a class it is usually a lot less confusing when you have a lot of them.

boylesg:
At some point you might consider teaching you self object oriented programming with classes and objects.

foo f;

So, replace a global array with a global object that contains an array? What a bother.

Of course, I'm meandering off topic.

BulldogLowell:
So, replace a global array with a global object that contains an array? What a bother.

I think the intent is to encapsulate the data (the array or arrays) into an object that also encapsulates the methods (functions) that manipulate the array(s). That would be a natural design if you have a group of functions that share common data.

BulldogLowell:
So, replace a global array with a global object that contains an array? What a bother.

Yes. At least you have to use the dot operator to access the data, which is better than leaving it totally unprotected in the open.

Robin2:
I have a lot more sympathy for the aversion to global variables in a PC program. But in the limited memory of an Arduino they don't seem to be much of a sin.

They can also make debugging much easier if you have a showDebugData() function as it can access the global variables without needing any complicated parameter passing.

I also have several programs with functions that need access to the same variables. It seems mad to try to cascade parameters and return values down and up through a series of function calls.

It's not a question of globals being a sin...some are not easily avoid. However, if I feel that SRAM constraints are getting in the way, I'd consider a different uC. I think the benefits of encapsulation far outweigh any additional cost of a larger uC.

It's hard for me to think about something that makes "complicated parameter passing". My experience is that functions that require complex parameter passing usually are not cohesive and need to be decomposed further. Often I had students who passed a bunch of parameters to a function because they wanted it to be able to do multiple things...they wanted a Swiss Army knife and the complexity it brings with it. If you can't describe what a function does in one or two sentences, it's not cohesive and may benefit from further decomposition.

If multiple functions need to share the same data, that may be a sign of unwanted coupling. In other cases, there's no way around it (e.g., using a file handle). Still, I think private data is better that public even if it means more parameter passing. Bentley, Kernighan, and others have said that 80% of the cost of a program is in the testing and debugging of the code. Data encapsulation really helps control that cost better that global exposure.

BulldogLowell:
So, replace a global array with a global object that contains an array? What a bother.

Of course, I'm meandering off topic.

Usually you have other global variables associated with the array or multiple related global arrays.
If they are all encapsulated in an global object then yes its an improvement.
Its the same sort of thing that many of the arduino libraries do, e.g rtc (real time clock) with its global rtc object.