Function Pointers demystified

A TO THE POINT EXPLANATION OF POINTERS TO FUNCTIONS OR FUNCTION POINTERS
-- Nishant Agarwal , nishant@purecode.us
The basic idea is that functions too are nothing but addresses. A function may be
called 100 times, but each time the same function is called, its because view the
function as an service requested from that address.
So, this gives the idea that functions too can be passed as arguments to functions,
and used as rvalues, just as addresses of variables or ADTs can.
A good example of this is the C qsort function.
int qsort (ary, N, sizeofeachelement, comparator)
Here, ary is the address of the starting block of memory which contains your
array or collection, N is the length of the collection, the third argument is the
size of each individual entity in the collection, and the fourth is the address of
the function which compares two entities of the collection.
so now, if your function is:
int comparator( Object a, Object b) , then in order to use this function in the above
qsort call, you would just write the name of the function as the fourth argument. What
you are doing is just passing the address of the function, just like you pass the
address of the first argument or any address.
The fun begins when you want to incorporate polymorphism in this idea. You dont want
to bind this call at compile time. So, declare a function pointer which can hold the
address of such a function, just like you would declare an int* p to hold the address
of an integer.
int (*pf) (int a, int b);
this is the function pointer which points to a function which can return an int
and takes the two arguments specified.
Now, suppose you have a comparator function which wants to sort in ascending order,
and one comparator which wants to sort in descending order.
//ascending
int comparator1 (int a, int b) {
if (a == b) return 0;
return a > b ? a : b;
}
//descending
int comparator2 (int a, int b) {
if (a==b) return 0;
return a > b ? b : a;
}
now, you got an array , a[20] of twenty integers. You want to sort in ascending order,
so you would call qsort, but first assign the correct function to your comparator
pointer function:
pf = comparator1;
qsort (a, 20, sizeof(a[0]), pf);
for descending order:
pf = comparator2;
qsort(a, 20, sizeof(a[0]), pf);
voila!! now you got run-time polymorphism akin to virtual functions in C
( do we really need C++ hmmmm).
A further point to note is that you can generalize the pointer to function definitions
even further by using the void * castings.
void* (*pf) (void* a, void* b);
Can this point to compartor 1 and comparator 2? I leave this to you to find out.
Also, what will this do:
int (*pf)[ ] (int a, int b);

Concurr and Conquer

CONCURR AND CONQUER
There has been a paradigm shift from the way computers are programmed
to do what we wanted to do. There is nothing more entertaining then
the beauty of the electron. Right from the moment you hit the enter on
the keyboard, to when the compiler generates the object files, the
linker links it up with the libraries and other objects, the assembler
churns out the assembly language for the native machine, loader puts
in the binary image of the 0s and the 1s into the memory, the sequence
of bits is interpreted as the micro-codes in the processor registers,
and life flows into the flip flops and the transistors, the drift
velocity of the electrons carrying them to and fro across the
channels, turning the silicon on and off.
This view can no longer be localized into just one processor. We dont
need embarassingly parallel problems to justify parallel architectures
or vice versa.
In my opinion, there has been no better mother of change, then the
need of managing complexity. The order of growth of complexity has
driven the IT revolution. Procedural to functional to Object oriented,
all due to one basic need of managing complexity. Flat to network to
relational to object oriented databases, again same reason. This is
taking an amortized view, mind that. If you go into intricacies of the
baud, it stops at the bits and the electrons, if you take an aggregate
view, it zooms in towards the white light shining far beyond the
matrix of the human race.
Coming back to what I was talking about earlier, there is a difference
in concurrency and parallelism. Concurrency is when two events can
occur in any order without affecting the outcome of the execution.
Parallelism is when these events occur on different processors. These
processors might share a common memory and clock, or they might be
loosely coupled and not share a common bus and a clock. As a
programmer, I would always program concurrently, and know that the
program, if run on a parallel architecture would exploit parallelism
as well, and get me more bang for the buck for my multi-threaded
application.
When do you thread your code?
1. Independent Tasks : When you can have tasks in your system, which
run independent of each other, the order of their execution doesnt
affect the outcome.
2. I/O use: When some tasks are I/O intensive, you dont want them to
hog up the system resources doing nothing, while other tasks could use
that time.
3. CPU use: when some tasks are CPU intensive, you dont want them to
use the CPU always, and starve other tasks.
4. Asynchronous event handling: Some task is expected to receive
service requests or signals asynchronously, I had rather thread that
task then make it busy wait or poll for the event to fire.
5. Resource sharing : As opposite it may sound to the first goal of
independent tasks, threading can enable tasks to share the global
process wide state of text and read only data, while maintaining their
own private execution states in the stacks and register sets.
Communication and Syncrhonization can be facilitated via message
passing, shared memory or other IPC mechanisms. This leads to an
important form of parallel execution: Pipelining. Think of it as a
pipelining in software, pipelining in thought, in the mind.
6. Existing multi-process code: As a rule of the thumb, if you already
have a multi-process code, you would most of the time benefit by
making it multi-threaded. Threads are light weight componenets
compared to processes. It has two major advantages: cost in context
switch is low, and also more work is done in user space then in kernel
space.
7. Concurrency inducive class of problems: As I talked of the
embarassingly parallel problems earlier, there are various problems
which are more easily, naturally and conducively solved via concurrent
thinking and algorithms. For eg: matrix multiplication.

...and now I am tired and very sleepy, will add to this list
soon, if you have suggestions, mail me at nishant@purecode.us