Defining a Preprocessor Macro - c++

I'm relatively new to C++ and I'm taking a class on it. Our class was assigned a lab and my teacher has said that the lab write-up is a bit hard to understand; however, he did not make any changes to the lab write-up. So, I came across this part of the lab:
Defining a Preprocessor Macro
Long-standing convention capitalizes macro names, and this macro name must be TRACE_FUNC. The macro has a single parameter, a symbol that will be replaced by a function name when you apply the macro to the code. The start of the macro looks like this:
#define TRACE_FUNC( symbol ) replacement-text`
and the preprocessor will substitute the replacement text everywhere that the TRACE_FUNC( sym ) string exists in the source code, AND feed the symbol into that replacement.
NOTE: the #define statement must be all on a single, logical line. To keep the length manageable, you can escape the newline character with a backslash at the end of the line; that will keep the preprocessor happy while allowing you to span a definition across multiple lines.
For this exercise, the replacement text must be a complete statement, including the terminating semi-colon.
The replacement text must be an output statement that prints the symbol followed by the text () called. and a newline to standard output. You can copy and modify one of the output statements from the warning.cpp source file.
warning.cpp is just a file we're using and TRACE_FUNC is being placed in a header file.
So, I read this a couple times and I'm not 100% sure what it's asking. Looking at it one way, it seems like it's asking me to create a macro called TRACE_FUNC. If you look at it another way, it's asking me to use the macro TRACE_FUNC. All of that is fine, but I don't know how to use TRACE_FUNC at all, I can't find any documentation on it anywhere and I don't know how to create a macro. When I asked for help, my teacher just kind of said. words and not ones that were very helpful because it was a very winding, confusing answer with no explanation of what TRACE_FUNC actually is.
Basically, all that my teacher said was that the symbol within TRACE_FUNC needs to be the name of one of the functions in the source code. As an example, say we had a function foo() within warning, then the symbol is supposed to be foo() (or foo, I'm not sure of that, either), from his explanation. Also, in the replacement text, apparently the name itself will be replaced if I put # in front of the symbol. I thought that supposed to denote preprocessor directives. Why am I supposed to be using it here?
Anyway, doing what my teacher says pretty much does nothing. Neither this line
#define TRACE_FUNC( foo() ) #foo() called. ;
nor this line
#define TRACE_FUNC( foo ) #foo () called. ;
replace any text, which I'm pretty sure is the operation of the #define directive. So I must be applying what my teacher said in the wrong way, but I don't really know why it's wrong or how to fix it.
So, my question. Is TRACE_FUNC actually a macro and if so, is there any documentation on it that I can read? Or am I supposed to be creating TRACE_FUNC and if so, how exactly am I supposed to do that?

Wow, what utter rubbish! You're supposed to be learning C++ right, not intricacies of the preprocessor.
Here's what you are supposed to be doing, though why is anyone's guess.
#define TRACE_FUNC(sym) std::cout << #sym << "() called\n"
void foo()
{
TRACE_FUNC(foo);
...
}
I'm assuming that there are examples from warning.cpp that use std::cout if not then you'll have to adapt the above to whatever you find in warning.cpp.
The idea is that each function starts with a use of the TRACE_FUNC macro, so you can trace the execution of your code. Why the professor thinks this is a good idea for newbies is beyond me. Even if it were a good idea, that you are expected to figure out the details for yourself is even stupider.
I could improve the macro above but that would probably confuse even more so I won't. For now I would just do what the professor says but ignore it. Hopefully he'll get onto stuff that's worth learning later.

here is a example: use the ouput print function in your libray to replace the standard function printf here
#define TRACE_FUNC(sym) printf("%s() called", #sym);
to use it as
TRACE_FUNC(printf)
the output should be
printf() called
your actual task is to print out a symbol in a defined format. so you need printf or similar function in your #define.

Related

Removal of unused or redundant code [duplicate]

This question already has answers here:
Listing Unused Symbols
(2 answers)
Closed 7 years ago.
How do I detect function definitions which are never getting called and delete them from the file and then save it?
Suppose I have only 1 CPP file as of now, which has a main() function and many other function definitions (function definition can also be inside main() ). If I were to write a program to parse this CPP file and check whether a function is getting called or not and delete if it is not getting called then what is(are) the way(s) to do it?
There are few ways that come to mind:
I would find out line numbers of beginning and end of main(). I can do it by maintaining a stack of opening and closing braces { and }.
Anything after main would be function definition. Then I can parse for function definitions. To do this I can parse it the following way:
< string >< open paren >< comma separated string(s) for arguments >< closing paren >
Once I have all the names of such functions as described in (2), I can make a map with its names as key and value as a bool, indicating whether a function is getting called once or not.
Finally parse the file once again to check for any calls for functions with their name as in this map. The function call can be from within main or from some other function. The value for the key (i.e. the function name) could be flagged according to whether a function is getting called or not.
I feel I have complicated my logic and it could be done in a smarter way. With the above logic it would be hard to find all the corner cases (there would be many). Also, there could be function pointers to make parsing logic difficult. If that's not enough, the function pointers could be typedefed too.
How do I go about designing my program? Are a map (to maintain filenames) and stack (to maintain braces) the right data structures or is there anything else more suitable to deal with it?
Note: I am not looking for any tool to do this. Nor do I want to use any library (if it exists to make things easy).
I think you should not try to build a C++ parser from scratch, becuse of other said in comments that is really hard. IMHO, you'd better start from CLang libraries, than can do the low-level parsing for you and work directly with the abstract syntax tree.
You could even use crange as an example of how to use them to produce a cross reference table.
Alternatively, you could directly use GNU global, because its gtags command directly generates definition and reference databases that you have to analyse.
IMHO those two ways would be simpler than creating a C++ parser from scratch.
The simplest approach for doing it yourself I can think of is:
Write a minimal parser that can identify functions. It just needs to detect the start and ending line of a function.
Programmatically comment out the first function, save to a temp file.
Try to compile the file by invoking the complier.
Check if there are compile errors, if yes, the function is called, if not, it is unused.
Continue with the next function.
This is a comment, rather than an answer, but I post it here because it's too long for a comment space.
There are lots of issues you should consider. First of all, you should not assume that main() is a first function in a source file.
Even if it is, there should be some functions header declarations before the main() so that the compiler can recognize their invocation in main.
Next, function's opening and closing brace needn't be in separate lines, they also needn't be the only characters in their lines. Generally, almost whole C++ code can be put in a single line!
Furthermore, functions can differ with parameters' types while having the same name (overloading), so you can't recognize which function is called if you don't parse the whole code down to the parameters' types. And even more: you will have to perform type lists matching with standard convertions/casts, possibly considering inline constructors calls. Of course you should not forget default parameters. Google for resolving overloaded function call, for example see an outline here
Additionally, there may be chains of unused functions. For example if a() calls b() and b() calls c() and d(), but a() itself is not called, then the whole four is unused, even though there exist 'calls' to b(), c() and d().
There is also a possibility that functions are called through a pointer, in which case you may be unable to find a call. Example:
int (*testfun)(int) = whattotest ? TestFun1 : TestFun2; // no call
int testResult = testfun(paramToTest); // unknown function called
Finally the code can be pretty obfuscated with #defineā€“s.
Conclusion: you'll probably have to write your own C++ compiler (except the machine code generator) to achieve your goal.
This is a very rough idea and I doubt it's very efficient but maybe it can help you get started. First traverse the file once, picking out any function names (I'm not entirely sure how you would do this). But once you have those names, traverse the file again, looking for the function name anywhere in the file, inside main and other functions too. If you find more than 1 instance it means that the function is being called and should be kept.

