Good function pointer analogies?

Question

The best one I have come up with so far is that a card catalog contains instructions on finding how to cook different types of food. It does not contain the information on how to cook the food, nor the instructions on cooking the food itself, but it can point you to relevant instructions which are located elsewhere. It is a good analogy because it demonstrates the flexibility on being able to cook different types of food (Mexican, Vegetarian, Indian, etc.) but the notion of a card catalog is quickly being replaced with computerized searches. I have been asked the dreaded "What is a card catalog?" Using Google as an example of finding cooking instructions is OK but there is not that clear distinction of going to a physical location, finding the instructions, and "executing them". Any one have any analogies that worked for them?

Answer 1

That analogy seems overly complex.

A function pointer is just like a phone number of someone who can get the job done for you.

Answer 2

I would say a function pointer is like "The address of the implementation" to a specific "declared specification" (unless your handling voids). Explain that the compiler examines the pointer type to check you are using the specification with the right implementation, and that the implementation is just a block of instructions expecting a certain calling convention.

not an analogy but probably simpler.

Answer 3

.NET calls them delegates, maybe this is helpful for analogies.

You could just say a function pointer is the address of someone (a worker, a company) that you'll delegate your job to.

Answer 4

Extending the card idea: imagine you play a game, where you have to do what is written at card you are given. All cards are written before the game and you know the full list but don't know the card you'll pick.

Answer 5

I don't think it's a good idea to try and teach a very technical concept through non-technical analogies - presumably the people you are teaching do NOT need a vague "management summary" kind understanding, they will eventually need to apply the concept concretely, so why such a detour?

Why not explain it with a simple programming example? Perhaps the best one would be a generic sorting algorithm (presumably the students have already learned about sorting).

"A function pointer is basically a way to pass a piece of code around to be called by other code who does not need to know about it beforehand. For example, a sorting algorithm like quicksort or mergesort really only needs to know one thing about the things it's sorting: how to compare them. But if you build the comparison into the sorting algorithm, it will only be able to compare one thing, like ints. By passing the comparison logic as a function pointer to the sorting algorithm, to be called whenever the algorithm needs to compare elements, the algorithm can now be used to sort anything at all without having to change its code - if you want to use it to compare apples and oranges, you only need to write a fruit-comaprison function and pass a pointer to it to the sorting algorithm, along with your fruit to be sorted."

Answer 6

I always think of function pointers as providing the mechanism to pass functions as arguments (among other uses). So if you ask "how can I pass this function to another function" the answer would be use a reference (pointer) to it. Don't know if this helps or not.

Answer 7

A function pointer is like a credit card. :)

To do a payment you don't need to carry money to do the transaction yourself, you just swipe the card and it does the transaction for you.

The transaction can be done by different banks an in different ways, but a credit card still looks the same way and works the same way. You don't have to know all the details behind it, you just have to know how to use the card.

Answer 8

I suggest to tell your pupils what something is for not what it is. Later, they will ask themselves "what is the right tool to solve this problem?" instead of "what is my problem called?"

Imagine you write a program that takes a bitmap and turns that into an image file. There are various kinds of formats for bitmaps (black and white, true color, true color with alpha channel, etc). And there are various image file formats (JPEG, PNG, GIF). If you tried to write that without function pointers, you would end up with N*M algorithms: N for the number of input bitmaps and M for the number of supported output formats. In this basic example, that would be 9 (3*3). Tomorrow, your boss comes around and wants support for TIFF, too. That would mean 12 (3*4) algorithms. A tiny change in the specs causes a lot of work. Dead end.

But you can define three function pointers: getWidth(bitmap), getHeight(bitmap), getPixel(bitmap, x, y)

Now you only need N algorithms which implement these three FPs. Each algorithm works with each kind of bitmap and knows how to read it. The output algorithms don't care anymore what the input image looks like, they just take the three FPs to access the now abstract image data. So you end up with 6 (3+3) algorithms and when your boss comes with TIFF, you only need to add a single algorithm: 7 instead of 12.

From the point of view of the computer, a FP is a trampoline. Instead of starting to execute the code at the address of the FP (normal function call), it reads the address stored there and starts to execute the code at which the address saves in the FP points to.

The funny code you need to write is only to make the compiler happy. In assembler, this looks pretty simple. Normal function call:

    lea.l someFunction,a0  # Load address of someFunction
    jsr.l a0               # Jump to subroutine

Function pointer:

    lea.l  functionPointer,a0  # Load address of functionPointer
    move.l (a0),a0             # Load what is stored at functionPointer into a0
    jsr.l  a0                  # Jump to subroutine

As you can see, just a single instruction difference.

Answer 9

I think that a "pointer" can be called an "identifier" (which is reasonable because a instance's 'memory address' is its 'identity'). So a "pointer to a function" is just "a variable which stores the identity of some function" (assuming you know what a 'function' is).

Answer 10

The card catalog thing seems a little strange anyway. Going with your theme, a better analogy for function pointers IMO would be that they're an entry in the index of a cookbook. "Cajun......39", so you go to page 39, and there are the instructions for cooking Cajun.

Answer 11

This clip describes CDS(Credit Default Swaps). It is exactly how pointers effect your system.

http://www.youtube.com/watch?v=KPNdYtrlgaU#t=120s

"Here we know we have an instrument of a particular finical instrument that is demonstrably dangerous, it creates long chains of risk which are vulnerable to the failure of individual trader or market partipants in that chain and these instruments in an affect permit the creation of vicious spirals. In which the CDS price interact with the bound price, the market price and you can have a downward spiral."

What my ears are telling me: "Don't create dependences that will create long chains of crashing systems."

So if they know what CDS are. Then it will be easy. :)