Go Down

Topic: Legitimate uses for pointers? (Read 14157 times) previous topic - next topic

GoForSmoke



No, structs are returnable without pointers.
So, one less reason to use pointers.


Sure. passing a whole struct or array on the stack is -so- much more efficient than passing an address to the struct or array, huh?

1) http://gammon.com.au/blink  <-- tasking Arduino 1-2-3
2) http://gammon.com.au/serial <-- techniques howto
3) http://gammon.com.au/interrupts
Your sketch can sense ongoing process events in time.
Your sketch can make events to control it over time.

Arrch

#31
Aug 15, 2013, 05:53 pm Last Edit: Aug 15, 2013, 06:00 pm by Arrch Reason: 1

Sorry if this comes across as inflammatory... I'm really trying to learn here. I'm a bit dense but I want to "get it".


Compare this:
Code: [Select]
void (*fToRun[]) () = {f1, f2, f3 };

void setup()
{
Serial.begin(115200);
Serial.println("begin");
}

void loop()
{
 if (Serial.available() > 0)
 {
   int i= Serial.parseInt();
   fToRun[i]();
 }
}

void f1() {}
void f2() {}
void f3() {}


to this:

Code: [Select]
void setup()
{
Serial.begin(115200);
Serial.println("begin");
}

void loop()
{
 if (Serial.available() > 0)
 {
   int i= Serial.parseInt();
   if (i ==1)
   {
     f1();
   }
   else if (i == 2)
   {
     f2();
   }
   else if (i == 3)
   {
     f3();
   }
 }
}

void f1() {}
void f2() {}
void f3() {}


And imagine you had 50 functions instead of just 3.

strtok() is another good example.

PeterH


Or use references...


This.

Pointers are very useful and powerful when needed, but I suggest you should only use them when/if necessary. On that basis the examples being discussed are not 'legitimate' (as you put it) use of pointers since pointers are not needed to solve this problem.

tylernt


It's when a use fits in an app you're working on that you will come to appreciate them

That's exactly what happened to me last night -- I was so happy I finally joined the ranks of "real C programmers" because I found a use for pointers.

That's why I as so disappointed to realize I could have done the same thing by return value assignment. I was instantly downgraded to n00b again. :-/

I think I'm going to have a hard time finding a use for pointers though, because I'm a hammer and everything looks like a nail. I approach programming problems based on the tools I have, and since pointers aren't one of those tools, I'm not sure the light bulb will ever go on. I'd really love to see an example where pointers make a particular task better than the alternatives so I can add pointers to my tool bag.

Quote
Sure. passing a whole struct or array on the stack is -so- much more efficient than passing an address to the struct or array, huh?

So, RAM consumption, rather than ease of programming, is the purpose of pointers?

Quote

Compare this:
to this:

Hmm. Your array takes more RAM than a switch/case, but I suppose switch/case would be slower to execute (especially for the later cases) than doing what is essentially a lookup table.

So again, it seems like pointers are more for hardware efficiency (RAM or CPU) than for ease or readability of programming?

Quote
Or use references...
Quote
This.
Oh jeez I'm just starting to understand pointers and you give me another topic to research. :)

AWOL

Quote
So, RAM consumption, rather than ease of programming, is the purpose of pointers?

Not just consumption, but the overhead of copying the data too.
For large data sets, that's a lot of memory bandwidth chewed up.

Arrch

#35
Aug 15, 2013, 06:29 pm Last Edit: Aug 15, 2013, 06:35 pm by Arrch Reason: 1

So again, it seems like pointers are more for hardware efficiency (RAM or CPU) than for ease or readability of programming?


You're telling me it's easier to read and program 50 case statements than a single line of function pointers?

Pointers don't have a specific purpose. In the example AWOL used, pointers are used to save RAM and instruction time at the slight cost of code readability. In my example, it's used to save instruction time and cut down the amount of code at the cost of RAM. In other examples, they're used to make scalability easier. You can't look at pointers and give them a general use.

tylernt

Quote
You're telling me it's easier to read and program 50 case statements than a single line of function pointers?
Either you write 50 case statements (with the code inline, not calling 50 different functions) or you write 50 functions. Either way it's a lot of typing and a lot of scrolling, they seem to be about equal from a finger-cramp standpoint.