Highlight arguments in function body in vim

A little something that could be borrowed from IDEs. So the idea would be to highlight function arguments (and maybe scoped variable names) inside function bodies. This is the default behaviour for some C:
Well, if I were to place the cursor inside func I would like to see the arguments foo and bar highlighted to follow the algorithm logic better. Notice that the similarly named foo in func2 wouldn't get highlit. This luxury could be omitted though...
Using locally scoped variables, I would also like have locally initialized variables highlit:
Finally to redemonstrate the luxury:
Not so trivial to write this. I used the C to give a general idea. Really I could use this for Scheme/Clojure programming better:
This should recognize let, loop, for, doseq bindings for instance.
My vimscript-fu isn't that strong; I suspect we would need to
Parse (non-regexply?) the arguments from the function definition under the cursor. This would be language specific of course. My priority would be Clojure.
define a syntax region to cover the given function/scope only
give the required syntax matches
As a function this could be mapped to a key (if very resource intensive) or CursorMoved if not so slow.
Okay, now. Has anyone written/found something like this? Do the vimscript gurus have an idea on how to actually start writing such a script?
Sorry about slight offtopicness and bad formatting. Feel free to edit/format. Or vote to close.
This is much harder than it sounds, and borderline-impossible with the vimscript API as it stands, because you don't just need to parse the file; if you want it to work well, you need to parse the file incrementally. That's why regular syntax files are limited to what you can do with regexes - when you change a few characters, vim can figure out what's changed in the syntax highlighting, without redoing the whole file.
The vim syntax highlighter is limited to dealing with regexes, but if you're hellbent on doing this, you can roll your own parser in vimscript, and have it generate a buffer-local syntax that refers to tokens in the file by line and column, using the \%l and \%c atoms in a regex. This would have to be rerun after every change. Unfortunately there's no autocmd for "file changed", but there is the CursorHold autocmd, which runs when you've been idle for a configurable duration.
One possible solution can be found here. Not the best way because it highlights every occurrence in the whole file and you have to give the command every time (probably the second one can be avoided, don't know about the first). Give it a look though.

#define (CLASS) in c++

I was looking at some coding done in a header file of a program installed on my PC & i found this :
# define A( CLASS ) \
B(CLASS) \
void *D(const C*to);
can anybody tell me what this means?
what are those slashes for & why hasnt all of this written in 1 line?
what does (CLASS) mean over here?
& why is there so much spacing done?
The \ just append the statements on two different lines.
It is essential same as:
#define A(CLASS) B(CLASS) void *D(const C*to);
This is done probably just for better readability.
The backslashes are there to "protect" the newline -- the preprocessor will throw away both the \ and the newline when reading in the file, putting the entire thing on one logical line. (Well, it'll also emit #line markups so the compiler can generate decent error messages too.)
Someone thought that layout was more legible than this:
#define A(CLASS) B(CLASS) void *D(const C*to);
If you imagine that B, D, and C are probably replaced with something else in the file, it'll look a bit like this in the output:
Monkey(Simian) void *Bananas(const sticks *to);
It must have made more sense to them, as they wrote the macro, to instead "see" it like this:
Monkey(Simian)
void *Bananas(const sticks *to);
I'm not sure it is an improvement (and I think I hate the style), but hopefully it makes sense now.
The slashes \ means the definition of the macro continues on the next line. In the absense of \, the next line would not be considered as a part of the macro, because by default macro considers only one line on which #define is written.
It is analogous to [contd...] which many people often use in English language (especially on online forums), to indicate continuation.

How To Extract Function Name From Main() Function Of C Source

I just want to ask your ideas regarding this matter. For a certain important reason, I must extract/acquire all function names of functions that were called inside a "main()" function of a C source file (ex: main.c).
Example source code:
int main()
{
int a = functionA(); // functionA must be extracted
int b = functionB(); // functionB must be extracted
}
As you know, the only thing that I can use as a marker/sign to identify these function calls are it's parenthesis "()". I've already considered several factors in implementing this function name extraction. These are:
1. functions may have parameters. Ex: functionA(100)
2. Loop operators. Ex: while()
3. Other operators. Ex: if(), else if()
4. Other operator between function calls with no spaces. Ex: functionA()+functionB()
As of this moment I know what you're saying, this is a pain in the $$$... So please share your thoughts and ideas... and bear with me on this one...
Note: this is in C++ language...
You can write a Small C++ parser by combining FLEX (or LEX) and BISON (or YACC).
Take C++'s grammar
Generate a C++ program parser with the mentioned tools
Make that program count the funcion calls you are mentioning
Maybe a little bit too complicated for what you need to do, but it should certainly work. And LEX/YACC are amazing tools!
One option is to write your own C tokenizer (simple: just be careful enough to skip over strings, character constants and comments), and to write a simple parser, which counts the number of {s open, and finds instances of identifier + ( within. However, this won't be 100% correct. The disadvantage of this option is that it's cumbersome to implement preprocessor directives (e.g. #include and #define): there can be a function called from a macro (e.g. getchar) defined in an #include file.
An option that works for 100% is compiling your .c file to an assembly file, e.g. gcc -S file.c, and finding the call instructions in the file.S. A similar option is compiling your .c file to an object file, e.g, gcc -c file.c, generating a disassembly dump with objdump -d file.o, and searching for call instructions.
Another option is finding a parser using Clang / LLVM.
gnu cflow might be helpful

finding a function name and counting its LOC

So you know off the bat, this is a project I've been assigned. I'm not looking for an answer in code, but more a direction.
What I've been told to do is go through a file and count the actual lines of code while at the same time recording the function names and individual lines of code for the functions. The problem I am having is determining a way when reading from the file to determine if the line is the start of a function.
So far, I can only think of maybe having a string array of data types (int, double, char, etc), search for that in the line and then search for the parenthesis, and then search for the absence of the semicolon (so i know it isn't just the declaration of the function).
So my question is, is this how I should go about this, or are there other methods in which you would recommend?
The code in which I will be counting will be in C++.
Three approaches come to mind.
Use regular expressions. This is fairly similar to what you're thinking of. Look for lines that look like function definitions. This is fairly quick to do, but can go wrong in many ways.
char *s = "int main() {"
is not a function definition, but sure looks like one.
char
* /* eh? */
s
(
int /* comment? // */ a
)
// hello, world /* of confusion
{
is a function definition, but doesn't look like one.
Good: quick to write, can work even in the face of syntax errors; bad: can easily misfire on things that look like (or fail to look like) the "normal" case.
Variant: First run the code through, e.g., GNU indent. This will take care of some (but not all) of the misfires.
Use a proper lexer and parser. This is a much more thorough approach, but you may be able to re-use an open source lexer/parsed (e.g., from gcc).
Good: Will be 100% accurate (will never misfire). Bad: One missing semicolon and it spews errors.
See if your compiler has some debug output that might help. This is a variant of (2), but using your compiler's lexer/parser instead of your own.
Your idea can work in 99% (or more) of the cases. Only a real C++ compiler can do 100%, in which case I'd compile in debug mode (g++ -S prog.cpp), and get the function names and line numbers from the debug information of the assembly output (prog.s).
My thoughts for the 99% solution:
Ignore comments and strings.
Document that you ignore preprocessor directives (#include, #define, #if).
Anything between a toplevel { and } is a function body, except after typedef, class, struct, union, namespace and enum.
If you have a class, struct or union, you should be looking for method bodies inside it.
The function name is sometimes tricky to find, e.g. in long(*)(char) f(int); .
Make sure your parser works with template functions and template classes.
For recording function names I use PCRE and the regex
"(?<=[\\s:~])(\\w+)\\s*\\([\\w\\s,<>\\[\\].=&':/*]*?\\)\\s*(const)?\\s*{"
and then filter out names like "if", "while", "do", "for", "switch". Note that the function name is (\w+), group 1.
Of course it's not a perfect solution but a good one.
I feel manually doing the parsing is going to be a quite a difficult task. I would probably use a existing tool such as RSM redirect the output to a csv file (assuming you are on windows) and then parse the csv file to gather the required information.
Find a decent SLOC count program, eg, SLOCCounter. Not only can you count SLOC, but you have something against which to compare your results. (Update: here's a long list of them.)
Interestingly, the number of non-comment semicolons in a C/C++ program is a decent SLOC count.
How about writing a shell script to do this? An AWK program perhaps.