For example:
#include "pathtoheader1/header1.hh"
##include "pathtoheader2/header2.hh"
What is the difference between these two preprocessor directives?
Edit
From what I can tell, the ##include directive, in the context of the program I am working with, will prepend -I flags to the specified include path.
TRICK_CFLAGS += -Imodels
TRICK_CXXFLAGS += -Imodels
The compiler will now look for:
/models/pathtoheader1/header1.hh
instead of
/pathtoheader1/header1.hh
These flags are stored in a .mk file.
Additional Information
I am using NASA's Trick Simulation environment to build a simple 2-body simulation of the earth orbiting the sun. The specific tool I am using is called 'trick-CP', Trick's compilation tool.
https://github.com/nasa/trick
## is the token pasting operator in both the C and C++ preprocessors. It's used to concatenate two arguments.
Since it requires an argument either side, a line starting with it is not syntactically valid, unless it's a continuation of a previous line where that previous line has used the line continuation symbol \ or equivalent trigraph sequence.
Question is about NASA Trick. Trick extends C and C++ language with its own syntax.
From Trick documentation:
Headers files, that supply data-types for user-defined models should be included using ##include . Note the double hash (#).
The second one is a syntax error in C++, and I am pretty sure it is a syntax error in C too. The ## preprocessor operator is only valid inside a preprocessor macro (where it forces token pasting).
Here is what the Trick Documentation says about include:
Include files
There are two types of includes in the S_define file.
Single pound "#" includes.
Include files with a single pound "#" are parsed as they are part of the S_define file. They are treated just as #include files in C or C++ files. These files usually include other sim objects or instantiations as part of the S_define file.
Double pound "#" includes.
Include files with a double pound "##" are not parsed as part of the S_define file. These files are the model header files. They include the model class and structure definitions as well as C prototypes for functions used in the S_define file. Double pound files are copied, minus one pound, to S_source.hh.
Also here is a link to where it talks about it in the Trick documentation: https://nasa.github.io/trick/documentation/building_a_simulation/Simulation-Definition-File
Related
I am trying to run a c program in vsCode but it keeps telling me "no such file or directory" when referring to one of my .h files (yet finds the others just fine...). I have tried googling this countless times but all the solutions seem to go way over my head and refer to things I cannot find such as the json file (and googling where that is didnt help either). Below is the error I am getting
Have you tried using #include "parser.h"?
From the C Standard (ISO/IEC 9899:2018 (C18)), section 6.10.2 "Source file inclusion":
2. A preprocessing directive of the form
# include < h-char-sequence > new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
3. A preprocessing directive of the form
# include " q-char-sequence " new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include < h-char-sequence > new-line
with the identical contained sequence (including > characters, if any) from the original directive.
When including a source file, if you use the #include <header.h> notation, the compiler (gcc in your case) will search the header in a standard list of system directories (and, if used, the directories specified after the -l option), while if you use the #include "header.h" notation, the compiler will search the header in the directory containing the current file.
If you want to know where gcc is seeking for source files, I'd suggest you to have a look at this article.
As mikyll98 has detailedly explained and indicated, #include <> and #include “” are for different things. Check which case your parser.h falls into.
In addition to miky’s answer, You should also check if the location of your header file is “visible” to VScode. This is where the json file comes in. VSCode settings is sometimes funky (I think) because sometimes you have to resort to json config files to fully modify the settings, and the location / configurable knobs of such json files are not explicit. You could open VSCode settings, type in the search bar “include path” or “include directories”, and go to the section relevant to C/C++. There should be an option where you either add extra directories via the GUI, or let VSCode open a json file and you can add your path to that file. But be aware that the configurable knobs of said json file isn’t explicit and you’ll have to look up VSCode’s documentation website to know what specific json attribute to add.
I have a project with a src and an include directory. When compiling, I pass the include directory via the -I option (gcc -Iinclude ...).
Should I use double quotes (") or angle brackets (<) to include my own header files?
I tried to look for an answer and found these two conflicting statements:
include header files relative to the c file via double quotes. Everything else (header files in include paths) with angle brackets.
-> thus use angle brackets
include standard headers with angle brackets. Everything else with double quotes. -> thus use double quotes
In my opinion statement 2 is clearer. When including a file with double quotes it is most obvious that it is my own header.
Should I use quotes or brackets to include my own header files? The C standard allows both possibilities. So what is the best practice?
The common convention is:
Use < … > for headers that are part of the C implementation or the platform—headers outside your project such as the C standard library, Unix or Windows headers, and headers of libraries generally installed for your development environment.
Use " … " for headers that are part of your project.
This is not fully determined by the C standard; it is a matter of general practice. For each delimiter choice, a compiler has a list of places (a search path) where it looks for headers. Those search paths are commonly designed to facilitate the use described above, but they are customizable (depending on the compiler you use) by command-line switches, by environment variables, by system settings, and/or by settings made when building the compiler.
Here is what the C standard says about them in C 2018 6.10.2. Paragraph 2 says:
A preprocessing directive of the form
# include < h-char-sequence > new-line
searches a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
Paragraph 3 says:
A preprocessing directive of the form
# include " q-char-sequence " new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read
# include < h-char-sequence > new-line
with the identical contained sequence (including > characters, if any) from the original directive.
Note some of the differences between the two:
The text for the bracket form says it searches for a header identified uniquely. The text for the quote form does not include the word “uniquely”. This suggests all the headers referred to by the bracketed form are supposed to be different from each other, which you might expect if they were part of a designed system seeking to avoid ambiguity.
Note that it says the first form “searches a sequence of implementation-defined places.” This accords with the compiler having a list of places to search for standard headers. For the second form, it uses “the source file identified by the specified sequence.” This accords with using the text between quotes as a path in the file system.
This text in the standard is quite lax, both allowing implementation-defined methods of identifying the files, so either can be stretched to be the same as the other (although it would be interesting to see a compiler complain that a header named in brackets is not unique), and compiler configuration options are sufficiently broad that you could use each in either way for your project. However, it is generally better to stick to convention.
Consider this example:
+- include/
| |
| \- header.h
|
+- src/
|
\- main.c
The statements are saying to either use:
#include "../include/header.h"
gcc src/main.c
or:
#include <header.h>
gcc -Iinclude src/main.c
You decide which style to use. I personally prefer the second one. But it more important to use a consistent style throughout the project.
Say that the names of the parsers are parser_1 and parser_2.
parser_1:
Bison file = parser_1.y
Flex file = parser_1.l
After Compiling with gcc I get my paser in the following two files:
parser_1.tab.c and parser_1.lex.yy.c
Similary my parser_2 consitst of:
parser_2.tab.c and parser_2.lex.yy.c
I am trying to compile both the parsers together because me program needs both the parsers. I cannot replace the two parsers by one parser because the following two reasons. The grammars are completely different and the parsers are to be invoked at entirely different statges of my program.
gcc parser_1.tab.c parser_1.lex.yy.c \
parser_2.tab.c parser_2.lex.yy.c \
my_program.c -lfl
It gives me error that some functions like yylex (), yyparse () etc. have been defined multiple times, which is understandable.
My Question:
Is there some method by which I can have the two parsers in my program?
Or please give your suggestions.
To invoke use multiple parsers from a C program there are two methods:
Use multiple start symbols, if grammars are closely related.
For details see
http://www.gnu.org/software/bison/manual/html_node/Multiple-start_002dsymbols.html
Change the prefix yy for parser(s). This would remove all the name conflicts. A new prefix can be specified using the option -Dapi.prefix={prefix}.
You will need to modify the prefixes of the lexical analyser also, if you are using a separte lexical analyser. This can be achieved by using the --prefix=PREFIX flag.
For details about renaming in Bison see: http://www.gnu.org/software/bison/manual/html_node/Multiple-Parsers.html
For details about renaming in Flex see: http://westes.github.io/flex/manual/#Code_002dLevel-And-API-Options
In flex you will need to specify %option noyywrap as the very first line of the .l file. For details see: http://westes.github.io/flex/manual/Generated-Scanner.html#index-yywrap_0028_0029
Is there a way to use a preprocessor directive without using the # character in C code?
Can we echo the hash character somehow by using its ASCII etc. equivalents?
Eg: 1 can be echoed by using 'SOH' in the .c source file. Is there a similar hack for
'#'?
You can use the digraph or trigraph equivalent if your compiler supports them (you may need to pass flags to the compiler):
digraph: %:
trigraph: ??=
However, if you're trying to use preprocessor macros to generate preprocessor commands, there's no way to do that.
I have #define values in headers that I certainly want Doxygen to document but I have others in C files that I treat as static constants and I don't want Doxygen to document them. Something as simple and stupid as
#define NUMBER_OF(a) (sizeof((a))/sizeof((a)[0]))
#define MSTR(e) #e
How can I keep Doxygen from putting those #defines in the documentation it creates? I've tried marking it with #internal but that didn't seem to help.
A somewhat-related question on Doxygen and #define, how can I get:
#define SOME_CONSTANT 1234 /**< An explanation */
to put "SOME_CONSTANT" and "An explanation" but not "1234" in the output?
There is no need to use the \cond and \endcond commands. You can hide the initializer by simply using the \hideinitializer command:
#define SOME_CONSTANT 1234 /**< An explanation #hideinitializer */
Regarding the first question, you may set HIDE_UNDOC_MEMBERS = YES and only the macros having a Doxygen documentation block will be shown in the output.
You can set MAX_INITIALIZER_LINES = 0 in your doxyfile to hide the values of your defines.
You can exclude any part of code from Doxygen parsing with \cond ... \endcond tags.
edit: Some related questions:
How can Doxygen exclude a C++ class?
Exclude some classes from doxygen documentation
You only want to document what is declared in the .h files. I'm assuming you declare all static functions and variables as static in your .c files. All the remaining are declared in .h corresponding files also. These are your "public" members.
What I like to do in this case, and I believe doxygen was more designed to be used this way is:
in your Doxyfile, set EXTRACT_ALL = NO and add the directory where your .h files are to INPUT
add /** \file */ to all your .h files (but not your .c files).
This will index only what is contained in your .h files. You can still add the directory containing your .c files to INPUT at your Doxyfile, and they will be scanned for additional documentation for your "public" members...
It will no doubt still seem noisy and unnatural, but to address your other question, try:
/** An explanation */
#define SOME_CONSTANT /** #cond */ 1234 /** #endcond */
I solved this problem by moving my documentation from the .c file to the .h file. Then run doxygen only on the .h file.
Then the items that I want to document (the 'public' items) are intrinsically what doxygen picks up.
Because I have been previously careful to put 'public' items in the .h file and 'private' items in the .c file this works very well.
This technique came to mind when I noticed that doxygen was pulling in the includes. It struck me that if I were to also move the subset of includes that the calling module would need to use my module, then that list would be documented as well.
This technique has an additional benefit: I can put the documentation in one terminal window and the source in a different terminal window while updating the documentation.
Sometimes you may have a define which you want to document, but want doxygen to treat it differently (or even ignore it completely to avoid parsing errors).
For this you can define the #define in doxygen differently than in your sourcecode.
Example:
Some compilers allow variable linkage to specific segments, i.e.:
const int myvar # "segment_of_myvar_in_memory"=123;
=> doxygen would parse the "segment_of_myvar_in_memory" part as variable name which is not desired.
We could use a define for it:
#define __link_to_segment(name) # name
const int myvar __link_to_segment("segment_of_myvar_in_memory")=123;
If Preprocessing is active, Doxygen interprets our variable now as a function because of the function-like define using brackets..
But if we redefine our define within the Doxyfile, behaviour changes:
PREDEFINED = __link_to_segment(a)=
now the variable is parsed correctly as variable - also all types or keywords in front are correctly shown as keywords.
A nice side effekt:
In case you use 2 different IDEs with your code (one IDE for compiling&debugging, one for editing), you will also discover that some IDEs (i.e. Eclipse) have problems parsing variables with #"segment name". Using the approach above, you can redefine the __link_to_segment(name) there too:
#define __link_to_segment(name)
i.e. Eclipse will then show and parse the variable correctly, whereas the "compiling&debugging" IDE can still link the variable to its segment name.