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.)
Related
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)
};
I was reading about enums on stack overflow but couldn't find a satisfactory answer
I just want to know why we create enum type like
enum result {pass,fail}; //result - user defined type
I could have just written
enum{pass,fail};
Only use of enum type I can see is to make variable of that particular type
Like
enum result test;
So only for this purpose is enum type used? ( to create variables of enum type)
Or is there some better practical use of making variables of type enum
Sorry it may seem like a duplicate question
But I did some research wasn't satisfied by answers I read
As I am a beginner in C
The use of an enumeration constant (enum) has many advantages over using the traditional symbolic constant
style of #define. These advantages include a lower maintenance requirement, improved program readability,
and better debugging capability. The first advantage is that enumerated constants are generated automatically
by the compiler. Conversely, symbolic constants must be manually assigned values by the programmer.
For instance, if you had an enumerated constant type for error codes that could occur in your program, your
enum definition could look something like this:
enum Error_Code
{
OUT_OF_MEMORY,
INSUFFICIENT_DISK_SPACE,
LOGIC_ERROR,
FILE_NOT_FOUND
};
In the preceding example, OUT_OF_MEMORY is automatically assigned the value of 0 (zero) by the compiler
because it appears first in the definition. The compiler then continues to automatically assign numbers to
the enumerated constants, making INSUFFICIENT_DISK_SPACE equal to 1, LOGIC_ERROR equal to 2, and so on.
If you were to approach the same example by using symbolic constants, your code would look something
like this:
#define OUT_OF_MEMORY 0
#define INSUFFICIENT_DISK_SPACE 1
#define LOGIC_ERROR 2
#define FILE_NOT_FOUND 3
Each of the two methods arrives at the same result: four constants assigned numeric values to represent error
codes. Consider the maintenance required, however, if you were to add two constants to represent the error
codes DRIVE_NOT_READY and CORRUPT_FILE. Using the enumeration constant method, you simply would put these two constants anywhere in the enum definition. The compiler would generate two unique values for hese constants. Using the symbolic constant method, you would have to manually assign two new numbers to these constants. Additionally, you would want to ensure that the numbers you assign to these constants are unique. Because you don’t have to worry about the actual values, defining your constants using the enumerated method is easier than using the symbolic constant method. The enumerated method also helps prevent accidentally reusing the same number for different constants.
Another advantage of using the enumeration constant method is that your programs are more readable and
thus can be understood better by others who might have to update your program later. For instance, consider
the following piece of code:
void copy_file(char* source_file_name, char* dest_file_name)
{
...
Error_Code err;
if (drive_ready() != TRUE)
err = DRIVE_NOT_READY;
...
}
Looking at this example, you can derive from the definition of the variable err that err should be assigned
only numbers of the enumerated type Error_Code. Hence, if another programmer were to modify or add
functionality to this program, the programmer would know from the definition of Error_Code what
constants are valid for assigning to err.
Conversely, if the same example were to be applied using the symbolic constant method, the code would look
like this:
void copy_file(char* source_file, char* dest_file)
{
...
int err;
...
if (drive_ready() != TRUE)
err = DRIVE_NOT_READY;
...
}
Looking at the preceding example, a programmer modifying or adding functionality to the copy_file()
function would not immediately know what values are valid for assigning to the err variable. The
programmer would need to search for the #define DRIVE_NOT_READY statement and hope that all relevant
constants are defined in the same header file. This could make maintenance more difficult than it needs to be and make your programs harder to understand.
NOTE
Simply defining your variable to be of an enumerated type does not ensure that only valid values
of that enumerated type will be assigned to that variable. In the preceding example, the compiler
will not require that only values found in the enumerated type Error_Code be assigned to err; it
is up to the programmer to ensure that only valid values found in the Error_Code type definition
are used.
A third advantage to using enumeration constants is that some symbolic debuggers can print the value of an
enumeration constant. Conversely, most symbolic debuggers cannot print the value of a symbolic constant.
This can be an enormous help in debugging your program, because if your program is stopped at a line that
uses an enum, you can simply inspect that constant and instantly know its value. On the other hand, because
most debuggers cannot print #define values, you would most likely have to search for that value by manually
looking it up in a header file.
With enum result {pass, fail};, you can create a function with result as a parameter type:
void foo(enum result r);
As well as helping source code readability, it can also assist enormously with debugging: a good debugger will display the enumeration name for r, despite the fact that you can pass any value permissible by the enum's backing type to the function.
enum types allow you to give meaningful names to int values. In your example, you have pass and fail as the values of the enum result type. This allows you to do something like
enum result r = pass;
Alternatively, if you use numbers 0 and 1 instead, you would have to do
int r = 1;
Note that when you read the enum version, the meaning is immediately obvious. When you read the int version, you may ask "Why the value 1?" and "What does 1 stand for?".
In short, enum makes code easier for humans to read.
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.
For example, in Python I can use getargspec from inspect to access a function's arguments in the follow way:
>>> def test(a,b,c):
... return a*b*c
...
>>> getargspec(test)
ArgSpec(args=['a', 'b', 'c'], varargs=None, keywords=None, defaults=None)
Is this possible to do in C at all? More specifically I am only interested in the arguments' names, I don't particularly care about their types.
The language doesn't include anything along this line at all.
Depending on the implementation, there's a pretty fair chance that if you want this badly enough, you can get at it. To do so, you'll typically have to compile with debugging information enabled, and use code specific to a precise combination of compiler and platform to do it. Most compilers do support creating and accessing debugging information that would include the names of the parameters to a function -- but code to do it will not be portable (and in many cases, it'll also be pretty ugly).
No, all variable names are gone during compilation (except perhaps file-scope variables with "extern" storage duration), so you can't get the declaration names of the arguments.
No, this is absolutely impossible in C, since variable names exist only at compile time.
Probably it would be solvable via macro.
You could define
#define defFunc3(resultType,name,type0,arg0name,type1,arg1name,type2,arg2name) \
...store the variable names somehow... \
...you can access the variable name strings with the # operator, e.g. #arg0name \
...or build a function with concatenation: getargspec_##name \
resultType name(type0 arg0name, type1 arg1name, type2 arg2name )
and then declare your function with this macro:
defFunc3( float, test, float, a, float, b, float, c ) {
return a * b * c;
}
In the macro body, you could somehow store the variable names (with the stringification preprocessor operator) and/or the function address somewhere or create some kind of "getargspec" function (via the concatenation preprocessor operator).
But this will be definitely ugly, error prone and tricky (since you can not execute code in such a function definition directly). I would avoid such macro magic whenever possible.
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.