Now, if some or all of those 50 functions could be used for other additional things, outside of and aside from parsing your serial data, then I agree it makes more sense to have them as functions and function pointers instead of inlining them in the switch/case block. You can take advantage of code re-use that way.

Ok... I think I'm finally starting to "get" pointers... and I agree there are legitimate uses for recursion too... just that they tend to be the exception rather than the rule. Useful tools, but maybe ones that collect a little dust between uses. :)

KeithRB

Now lets talk about *function* pointers. 8^)

I used them in a programmable image processing program. I stored the operations in a stack and for operators used function pointers. You would pop the function and it would execute and pop the data from the stack (polish notation, but not reverse polish notation). I could have pushed an index and used a monster switch/case, but I felt that the function pointer was much more readable and easy to maintain.

Arrch

Either you write 50 case statements (with the code inline, not calling 50 different functions) or you write 50 functions. Either way it's a lot of typing and a lot of scrolling, they seem to be about equal from a finger-cramp standpoint.

Now, if some or all of those 50 functions could be used for other additional things, outside of and aside from parsing your serial data, then I agree it makes more sense to have them as functions and function pointers instead of inlining them in the switch/case block. You can take advantage of code re-use that way.

Perhaps those 50 functions represent various states in a state machine, and sending the serial command isn't the only way to call them? Maybe the functions are included from somewhere else, and aren't something you wrote yourself?

That's the detriment of simple examples: assumptions have to be made about the reasons for other, less relevant portions of the code. Since you're more interested in picking apart the examples than looking at the main points, I won't bother with anymore of them.

PeterH


Pointers don't have a specific purpose.


The closest I'd get to a 'specific purpose' for them is to enable code to reference something without using a symbol to identify it. The main reason for doing that IMO is that the code does not have a symbolic dependency on the thing (variable, function, object) referenced, so it might be used to refer to multiple things, or it might be used to refer to a thing without knowing which thing it is. I admit that's not very specific.

tylernt

Quote

Now, if some or all of those 50 functions could be used for other additional things, outside of and aside from parsing your serial data, then I agree it makes more sense to have them as functions and function pointers instead of inlining them in the switch/case block. You can take advantage of code re-use that way.

Perhaps those 50 functions represent various states in a state machine, and sending the serial command isn't the only way to call them? Maybe the functions are included from somewhere else, and aren't something you wrote yourself?
I agree with you. If those functions have more than one use, then using an array of function pointers makes perfect sense. Absolutely legitimate use. :)

Arrch



Pointers don't have a specific purpose.


The closest I'd get to a 'specific purpose' for them is to enable code to reference something without using a symbol to identify it. The main reason for doing that IMO is that the code does not have a symbolic dependency on the thing (variable, function, object) referenced, so it might be used to refer to multiple things, or it might be used to refer to a thing without knowing which thing it is. I admit that's not very specific.


Specific was a bad term to use. I should have said general.

You can't look at pointers and say:
They're used to reduce RAM
They're used to make code easier to read
They're used to make code more reusable.


Because it depends on the situation.

KeithRB

Another good use, is in the recent "switching arrays" thread. He could use one array or another by using a pointer to the array and avoid copying the whole array. The other solution, a multi-dimensional array was good to, and essentially the same thing under the hood.

Kand R:
"Pointers have been lumped with the goto statement as a marvelous way to create impossible-to-understand programs. This is certainly true when they are used carelessly, and it is easy to create pointers that point somewhere unexpected. With discipline, however, pointers can also be used to achieve clarity and simplicity. This is the aspect we will try to illustrate."

tylernt


Another good use, is in the recent "switching arrays" thread.
I just read that. I like the multidimensional array best, but if those arrays were wildy different sizes then you'd be wasting tons of space and the pointer seems like a better idea.

Hot dang I think I learned something today! Thanks for being patient with me everyone! :D

AWOL

There are situations where pointers produce a more natural implementation : lookups where the index may be negative or Iliffe vectors for non-rectangular arrays

Go Up