How can i get a function's name without calling/invoking it, or is that even possible ?
I have an array of sorting functions, my goal is to be able to list the name of each one, dynamically, without having to invoke any.
After searching on the web, i couldn't find any solution that doesn't require the function being invoked and uses __FUNCTION__ or __func__.
The array of functions that is use:
// Pointer to functions
char *(*srtFunc[])(int *, int) = {selection, bubble, recursiveBubble, insertion, recursiveInsertion};
More information about what I want to achieve with this:
I want to loop over each function in the given array, create a file with the name of the function, invoke the function 100 times with different arguments each time, and print the time spent by the function each time in its dedicated file, redo for the remaining functions.
Unfortunately, not easily. C is not built for introspection and doesn't have features like this-- the name of function foo and the call to function foo are compiled down to just some jump and call instructions in the output; the actual name "foo" is essentially a convenience for you when programming and disappears in the compiled output.
The macro __FUNCTION__ is a preprocessor macro-- and as you note it only works within a function, because all it does it tell the preprocessor (as its churning through the text) hey, as you're scanning this token just drop in the name of the function you're currently scanning and then continue on. It's very "dumb" and is upstream of even the compiler.
There are various ways to get the effective result you want here, including most simply just manually building a table of string literals that have the same names as your functions. You can do this in fairly clean ways (see #nielsen's answer for a useful snippet) using macros. But the preprocessor/compiler can't help you derive or enforce a table from the actual functions so you will always have some risk of an issue at runtime when you make changes to it. Unfortunately C just doesn't have the capability for the kind of elegance you're looking for in this design.
You may be able to do something with smart preprocessor tricks, but your code would be difficult to read. I think I would go for the really low-tech solution here and just add an array of the function names matching the array of function pointers:
#define ARRAY_SIZE(A) (sizeof(A)/sizeof(A[0]))
// Pointer to functions
char *(*srtFunc[])(int *, int) = {selection, bubble, recursiveBubble, insertion, recursiveInsertion};
const char *srtFuncNames[] = {"selection", "bubble", "recursiveBubble", "insertion", "recursiveInsertion"};
_Static_assert(ARRAY_SIZE(srtFuncNames)==ARRAY_SIZE(srtFunc), "Function table and names out of synch!");
Having the two definitions just after each other makes it easy to keep them synchronized and the code is easy to read. The _Static_assert (available from C11) will help remembering to add new names as new functions are added.
Alternatively, a structure can be defined holding a function pointer and corresponding name. This can be initialized using a macro as follows:
typedef struct
{
char *(*srtFunc)(int *, int);
const char *srtName;
} sortMethod;
#define SORT_METHOD(S) {(S), #S}
sortMethod methods[] = {
SORT_METHOD(selection),
SORT_METHOD(bubble),
SORT_METHOD(recursiveBubble),
SORT_METHOD(insertion),
SORT_METHOD(recursiveInsertion)
};
Related
I'm trying to create something like a library. I found out that, using #define macros, you can pretty much do anything you want with your code, and I tried to chain some of them in some crazy way to make some cool stuff happen.
For that reason, I'm trying to create a tool that uses a function-like macro, in which you pass a type name (like int or float), and it creates some typedef struct things and related functions, in order to make a new data type List(type).
The idea is, you only need to specify the type of the list and the name of the new list, as you would declare any variable, and it already knows which functions you have to work with it:
/* this function is not present in the code, but */
/* I call it in the .h file to make sure that it's */
/* possible to have an existent List(float) type. I */
/* added this, because I want to work i the future on */
/* the possibility to have a user-defined type for which */
/* you can build a List(custom_type) variable */
declare_new_type(float);
List(float) list;
main() {
/*do stuff with the list, */
/* using some functions defined in the library */
/* along with the List(float) type */
return 0;
}
When I wrote the library, I put in a macro (that is not to be called by the programmer who uses the library itself, but it's called by me in order to declare for which types the type List(type) exists) that defines the data type and a bunch of functions that work with variables of the same type.
All of that is done with a lot of other #ifndef and #define macros, all of which pass to one another the same parameter typename, that is the one I pass myself when I call declare_new_type(type) (to put it in other words, the parameter value is literally type).
In this way, all the other expanded macros know the actual content in the typename parameter, and they are able to create a lot of function with variable types in return and names that depend from that same parameter using the ## macro expansion tool. For example, the begin(...) function that one of these macros defines is defined as following:
/* when I call begin(float) in the main code, */
/* it just makes a call to this function, and not to */
/* this code snippet for the definition */
#define begin(typename) typename##List fBegin##typename() { \
\
typename##List e=(typename##List)malloc(sizeof(typename##Item)); \
e->v=0; \
e->next=NULL; \
return e; \
}
For this one, I have no problems, because I have to pass another time the typename parameter when I call the function (to avoid type mismatch in the declaration of the data type, and the data that it works on), and for that reason it calls exactly the fBeginfloat() function that is defined when I call the declare_new_type(type) function.
In other cases, however, I wanted the function to have only the List(type) variable as parameter (and some other needed parameters to work with it), but not the actual type that it works on, and there the real problem comes out.
For some reason (probably, me not knowing much about C compiling and high-level programming), I'm not able to extract the type of a variable and pass it to any other function. It seems that even operators like sizeof(variable) or typeof(variable) are not able to pass what I want them to pass as parameters, when they get called as function parameters them selves.
I tried using # macro operators, blocks of code, anything to make it happen, and I just don't seem able to do it.
Now, I wonder if it's really possible to make something like this happen: is it possible to pass a variable to a #define macro, or even to another defined function, and have it to get the variable type, in order to pass it as parameter to another macro or function? I hope you understood the problem, and will help me in some way. Thanks!
An important insight into the C preprocessor (which handles macros) is that it knows absolutely nothing about the semantics of the program. Nothing. For the preprocessor, the input is just a sequence of tokens, and all it does is rearrange those tokens according to some rules.
So, it doesn't know what a type is, or what a variable is, or what the type of a variable might be, and certainly not what the value of a variable might be.
(It can do arithmetic in the context of an #if directive. But it is still only working with tokens, not with C variables or expressions or whatever. An identifier in an #if will be expanded (not evaluated) if it has previously been #defined; otherwise it is replaced with 0 for the conditional evaluation. And there is no way of saving the result of an arithmetic expression; #if is only a conditional.)
So, to address the question in the last paragraph of your post:
typeof() is a very recent addition to C, although it is implemented as an extension in several C compilers. The result of typeof is a type, which is an internal compiler data object. You cannot convert a type to a string, and it is not a value which exists at runtime, so it makes no sense to try to pass it as an argument to a function. In C, types occupy the very short time after the preprocessor and before code generation.
However, you can use typeof to define other types, and you can name those types using typedef. (Remember that typedef is just a type alias, not a new type. Two typedefd names which alias the same type are the same type, unlike two anonymous struct declarations with the same members.)
I am trying to use a function-like macro to generate an object-like macro name (generically, a symbol). The following will not work because __func__ (C99 6.4.2.2-1) puts quotes around the function name.
#define MAKE_AN_IDENTIFIER(x) __func__##__##x
The desired result of calling MAKE_AN_IDENTIFIER(NULL_POINTER_PASSED) would be MyFunctionName__NULL_POINTER_PASSED. There may be other reasons this would not work (such as __func__ being taken literally and not interpreted, but I could fix that) but my question is what will provide a predefined macro like __func__ except without the quotes? I believe this is not possible within the C99 standard so valid answers could be references to other preprocessors.
Presently I have simply created my own object-like macro and redefined it manually before each function to be the function name. Obviously this is a poor and probably unacceptable practice. I am aware that I could take an existing cpp program or library and modify it to provide this functionality. I am hoping there is either a commonly used cpp replacement which provides this or a preprocessor library (prefer Python) which is designed for extensibility so as to allow me to 'configure' it to create the macro I need.
I wrote the above to try to provide a concise and well defined question but it is certainly the Y referred to by #Ruud. The X is...
I am trying to manage unique values for reporting errors in an embedded system. The values will be passed as a parameter to a(some) particular function(s). I have already written a Python program using pycparser to parse my code and identify all symbols being passed to the function(s) of interest. It generates a .h file of #defines maintaining the values of previously existing entries, commenting out removed entries (to avoid reusing the value and also allow for reintroduction with the same value), assigning new unique numbers for new identifiers, reporting malformed identifiers, and also reporting multiple use of any given identifier. This means that I can simply write:
void MyFunc(int * p)
{
if (p == NULL)
{
myErrorFunc(MYFUNC_NULL_POINTER_PASSED);
return;
}
// do something actually interesting here
}
and the Python program will create the #define MYFUNC_NULL_POINTER_PASSED 7 (or whatever next available number) for me with all the listed considerations. I have also written a set of macros that further simplify the above to:
#define FUNC MYFUNC
void MyFunc(int * p)
{
RETURN_ASSERT_NOT_NULL(p);
// do something actually interesting here
}
assuming I provide the #define FUNC. I want to use the function name since that will be constant throughout many changes (as opposed to LINE) and will be much easier for someone to transfer the value from the old generated #define to the new generated #define when the function itself is renamed. Honestly, I think the only reason I am trying to 'solve' this 'issue' is because I have to work in C rather than C++. At work we are writing fairly object oriented C and so there is a lot of NULL pointer checking and IsInitialized checking. I have two line functions that turn into 30 because of all these basic checks (these macros reduce those lines by a factor of five). While I do enjoy the challenge of crazy macro development, I much prefer to avoid them. That said, I dislike repeating myself and hiding the functional code in a pile of error checking even more than I dislike crazy macros.
If you prefer to take a stab at this issue, have at.
__FUNCTION__ used to compile to a string literal (I think in gcc 2.96), but it hasn't for many years. Now instead we have __func__, which compiles to a string array, and __FUNCTION__ is a deprecated alias for it. (The change was a bit painful.)
But in neither case was it possible to use this predefined macro to generate a valid C identifier (i.e. "remove the quotes").
But could you instead use the line number rather than function name as part of your identifier?
If so, the following would work. As an example, compiling the following 5-line source file:
#define CONCAT_TOKENS4(a,b,c,d) a##b##c##d
#define EXPAND_THEN_CONCAT4(a,b,c,d) CONCAT_TOKENS4(a,b,c,d)
#define MAKE_AN_IDENTIFIER(x) EXPAND_THEN_CONCAT4(line_,__LINE__,__,x)
static int MAKE_AN_IDENTIFIER(NULL_POINTER_PASSED);
will generate the warning:
foo.c:5: warning: 'line_5__NULL_POINTER_PASSED' defined but not used
As pointed out by others, there is no macro that returns the (unquoted) function name (mainly because the C preprocessor has insufficient syntactic knowledge to recognize functions). You would have to explicitly define such a macro yourself, as you already did yourself:
#define FUNC MYFUNC
To avoid having to do this manually, you could write your own preprocessor to add the macro definition automatically. A similar question is this: How to automatically insert pragmas in your program
If your source code has a consistent coding style (particularly indentation), then a simple line-based filter (sed, awk, perl) might do. In its most naive form: every function starts with a line that does not start with a hash or whitespace, and ends with a closing parenthesis or a comma. With awk:
{
print $0;
}
/^[^# \t].*[,\)][ \t]*$/ {
sub(/\(.*$/, "");
sub(/^.*[ \t]/, "");
print "#define FUNC " toupper($0);
}
For a more robust solution, you need a compiler framework like ROSE.
Gnu-C has a __FUNCTION__ macro, but sadly even that cannot be used in the way you are asking.
My C header file contains about 300 various functions, their names all beginning with "foo_db_" and accepting a "db_t" as their first parameter (knowing what is exactly a db_t is no really relevant here, it's just a struct).
function foo_db_my_first_function(db_t *db, char *param1, int param2);
function foo_db_my_second_function(db_t *db, double param1, const char *param2, int param3);
(...)
function foo_db_my_Nth_function(db_t *db, int param1);
My job is to write another 300 wrapping functions named "foo_XXXX" (XXXX begin the suffix of the "foo_db_" function) with a default value for the first parameter.
static __inline function foo_my_first_function(char *param1, int param2) {
foo_db_my_first_function(DEFAULT_DB, param1, param2);
}
(...)
I was wondering if I could write some macros to ease my job: declare the "db" function and the corresponding "default" function (without the first parameter).
Unfortunately, I cannot use C99 and variadic macros arguments :( so I think I'm screwed :), but I prefer to ask first here before burning my fingers to write those 300 functions :/
Assuming the original header file for the API is regular enough, then a script in your favorite text processing language (Perl, Lua, Python, Awk, or even /bin/sh in a pinch) will likely be the simplest approach.
Your script would collect all public function declarations using a regex or simple text matching to identify them (likely based on the foo_db_ prefix). It could then write two output files. First, a suitable .h file declaring your wrappers, and second the .c source file implementing them by stuffing DEFAULT_DB into their first parameter. You will need to do a minimal amount of work to copy the rest of the parameters through, but with luck the declarations are all regular enough that the text manipulation can be as simple as "rest of line" or the like.
Having done that, I would check the script into revision control, and get it invoked at build time, treating the generated files as transient build products. However, if you don't have a sufficiently flexible build system (this is why I still perfer make to nearly everything else I've seen proposed) then you will have to find a suitable kludge to signal that your generated default wrappers are out of date when the API changes.
This approach will require investing some time in the code generator script, but you should be ahead on that well before the time you imagine hand-coding your 100th wrapper. And the second time you run it....
In extreme cases, you could end up needing to implement much of the front-end of a C compiler. In that case, I see two approaches that are both more socially acceptable than arranging a meeting with the architect in a dark alley. First, there is a GCC back-end that emits its AST in XML; the resulting XML is a bear, but has been reduced down to a tree of tokens that can be manipulated. Second, there is always LPeg, a full parser that is easily used from Lua (and I suspect that there are other PEG parsers out there for other scripting languages too). Sample code for LPeg that lexes and parses C is referenced at the Wiki page.
Do it in Excel. Create a cell with "foo_db_ (db_t *db)", drag it down as many places as you need, fill in all the blanks, then copy it all into your program (you can test that the copy will work ahead of time, but I just tried with Notepad and it seems to work as intended). Now you have all your function headers, and can fill in the rest from there.
In a C program I'm making, I will receive as command lines arguments a file path and a letter. The file is where I read data from, and the letter represents the type of data that is held inside that file.
The instructions I need to perform on the data are basically the same, only the type is different: it might be that the file holds ints, doubles or the values of a struct X. Regardless of type, the operations will be identical; how can I avoid repeating code? In C++ I would handle this with templates. How would this be typically handled in C?
In C you would do it through what you're hoping to avoid -- repeating the code. C++ makes this more convenient with templates, as you're aware, however that's just a simple way to repeat the code and base it on a different type.
Something that might be appropriate for you is to provide the different class functions but to not call them directly. Instead, based on your command line, determine once which function(s) will process your data, and assign them to function pointers. Then, your control loop will just generically call the processing function(s) using those pointer(s). This will obviously include whatever you do with the data, but you might also decide to have separate input functions based on data type.
Edit: As Mat says, there are come types which promote well and so one block of code would work fine. I suspect this is why your assignment includes working with some structure type.
The solution to this problem is obvious with modern objected oriented languages -- you make an object of each type that implements an interface (or via inheritance) of the actions you want to perform.
You can't do this in C because the language does not naively support object oriented, but you can "reproduce" the same functionality instead of letting the compiler do it for you. To do so you need to use a level of indirection specifically you will need to use function pointers.
So (as an example) one of the actions you might take is to read values from the file. One of your variables will be a function pointer to a function that takes as a parameter the file and a variable of type void (this will change for each function you write.) Write the function for each of your types and then at run type assign the function to use based on the type of the file.
In the realms of really ugly pre-processor tricks, if you want to replicate the body of a function for different types, but keep the code "structure" identical, you can do something like this:
foo.hc
#define YNAME(X) foo_ ## X
#define XNAME(X) YNAME(X)
#define NAME XNAME(TYPE)
int NAME(FILE* f) {
TYPE myvar;
...
return whatever;
}
foo.c
#define TYPE int
#include "foo.hc"
#undef TYPE
#define TYPE double
#include "foo.hc"
#undef TYPE
This foo.c will pre-process to:
int foo_int(FILE* f) {
int myvar;
...
return whatever;
}
int foo_double(FILE* f) {
double myvar;
...
return whatever;
}
All you need to do in your main processing loop with that is to dispatch to the right function depending on your file type. A plain switch statement can work pretty well, an array of function pointers could work too.
The new C standard, C11, has type generic expressions that you could use for this. There is not yet much compiler support for C11 but for example the latest version of clang has _Generic. You can also use P99 to emulate C11 features on top of similar extensions that are provided by gcc.
I'm following a guide to learn curses, and all of the C code within prototypes functions before main(), then defines them afterward. In my C++ learnings, I had heard about function prototyping but never done it, and as far as I know it doesn't make too much of a difference on how the code is compiled. Is it a programmer's personal choice more than anything else? If so, why was it included in C at all?
Function prototyping originally wasn't included in C. When you called a function, the compiler just took your word for it that it would exist and took the type of arguments you provided. If you got the argument order, number, or type wrong, too bad – your code would fail, possibly in mysterious ways, at runtime.
Later versions of C added function prototyping in order to address these problems. Your arguments are implicitly converted to the declared types under some circumstances or flagged as incompatible with the prototype, and the compiler could flag as an error the wrong order and number of types. This had the side effect of enabling varargs functions and the special argument handling they require.
Note that, in C (and unlike in C++), a function declared foo_t func() is not the same as a function declared as foo_t func(void). The latter is prototyped to have no arguments. The former declares a function without a prototype.
In C prototyping is needed so that your program knows that you have a function called x() when you have not gotten to defining it, that way y() knows that there is and exists a x(). C does top down compilation, so it needs to be defined before hand is the short answer.
x();
y();
main(){
}
y(){
x();
}
x(){
...
more code ...
maybe even y();
}
I was under the impression that it was so customers could have access to the .h file for libraries and see what functions were available to them, without having to see the implementation (which would be in another file).
Useful to see what the function returns/what parameters.
Function prototyping is a remnant from the olden days of compiler writing. It used to be considered horribly inefficient for a compiler to have to make multiple passes over a source file to compile it.
In C, in certain contexts, referring to a function in one manner is syntactically equivalent to referring to a variable: consider taking a pointer to a function versus taking a pointer to a variable. In the compiler's intermediate representation, the two are semantically distinct, but syntactically, whether an identifier is a variable, a function name, or an invalid identifier cannot be determined from the context.
Since it's not determinable from the context, without function prototypes, the compiler would need to make an extra pass over each one of your source files each time one of them compiles. This would add an extra O(n) factor for any compilation (that is, if compilation were O(m), it would now be O(m*n)), where n is the number of files in your project. In large projects, where compilation is already on the order of hours, having a two-pass compiler is highly undesirable.
Forward declaring all your functions would allow the compiler to build a table of functions as it scanned the file, and be able to determine when it encountered an identifier whether it referred to a function or a variable.
As a result of this, C (and by extension, C++) compilers can be extremely efficient in compilation.
It allows you to have a situation in which say you can have an iterator class defined in a separate .h file which includes the parent container class. Since you've included the parent header in the iterator, you can't have a method like say "getIterator()" because the return type would have to be the iterator class and therefore it would require that you include the iterator header inside the parent header creating a cyclic loop of inclusions (one includes the other which includes itself which includes the other again, etc.).
If you put the iterator class prototype inside the parent container, you can have such a method without including the iterator header. It only works because you're simply saying that such an object exists and will be defined.
There are ways of getting around it like having a precompiled header, but in my opinion it's less elegant and comes with a slew of disadvantages. Of couurse this is C++, not C. However, in practice you might have a situation in which you'd like to arrange code in this fashion, classes aside.