So, I'm making a Unix minishell, and have come to a roadblock. I need to be able to execute built-in functions, so I made a function:
int exec_if_built_in(char **args)
It takes an array of strings(the first being the command, and the rest being arguments). For non built-in commands I simply use something like execvp, however I need to find a way to map the first string to a function. I was thinking of making two arrays, one of strings, and another with their corresponding function pointers. However, since many of these functions will be different(return and accept different things), this approach won't work. I also thought of making an array of structs with a name property and a function pointer property, however once again due to the varied nature of the functions I'll be using, this won't work.
So, what's the best way to execute a function based on the input of a string? How do I map a string to a certain function? I'm not very familiar with function pointers so I may be missing something.
Thank you guys for the help :)
I was thinking of making two arrays, one of strings, and another with their corresponding function pointers.
That is the right approach. Make wrapper functions that take arguments of identical type* then call the "real" functions from inside your wrappers.
If you would like to "earn additional points for style", sort the array of strings alphabetically, and use binary search on the array of strings. This will let you save a few CPU cycles when the two arrays get bigger.
* Perhaps you could use char **, because that's what your exec_if_built_in takes.
If your cases are so varied that a table-driven approach is inappropriate, then maybe an if/else-if cascade is the best solution.
if(!strcmp(args[0], "cat")) {
/* cat a file */
} else if(!strcmp(args[0], "dog")) {
/* dog a file */
} else if(!strcmp(args[0], "echo")) {
/* create an echo chamber */
} ...
Related
Apart from the obvious difference that the first deals only with arrays, don't they do the same thing? I keep reading the help pages for the two functions, and can't understand when should I use one over the other and why. Internet search seems to indicate only the second is used whatsoever for array copying purposes if not written using loops.
System.Copy is really compiler magic. It's applicable both to strings and to dynamic arrays.
Compiler chooses needed version of intrinsic routine (different for short strings, long strings, dynamic arrays) and substitutes your call of Copy.
For dynamic arrays _DynArrayCopyRange prepares memory, provides reference counting, and calls System.CopyArray for deep copy of elements.
Usually you don't need to call the last procedure expicitly, it is compiler prerogative.
I'm looking to solve a math equation given as string to array of pointers like
char* equations = {"n+1", "n+2", "n*n+3"}
I want the compiler to consider strings inside the above character array as variables e.g "n" is a variable. So, when I assign this string to an 'int' so they will act like a mathematical operation like this:
int a = n+1;
I was thinking the below method could work, but it is definitely not working because we can't assign a pointer's array to int. Even it did, but it's taking just the codes of it like A=65, but this is not my requirement:
a = equations[0]; //(compiler assume it like a = n+1)
The compiler cannot do that for you, you will have to parse the strings into their components (variables, constants, operators) and then apply the appropriate operations yourself.
there are many ways to do this, for example you could parse each expression do some pattern matching and then create and expression from this, which is of course much easier said than done.
But I've found a library that I've not tested yet that do what you want(Or promise to do so), here is the link:
http://partow.net/programming/exprtk/index.html
No, what you want is not possible, because, in a compiled version of a C code, the notion of a "variable name" does not exist.
If you want to achieve this sort of things, you have to do this before you head into the compilation part, i.e, during the pre-processing part.
Otherwise, a more flexible way of achieving what you "probably" want is to make use of function pointers (as "callbacks", if you prefer). You can have different functions defined to do certain jobs and then, at run-time, you can choose any of the already defined functions to be called / invoked and collect the result in the desired variable.
I am asking this question in the context of the C language, though it applies really to any language supporting pointers or pass-by-reference functionality.
I come from a Java background, but have written enough low-level code (C and C++) to have observed this interesting phenomenon. Supposing we have some object X (not using "object" here in the strictest OOP sense of the word) that we want to fill with information by way of some other function, it seems there are two approaches to doing so:
Returning an instance of that object's type and assigning it, e.g. if X has type T, then we would have:
T func(){...}
X = func();
Passing in a pointer / reference to the object and modifying it inside the function, and returning either void or some other value (in C, for instance, a lot of functions return an int corresponding to the success/failure of the operation). An example of this here is:
int func(T* x){...x = 1;...}
func(&X);
My question is: in what situations makes one method better than the other? Are they equivalent approaches to accomplishing the same outcome? What are the restrictions of each?
Thanks!
There is a reason that you should always consider using the second method, rather than the first. If you look at the return values for the entirety of the C standard library, you'll notice that there's almost always an element of error handling involved in them. For example, you have to check the return value of the following functions before you assume they've succeeded:
calloc, malloc and realloc
getchar
fopen
scanf and family
strtok
There are other non-standard functions that follow this pattern:
pthread_create, etc.
socket, connect, etc.
open, read, write, etc.
Generally speaking, a return value conveys a number of items successfully read/written/converted or a flat-out boolean success/fail value, and in practice you'll almost always need such a return value, unless you're going to exit(EXIT_FAILURE); at any errors (in which case I would rather not use your modules, because they give me no opportunity to clean up within my own code).
There are functions that don't use this pattern in the standard C library, because they use no resources (e.g. allocations or files) and so there's no chance of any error. If your function is a basic translation function (e.g. like toupper, tolower and friends which translate single character values), for example, then you don't need a return value for error handling because there are no errors. I think you'll find this scenario quite rare indeed, but if that is your scenario, by all means use the first option!
In summary, you should always highly consider using option 2, reserving the return value for a similar use, for the sake of consistent with the rest of the world, and because you might later decide that you need the return value for communicating errors or number of items processed.
Method (1) passes the object by value, which requires that the object be copied. It's copied when you pass it in and copied again when it's returned. Method (2) passes only a pointer. When you're passing a primitive, (1) is just fine, but when you're passing an object, a struct, or an array, that's just wasted space and time.
In Java and many other languages, objects are always passed by reference. Behind the scenes, only a pointer is copied. This means that even though the syntax looks like (1), it actually works like (2).
I think I got you.
These to approach are very different.
The question you have to ask your self when ever you trying to decide which approach to take is :
Which class would have the responsibility?
In case you passing the reference to the object you are decapul the creation of the object to the caller and creating this functionality to be more serviceability and you would be able to create a util class that all of the functions inside will be stateless, they are getting object manipulate the input and returning it.
The other approach is more likely and API, you are requesting an opperation.
For an example, you are getting array of bytes and you would like to convert it to string, you would probably would chose the first approch.
And if you would like to do some opperation in DB you would chose the second one.
When ever you will have more than 1 function from the first approch that cover the same area you would encapsulate it into a util class, same applay to the second, you will encapsulate it into an API.
In method 2, we call x an output parameter. This is actually a very common design utilized in a lot of places...think some of the various built-in C functions that populate a text buffer, like snprintf.
This has the benefit of being fairly space-efficient, since you won't be copying structs/arrays/data onto the stack and returning brand new instances.
A really, really convenient quality of method 2 is that you can essentially have any number of "return values." You "return" data through the output parameters, but you can also return a success/error indicator from the function.
A good example of method 2 being used effectively is in the built-in C function strtol. This function converts a string to a long (basically, parses a number from a string). One of the parameters is a char **. When calling the function, you declare char * endptr locally, and pass in &endptr.
The function will return either:
the converted value if it was successful,
0 if it failed, or
LONG_MIN or LONG_MAX if it was out of range
as well as set the endptr to point to the first non-digit it found.
This is great for error reporting if your program depends on user input, because you can check for failure in so many ways and report different errors for each.
If endptr isn't null after the call to strtol, then you know precisely that the user entered a non-integer, and you can print straight away the character that the conversion failed on if you'd like.
Like Thom points out, Java makes implementing method 2 simpler by simulating pass-by-reference behavior, which is just pointers behind the scenes without the pointer syntax in the source code.
To answer your question: I think C lends itself well to the second method. Functions like realloc are there to give you more space when you need it. However, there isn't much stopping you from using the first method.
Maybe you're trying to implement some kind of immutable object. The first method will be the choice there. But in general, I opt for the second.
(Assuming we are talking about returning only one value from the function.)
In general, the first method is used when type T is relatively small. It is definitely preferable with scalar types. It can be used with larger types. What is considered "small enough" for these purposes depends on the platform and the expected performance impact. (The latter is caused by the fact that the returned object is copied.)
The second method is used when the object is relatively large, since this method does not perform any copying. And with non-copyable types, like arrays, you have no choice but to use the second method.
Of course, when performance is not an issue, the first method can be easily used to return large objects.
An interesting matter is optimization opportunities available to C compiler. In C++ language compilers are allowed to perform Return Value Optimizations (RVO, NRVO), which effectively turn the first method into the second one "under the hood" in situations when the second method offers better performance. To facilitate such optimizations C++ language relaxes some address-identity requirements imposed on the involved objects. AFAIK, C does not offer such relaxations, thus preventing (or at least impeding) any attempts at RVO/NRVO.
Short answer: take 2 if you don't have a necessary reason to take 1.
Long answer: In the world of C++ and its derived languages, Java, C#, exceptions help a lot. In C world, there is not very much you can do. Following is an sample API I take from CUDA library, which is a library I like and consider well designed:
cudaError_t cudaMalloc (void **devPtr, size_t size);
compare this API with malloc:
void *malloc(size_t size);
in old C interfaces, there are many such examples:
int open(const char *pathname, int flags);
FILE *fopen(const char *path, const char *mode);
I would argue to the end of the world, the interface CUDA is providing is much obvious and lead to proper result.
There are other set of interfaces that the valid return value space actually overlaps with the error code, so the designers of those interfaces scratched their heads and come up with not brilliant at all ideas, say:
ssize_t read(int fd, void *buf, size_t count);
a daily function like reading a file content is restricted by the definition of ssize_t. since the return value has to encode error code too, it has to provide negative number. in a 32bit system, the max of ssize_t is 2G, which is very much limited the number of bytes you can read from your file.
If your error designator is encoded inside of the function return value, I bet 10/10 programmers won't try to check it, though they really know they should; they just don't, or don't remember, because the form is not obvious.
And another reason, is human beings are very lazy and not good at dealing if's. The documentation of these functions will describe that:
if return value is NULL then ... blah.
if return value is 0 then ... blah.
yak.
In the first form, things changes. How do you judge if the value has been returned? No NULL or 0 any more. You have to use SUCCESS, FAILURE1, FAILURE2, or something similar. This interface forces users to code more safer and makes the code much robust.
With these macro, or enum, it's much easier for programmers to learn about the effect of the API and the cause of different exceptions too. With all these advantages, there actually is no extra runtime overhead for it too.
I will try to explain :)
Let say you have to load a giant rocket into semi,
Method 1)
Truck driver places a truck on a parking lot, and goes on to find a hookers, you are stack with putting the load onto forklift or some kind of trailer to bring it to the track.
Method 2)
Truck driver forgets hooker and backs truck up right to the rocket, then you need just to push it in.
That is the difference between those two :). What it boils down to in programming is:
Method 1)
Caller function reserves and address for called function to return its return value to, but how is calling function going to get that value does not matter, will it have to reserve another address or not does not matter, I need something returned, it is your job to get it to me :). So called function goes and reserves the address for its calculations and than stores the value in address then returns value to caller. So caller goes and say oh thank you let me just copy it to the address I reserved earlier.
Method 2)
Caller function says "Hey I will help you, I will give you the address that I have reserved, store what ever calculations you do in it", this way you save not only memory but you save in time.
And I think second is better, and here is why:
So let say that you have struct with 1000 ints inside of it, method 1 would be pointless, it will have to reserve 2*100*32 bits of memory, which is 6400 plus you have to copy it to first location than copy it to second one. So if each copy takes 1 millisecond you will need to way 6.4 seconds to store and copy variables. Where if you have address you only have to store it once.
They are equivalent to me but not in the implementation.
#include <stdio.h>
#include <stdlib.h>
int func(int a,int b){
return a+b;
}
int funn(int *x){
*x=1;
return 777;
}
int main(void){
int sx,*dx;
/* case static' */
sx=func(4,6); /* looks legit */
funn(&sx); /* looks wrong in this case */
/* case dynamic' */
dx=malloc(sizeof(int));
if(dx){
*dx=func(4,6); /* looks wrong in this case */
sx=funn(dx); /* looks legit */
free(dx);
}
return 0;
}
In a static' approach it is more comfortable to me doing your first method. Because I don't want to mess with the dynamic part (with legit pointers).
But in a dynamic' approach I'll use your second method. Because it is made for it.
So they are equivalent but not the same, the second approach is clearly made for pointers and so for the dynamic part.
And so far more clear ->
int main(void){
int sx,*dx;
sx=func(4,6);
dx=malloc(sizeof(int));
if(dx){
sx=funn(dx);
free(dx);
}
return 0;
}
than ->
int main(void){
int sx,*dx;
funn(&sx);
dx=malloc(sizeof(int));
if(dx){
*dx=func(4,6);
free(dx);
}
return 0;
}
Hello Friends,
How can I use an array of function pointers?
If we will see the above link, it tells us how function pointer works.
Now the question is why should I choose function pointer?
Why can't I use function call directly?
What are the benifits will I get with function pointer?
e.g
enum{a, b, c};
void A();
void B();
void C();
void (*fun[3])() = {A, B, C};
Now when I need to call a function I am doing like,
fun[a](); // This calls function A
// And so on...
Same can be done in function calls also
like when I need to call function A, B or C.
directly I can right like
A();
B();
or
C();
Then why function pointer?
There are many reasons to use a function pointer, in particular for doing things generically in C.
The main place you'll see them being used are as an argument to a function. For example with the function bsearch, it uses a comparison function, passed as a function pointer, to compare items and sort the data:
void *bsearch(const void *key, const void *base,
size_t nmemb, size_t size,
int (*compar)(const void *, const void *));
That allows bsearch to be generic and sort any type of data, since only that comparison function has to know the type of the data.
Another one has to do with avoiding multiple checks. ie.
void makePizza(void) { }
void bakeCake(void) { }
iWantPizza = 1;
...
if (iWantPizza)
makePizza();
else
bakeCake();
/* want to call the same function again... */
if (iWantPizza)
makePizza();
else
bakeCake();
..
/* alternative */
void (*makeFood)(void) = iWantPizza ? makePizza : bakeCake;
makeFood();
/* want to call the same function again... */
makeFood();
Now the question is why should I choose function pointer?
What are the benifits will I get with function pointer?
You use function pointers when you need to implement a Asynchronous mechanism.
You need a function be called asynchronously when something happens.
How will you know which function to call?
The address of every function is Unique,So you need to use and store the function address.
Where do you store this function address?
A function pointer
For the example that you showed, one more thing can be done.
Lets say there are bunch of function that needs to run for some device operation.
In simple way, you can write all function calls in another master function and call that
master function.
Another way to do it is, write all function names in a curly bracket and call each by using a function pointer and a loop. That looks smart. I'm not sure how that helps you in better way but I saw this in linux kernel code.
I agree to all the answers here. Apart from this I have some of my own judgements to use function pointer.
Lets take an example of some complex math calculation (like printing Fibonacci, integration, fourier Xform, etc...).
You have a function FX(which does that complicated math calculation or anything else) that you use many a times in your program. This function is used in many different jobs.
After using your program for a few months, you find out that, for some work, you can improve the function and for some, current one is best.
What you will do? Write a new function, go and change the function name at all places.
Everytime you find something better, you are gonna do same.
Instead, use different function pointer for different work. At initial stage, all pointers can point to one function. When you discover a better function for some work, just divert the pointer and you are done.
Take another scenario.
Here, you have a real big code like mobile phone OS. (not fully open but half compiled).
You need to add bluetooth driver to it for a particular hardware.
Now, you can add or you can leave is the option available in OS.
You may need to turn on/off bluetooth from many places.
So what OS does is, it makes a function pointer that turn bluetooth ON and use it wherever it is needed. This code is already compiled so you cannot add your code in it. But what can be done is, you can write function and make that pointer point to your function.
This is what I have already seen under Android OS. (not exactly but nearer)
In my experience, function pointers are mainly used to pass a function as a parameter to another function.
Looking at your code, they could also be used like with arrays, so you can just loop through the entire array (which could consist of hundreds of function pointers) and it will just execute them all.
Function Pointers are pointers(like variable pointers) which point to the address of a function. They actually calling the underlying function when you dereference them like a function call does.
The main advantage of a function pointer is that you can pass it to another function as a parameter for example ...
What is the difference between Function Pointer vs Function Call?
It's like the difference between asking the compiler to "tell me the address of the National Gallery (I might want to go there later and I want to be ready to do it)", rather than "take me to the National Gallery right now (but I won't be paying attention to how you get me there so don't expect me to know later on)". Crucially, if you ask for the address/pointer you can write it down in some place like "next Sunday afternoon's big trip"... you don't even have to remember that it is the National Gallery you'll be going to - it can be a pleasant surprise when you get there - but you immediately know your Sunday's entertainment's all sorted.
What benefits will I get with function pointer?
Well, as above, at the time you set the function pointer you need to make a decision about where you'll call later, but then you can forget about all the reasons for making that decision and just know that later destination's all ready for use. At the time when you're actually doing stuff... "my Sunday routine: sleep in to 10, eat a big breakfast, go back to bed, have a shower, if I've got plenty of money then go on my Sunday afternoon big trip, meet friends for dinner"... the earlier decision just kicks in to get you to the gallery. Crucially, you can keep using your familiar Sunday schedule and start "pointing" the "next Sunday afternoon's big trip" address/pointer at new places as they catch your eye, even if they didn't exist when your general schedule was formed.
You see this post-facto flexibility to change the destination dispatched to at one step in an old routine illustrated well by AusCBloke's mention of bsearch. qsort is another classic example - it knows the big picture logic of efficiently sorting arrays of arbitrary things, but has to be told where to go to compare two of the things you're actually using it for.
These are good examples, particularly the first in Urvish's above. I have wondered the same thing, and I think the answer is purely design. In my mind, they are the same result, as in you can point to a function and get a+b or you can just call a function regularly and get a+b, and with the examples on SO, they are usually small and trivial for illustration. But, if one had a 10k line C program, and you had to change something fifty times because you made a change, you'd probably pick up pretty quickly why you'd want to use function pointers.
It also makes you appreciate the design of OOP languages and the philosophy behind OOD.
I have functions which get file path as their input argument. This functions are cross platform. Functions support both unicode and regular file paths. What is the best interface for this functions, know I have 2 chooses:
make two version of each function FunctionW and FunctionA as in WinAPI.
make one version which will get char * as input argument, but this string must be in UTF8 format.
Which one is better?
Thanks in advance!
This really depends on the rest of your code and how you're going to use them. There is no correct answer here - try to approximate the time it will take you to write, to use and to maintain each one of the options, and try to take the one where it's easier.
You should also consider the difference between FunctionA and FunctionW. If the difference isn't big, then you can likely use a single inner helper function that both of them will call, and so the extra time for writing and maintaining a second function is minimal. If it is, consider how tough it would be (if at all) to convert strings to UTF8 for the 2nd option you presented.