I am writing a c program and came across the declare() function.
When I searched on web for it, I received results about function declaration and function definition.
I would like to know about the declare() function in c,what it does, what are its parameters, etc.
Here is block of code that uses the function:
char file[50];
strcpy(file,"IS_inst.txt");
declare(file,IS_ins,&IS_inst_count);
strcpy(file,"DS_inst.txt");
declare(file,DS_ins,&DS_inst_count);
strcpy(file,"AD_inst.txt");
declare(file,AD_ins,&AD_inst_count);
strcpy(file,"REG_OPERAND.txt");
declare(file,REG_oprand,®_op_count);
There is no such function in C, it might/should be defined in your program.
There is no function called declare in the C standard library, or, as far as I know, in any commonly used add-on library.
There's nothing special about the name declare. It might as well have been named foobar.
It must be declared as a function or as a macro somewhere in your program. If your development environment has such a feature, try querying the name (perhaps you can hover over or right-click on the function name if you're using an IDE). Or just search the source file and any headers it #includes for the name declare. grep and ctags are both useful tools for this kind of thing.
You should implement this function in your code
Declare function means you are assigning a function's return type. There is no built in function named as "Declare Function". Suppose, you want to create a function to add numbers. So, you can name the function as "Add". In c programming you have to declare the function type at first example: for two integers addition the function type should be int Add() {}
Related
I have code that gives me an error. Implicit declaration of isNumericFloat.
I want to know if the function:
isNumericFloat()
a built it function in C?
NO, it's not a "built-in" c function.1
This function is used somewhere in your code and it's not part of the standard library. In fact, just because it uses camel case which is not very common in c code it seems like an odd function written by a not so c-ish programmer, of course that's a subjective reason, but commonly c programmers would choose is_numeric_float().
You need to search your code to see if you can find it's defintion, but in the mean time you can provide a prototype, like
int isNumericFloat(float value); // I don't really know what arguments it takes
// but you can surely infer them from the code
before it's ever called in the code, if you do so one of these two things will happen
If there is a definition for the function somewhere, it will compile fine.
If there is no definition, the linker will tell you that there is/are undefined reference/s to it in the code.
1Strictly speaking, there are no built-in functions in c, there is something called the standard library (headers starting with std , like stdlib.h), and I mean that it's not part of such library.
Let's say I have a function:
int foo (int A, char B){...}
One of the features I want to implement is the capability for the user to call any function on the application through the Linux terminal. So as an input for the software, in the terminal they type something like:
foo 2 'a'
Then my application parses that, and using the symbol tables it is able to find the address for foo(), as well as the type for all its parameters.
However, I'm not sure how I would pass the parameters to the function when calling it, since I can have hundreds of different parameters types combination depending on the function called.
Any hint how that could be achieved without having hundreds of nested if statements to cast the parameters to the correct types before calling the functions?
That functionality is similar to what GDB has, where you can do call foo(2,'a') and GDB calls that function to you.
There are two approaches to this. If what you described is all you want to do, then you can use the dyncall library so that you dont have to worry about platform/compiler-specific calling semantics yourself:
The dyncall library encapsulates architecture-, OS- and compiler-specific function call semantics in a virtual bind argument parameters from left to right and then call interface allowing programmers to call C functions in a completely dynamic manner. In other words, instead of calling a function directly, the dyncall library provides a mechanism to push the function parameters manually and to issue the call afterwards.
The other approach is, if you might want to do more: e.g. what if an argument cannot be created by a literal? What if the argument is the output of another function? Can you write f(123, g("a")) in your console? Can you write x=g("a"); f(x)? And if(cond) x="a" else x="b"; f(x) In this case you need to embed a scripting language like e.g. LUA.
If you compile your binary with debug information, you can extract it using libdwarf (https://www.prevanders.net/dwarf.html), so for every function you can get a list a parameters with types and you would know how to interpret user's input.
I am writing a C program that uses some macros that make function prototypes in batches, however I often don't write all of the functions the macro makes prototypes for. This compiles fine in gcc, but I'm wondering if this is unsafe in any way or if it will cause errors if I use a different compiler?
The prototypes only declare the name and use (parameters, types) of functions. If the compiler encounters a use of such a function, it will check your use against the prototype and warn if your use is not compatible.
When the development environment starts linking the objects, it will search for functions used but not found in the object. Linking fails if a function that is used is not found.
Since the prototype only declares the function and its usage, it does not require the function to be present IF the function is not used. Hence it is safe to declare prototypes for functions that you don't provide.
(But it could be confusing for another programmer who will expect the function to exists if he/she sees the prototype.)
Why use function prototypes in C? It seems sort of redundant because we already declare the function name, argument types, and return type in the definition. Do the prototypes have to be declared before the function is defined or used for the optimizations?
Generally speaking, you don't need to explicitly declare functions because defining them also declares them. Here are two situations where you would need to:
The definition of the function is in an external module.
For example, if the function is defined in definer.c, but you want to call it from user.c, you will need to declare the function in user.c or a file included by it (typically, definer.h).
The definition of the function comes after a call to it.
For example, if you have two functions that call each other, you will need to declare the second one before the definition of the first one.
With the declaration of a function the compiler can check the consistent use of parameters and return value, and can compile the code even if the function is not implemented in this module.
If the function is only declared but not implemented in the respective module, this gap will be closed by the linker, not the compiler.
It's similar to declaring extern variables. If you'd define them, the memory for them would be allocated multiple times. That's why you should never define variables in h-files, but declare them there. Including the h-file would result in multiple allocations of memory.
While a function definition specifies what a function does, a function prototype can be thought of as specifying its interface.
Creating library interfaces:
By placing function prototypes in a header file, one can specify an interface for a library.
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.