Quoting a code snippet :
/**
* list_add - add a new entry
* #new: new entry to be added
* #head: list head to add it after
*
* Insert a new entry after the specified head.
* This is good for implementing stacks.
*/
static inline void list_add(struct list_head *new, struct list_head *head)
{
__list_add(new, head, head->next);
}
I have seen similar code in several different programs, especially those manipulating data structures. What is the usual intention in adding this extra level of indirection - why can't the code inside __list_add be put inside list_add ?
If you copy code, it will make maintenance harder. In this example, the extra level of indirection hides the parameter next. It will provide a function with just 2 parameters rather than 3.
If the code inside the __list_add() is copied, it needs to be copied to multiple places. If then the list mechanism is changed somewhat, all of these places need to be updated too, or bugs will start to pop-up (i.e. a FIFO and LIFO implementation of a list show different behavior).
There is always a tradeoff; another level of indirection also adds complexity and possibly overhead, as opposed to duplicating lines of code or having lots of parameters in the API.
It's about code reuse, and avoiding duplication.
__list_add() contains code that is useful in more situations than just this one, and can be shared between several different functions.
Sharing code like this has several advantages:
If there's a bug in __list_add() and you fix it, all the functions that use it get the fix.
If __list_add() gets an enhancement (eg. you make it faster) all the functions get faster.
There's only one place to look when you want to see how items are added to lists.
It can.
However, there are probably other public entries that can share the code in __list_add(). eg, there may be a push() or an insert_head() or something like that.
NOTE: If this is C++ then you might want to rethink calling your variables new, as this is a reserved word.
__list_add will be intended as a "private" internal function which might have multiple uses internally. The public facing list_add is there as a convenient wrapper around it.
This wrapper is inline. If you added the body of __List_add, that too would be inlined. The apaprent goal is to just inline the pushing of the extra head->next argument and nothing else.
That function comes from the linux kernel.
It belongs to the generic list implementation:
Take a look: __list_add()
__list_add() is used in many places: e.g. list_add() which adds an element at a list head, list_add_tail() which adds an element at list tail... It can also be used to insert an element at a given position.
It is also common to define an wrapper function for recursive functions so the initial parameters are set correctly.
See binary search on wikipedia for Recursion (computer science)
Could also be to keep binary compatibility. you have an indirection that allows to keep the ABI invariant.
From http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
When a new version of a library is
binary-incompatible with the old one
the soname needs to change. In C,
there are four basic reasons that a
library would cease to be binary
compatible:
The behavior of a function changes so that it no longer meets its
original specification,
Exported data items change (exception: adding optional items to
the ends of structures is okay, as
long as those structures are only
allocated within the library).
An exported function is removed.
The interface of an exported function changes.
Related
The function gtk_tree_store_clear() does what the documentation says it does: the store is cleared and all lines inside the associated tree view disappear.
Does this function also free the memory that the store used? For example, if the store had 1,000 lines of gchar *, is all that memory freed?
Yes, otherwise everyone using GtkTreeStore (or GtkListStore for that matter) that would be dealing with a major memory leak. :-)
That's also the reason why you have to pass a list of GTypes to the constructors of those classes: GTK uses them to lookup on how to free them. If you want to know the implementation details: both classes internally use an internal class called GtkTreeDataList which implements this.
The fact that it also knows about thise GTypes is also the reason why you don't need to explicitly strdup() your strings when passing them one for example: that's also something the subclass will lookup from the respective column types.
I have come across the function pointers. I know understand how this works. But i am not pretty sure, in what situation it will use. After some google and other search in Stack Overflow. I came know to know that it will use in two case
when callback mechanism is used
Store a array of functions, to call dynamically.
In this case also, why don't we call function directly. In the call back Mechanism also, as particular events occur, callback pointer is assigned to that function(Address). Then that is called. Can't we call function directly rather than using the function pointer. Can some some one tell me, what is the exact usage of Function pointer and in what situation.
Take a look at functions needing a callback, like
bsearch or qsort for the comparator, signal for the handler, or others.
Also, how would you want to program other openly-extensible mechanisms, like C++-like virtual-dispatch (vptr-table with function-pointers and other stuff)?
In short, function-pointers are used for making a function generic by making parts of the behavior user-defined.
One of the situation when function pointers would be useful is when you are trying to implement callback functions.
For example, in a server that I've been implementing in C and libevent accepts a message from clients and determine what to do. Instead of defining hundreds of switch-case blocks, I store function pointer of function to be called in a hash table so the message can be directly mapped to the respective function.
Event handling in libevent API(read about event_new()) also demonstrates the usefulness of having function points in APIs such that users can define their own behaviour given a certain situation and need not to modify the master function's code, which creates flexibility while maintaining certain level of abstraction. This design is also widely used in the Kernel API.
You said:
In the call back Mechanism also, as particular events occur, callback pointer is assigned to that function(Address).
Callback functions are registered at a very different place than where the callback functions are called.
A simple example:
In a GUI, the place where you register a function when a button is pressed is your toplevel application setup. The place where the function gets called is the implementation of the button. They need to remain separate to allow for the user of the button to have the freedom of what they wish to do when a button is pressed.
In general, you need a function pointer when the pointer needs to be stored to be used at a future time.
In the case of a callback situation, including interrupt driven code, a sequence of call backs or interrupts may occur for a single logical process. Say you have a set of functions like step1(), step2(), ... , to perform some process where a common callback is being used to step through a sequence. The initial call sets the callback to step1(), when step1() is called, it changes the pointer to function to step2() and initiates the next step. When that step completes, step2() is called, and it can set a pointer to function to step3(), and so on, depending on how many steps it takes to perform the sequence. I've mostly used this method for interrupt driven code.
Sometimes I use function pointers just to make (as I see it) the code more legible, and easier to change. But this is a matter of taste, there is no one 'correct' way. It's possible that the function pointer code will be slower, but probably only slightly and of course as far as performance goes it's always a matter of measuring, and usually more a matter of choosing better algorithms than of micro-optimisation.
One example is when you have two functions, with identical and long argument lists and sometimes you want to call one and sometimes the other. You could write
if ( condition)
{ one( /* long argument list */);
}
else
{ other( /* long argument list */);
}
or you could write
(condition ? one : other)(/* long argument list */);
I prefer the second as there is only one instance of the long argument list, and so it's easier to get right, and to change.
Another case is implementing state machines; one could write
switch( state)
{ case STATE0: state = state0_fun( input); break;
// etc
}
or
typedef int (*state_f)( void*);
state_f statefs[] = { state0_fun /* etc */}
state = statefs[ state](input);
Again I find the second form more maintainable, but maybe that's just me.
In implementing a single linked list in C, I think there are three ways :
HEADER IS A POINTER ITSELF.IT POINTS TO THE FIRST NODE OF THE LINKED LIST.
1.Declare the header globally and use function void insert(int) to insert.This should work as header is global.
2.Declare header inside main and use function node*insert(node*) to insert.This should work because of the return involved.
3.Declare header inside main and use function void insert(node**) to insert.
Sometimes the second way works even without the return involved. Why?
Which is the better way?
If the functions involved are recursive as in tree which method is appropriate?
You should encapsulate your data structure in a single object (the head node or a struct that contains it), and then you can have your functions work on that object. This means that you can have more than one linked list in your program (that won't work with a global head node) and you can also pass it around to different functions that want to use it (there's no point having a data structure without being able to use it).
If you have your single object (head node) stored in your program then the insert and delete functions don't need to return anything, as you already have a pointer to the object that represents the linked list.
If the functions involved are recursive as in tree which method is appropriate?
The functions should not be recursive "as in tree". The depth of a tree is O(logn), which means recursion is reasonable in many situations; The size of a linked list is O(n), which means recursion can easily overflow the stack.
I have a need for an efficient sort that doesn't have a callback, but is as customizable as using qsort(). What I want is for it to work like an iterator, where it continuously calls into the sort API in a loop until it is done, doing the comparison in the loop rather than off in a callback function. This way the custom comparison is local to the calling function (and therefore has access to local variables, is potentially more efficient, etc). I have implemented this for an inefficient selection sort, but need it to be efficient, so prefer a quick sort derivative.
Has anyone done anything like this? I tried to do it for quick sort, but trying to turn the algorithm inside out hurt my brain too much.
Below is how it might look in use.
// the array of data we are sorting
MyData array[5000], *firstP, *secondP;
// (assume data is filled in)
Sorter sorter;
// initialize sorter
int result = sortInit (&sorter, array, 5000,
(void **)&firstP, (void **)&secondP, sizeof(MyData));
// loop until complete
while (sortIteration (&sorter, result) == 0) {
// here's where we do the custom comparison...here we
// just sort by member "value" but we could do anything
result = firstP->value - secondP->value;
}
Turning the sort function inside out as you propose isn't likely to make it faster. You're trading indirection on the comparison function for indirection on the item pointers.
It appears you want your comparison function to have access to state information. The quick-n-dirty way to create global variables or a global structure, assuming you don't have more than one thread going at once. The qsort function won't return until all the data is sorted, so in a single threaded environment this should be safe.
The only other thing I would suggest is to locate a source to qsort and modify it to take an extra parameter, a pointer to your state structure. You can then pass this pointer into your comparison function.
Take an existing implementation of qsort and update it to reference the Sorter object for its local variables. Instead of calling a compare function passed in, it would update its state and return to the caller.
Because of recursion in qsort, you'll need to keep some sort of a state stack in your Sorter object. You could accomplish that with an array or a linked-list using dynamic allocation (less efficient). Since most qsort implementations use tail recursion for the larger half and make a recursive call to qsort for the smaller half of the pivot point, you can sort at least 2n elements if your array can hold n states.
A simple solution is to use a inlineble sort function and a inlineble compare callback. When compiled with optimisation, both call get flatten into each other exactly like you want. The only downside is that your choice of sort algorithm is limited because if you recurse or alloc more memory you potentially lose any benefit from doing this. Method with small overhead, like this, work best with small data set.
You can use generic sort function with compare method, size, offset and stride.This way custom comparison can be done by parameter rather then callback. With this way you can use any algorithm. Just use some macro to fill in the most common case because you will have a lot of function argument.
Also, check out the STB library (https://github.com/nothings/stb).
It has sorting function similar to this among many other useful C tools.
What you're asking for has already been done -- it's called std::sort, and it's already in the C++ standard library. Better support for this (among many other things) is part of why well-written C++ is generally faster than C.
You could write a preprocessor macro to output a sort routine, and have the macro take a comparison expression as an argument.
#define GENERATE_SORT(name, type, comparison_expression) \
void name(type* begin, type* end) \
{ /* ... when needed, fill a and b and use comparison_expression */ }
GENERATE_SORT(sort_ints, (*a<*b))
void foo()
{
int array[10];
sort_ints(array, array+10);
}
Two points. I).
_asm
II). basic design limits of compilers.
Compilers have, as a basic purpose, the design goal of avoiding assembler or machine code. They achieve this by imposing certain limits. In this case, we give up a flexibility that we can easily do in assembly code. i.e. split the generated code of the sort into two pieces at the call to the compare function. copy the first half to somewhere. next copy the generated code of the compare function to there, just after the previous copied code of the first part. then copy the last half of the sort code. Finally, we have to deal with a whole series of minor details. See also the concept of "hot patching" running programs.
Important: Please see this very much related question: Return multiple values in C++.
I'm after how to do the same thing in ANSI C? Would you use a struct or pass the addresses of the params in the function? I'm after extremely efficient (fast) code (time and space), even at the cost of readability.
EDIT: Thanks for all the answers. Ok, I think I owe some explanation: I'm writing this book about a certain subset of algorithms for a particular domain. I have set myself the quite arbitrary goal of making the most efficient (time and space) implementations for all my algos to put up on the web, at the cost of readability and other stuff. That is in part the nature of my (general) question.
Answer: I hope I get this straight, from (possibly) fastest to more common-sensical (all of this a priori, i.e. without testing):
Store outvalues in global object (I would assume something like outvals[2]?), or
Pass outvalues as params in the function (foo(int in, int *out1, int *out2)), or
return a struct with both outvals, or
(3) only if the values are semantically related.
Does this make sense? If so, I think Jason's response is the closest, even though they all provide some piece of the "puzzle". Robert's is fine, but at this time semantics is not what I'm after (although his advice is duly noted).
Both ways are valid, certianly, but I would would consider the semantics (struct vs parameter reference) to decide which way best communicates you intentions to the programmer.
If the values you are returning are tightly coupled, then it is okay to return them as a structure. But, if you are simply creating artificial mechanism to return values together (as a struct), then you should use a parameter reference (i.e. pass the address of the variables) to return the values back to the calling function.
As Neil says, you need to judge it for yourself.
To avoid the cost of passing anything, use a global. Next best is a single structure passed by pointer/reference. After that are individual pointer/reference params.
However, if you have to pack data into the structure and then read it back out after the call, you may be better off passing individual parameters.
If you're not sure, just write a bit of quick test code using both approaches, execute each a few hundred thousand times, and time them to see which is best.
You have described the two possible solutions and your perceived performance constraint. Where you go from here is really up to you - we don't have enough information to make an informed judgement.
Easiest to read should be passed addresses in the function, and it should be fast also, pops and pushes are cheap:
void somefunction (int inval1, int inval2, int *outval1, int *outval2) {
int x = inval1;
int y = inval2;
// do some processing
*outval1 = x;
*outval2 = y;
return;
}
The fastest Q&D way that I can think of is to pass the values on a global object, this way you skip the stack operation just keep in mind that it won't be thread safe.
I think that when you return a struct pointer, you probably need to manually find some memory for that. Addresses in parameter list are allocated on the stack, which is way faster.
Keep in mind that sometimes is faster to pass parameters by value and update on return (or make local copies on the stack) than by reference... This is very evident with small structures or few parameters and lots of accesses.
This depends massively on your architecture, and also if you expect (or can have) the function inlined. I'd first write the code in the simplest way, and then worry about speed if that shows up as an expensive part of your code.
I would pass the address to a struct. If the information to be returned isn't complex, then just passing in the addresses to the values would work too.
Personally, it really comes down to how messy the interface would be.
void SomeFunction( ReturnStruct* myReturnVals )
{
// Fill in the values
}
// Do some stuff
ReturnStruct returnVals;
SomeFunction( &returnVals);
// Do more stuff
In either case, you're passing references, so performance should be similar. If there is a chance that the function never actually returns a value, you could avoid the cost of the malloc with the "return a struct" option since you'd simply return null.
My personal preference is to return a dynamically allocated (malloc'd) struct. I avoid using function arguments for output because I think it makes code more confusing and less maintainable in the long-term.
Returning a local copy of the structure is bad because if the struct was declared as non-static inside the function, it becomes null and void once you exit the function.
And to all the folks suggesting references, well the OP did say "C," and C doesn't have them (references).
And sweet feathery Jesus, can I wake up tomorrow and not have to see anything about the King of Flop on TV?