When you run bison, it creates a stack class for you in "stack.hh". The file name is fixed, but the contents are wrapped in a namespace of your choosing.
If you use bison to generate 2 separate grammars (ie 2 *.y files) and you use the C++ mode, the "stack.hh" files conflict and get overwritten.
A similar thing happens for the "location.hh" and "position.hh" classes that are autogenerated, but there is a work around in bison 2.7
%define api.location.type "foo::location"
that lets you reuse the foo grammar namespace in your bar grammar namespace.
But I can't find anyway of doing this exercise when dealing with the "stack.hh" file.
The easiest way to deal with this is just to put the Bison files in two separate directories. Then when you generate the code the files will not conflict, assuming each set of files gets generated in the same location as the corresponding Bison file.
Related
I am making a compiler with flex, bisonc++ and gcc (in Ubuntu), which compile a simple esoteric programming language to c++ source code(I don't want to make assembly code).
I want to make optimization as well, so I need an AST to do it.
I also have a symbol table, but I don't have any idea how to construct an AST properly and if I have a correct AST for the grammar, how to make code optimization (so I don't want just print the AST).
My grammar (.y file) is full and correct (it recognize every syntax error).
It's clear that I have to write the action code of AST into the .y file, but I don't know what to read (I mentioned it also have syntax table), and where I should define my AST struct or class.
My files:
language.l (lex file where are the tokens)
language.y (bisonc++ source file(the grammar of my language))
lex.yy.cc (it's generated by flex)
Those are generated by bisonc++:
Parser.h (in this file, I added the symbol table, which is an std::map<std::string, var_data> where var_data is struct defined in semantics.h)
Parser.ih
Parserbase.h
parse.cc
I have a language.cc file which containts the main fuction, it reads the input file (comand line argument) and starts the analysis.
I also have a semantics.h header which contains structs for the symbol table.
Basically, I have a .proto definition which declares the package as main.
package main;
This file is being used by two programs. I am rewriting one of them. When I generate the c++ files for this definition, the namespace generated is main. This causes clash with the main function. Right now I just wrap the header and the source of the generated files with this:
#define main protocol
//Generated code
#undef main
I want to know if it is safe for me to rename the package in the .proto file and if I did, would the resulting protocol buffer messages will be compatible.
Something like
package xxx;
//Same definitions
Yes this would be 100% compatible in terms of data using the binary protocol - the binary DAT excludes all names, only tag numbers are included.
If you're using the JSON protocol, some names matter - in particular the member names.
The intention here is that when the program starts, a particular function will read a configuration file and set some #defines. In other parts of this project, these preprocessor directives will decide what code to execute and what not.
Example:
A file X contains:
#define WHAT 0
A file Y contains:
#if (WHAT)
// Do this
How and where should these types of #defines be organized so that they are accessible where they should be without creating a mess?
Preprocessor directives are resolved when the program is compiled, not when it starts, so what you're asking for can't be done.
You'll need a runtime mechanism to make this work, but that doesn't guarantee code exclusion from the compiled binary.
The intention here is that when the program starts, a particular
function will read a configuration file and set some #defines. In
other parts of this project, these preprocessor directives will decide
what code to execute and what not.
As the other answer has said, this is not possible as the preprocessor directives like #define are consumed by the compilers pre-processors. What your executable binaries actually see is the compiled modified source which remains the same irrespective of every time you run with a different file that you open. Moreover, there is no concept like loading a configuration file and changing the run time as, C++ is a compiled language and not an interpreted.
What actually is possible is to
load the configuration file (preferable in a stand format)
Parse it with publicly available libraries for standard format or write your own parser.
Use STL objects like map to create a mapping between the configuration key and value
Place the STL in some namespace so as not to pollute the global namespace and make it extern. Ensure that an extern declaration is present in a header file and the variable is defined in a .cpp file so that the variable can be accesses from a translation unit different from where it was defined.
Consume the mapped configuration anywhere within your program.
I have a .cpp that's getting rather large, and for easy management I'd like to split it into a few files. However, there are numerous globals, and I'd like to avoid the upkeep of managing a bunch of extern declarations across different files. Is there a way to have multiple .cpp files act as a single file? In essence, I'd like a way to divide the code without the division being recognized by the compiler.
Is there a way to have multiple .cpp files act as a single file?
Yes. That is the definition of #include. When you #include a file, you make a textual substitution of the included file in place of the #include directive. Thus, multiple included files act together to form one translation unit.
In your case, chop the file into several bits. Do this exactly -- do not add or detract any lines of text. Do not add header guards or anything else. You may break your files at almost any convenient location. The limitations are: the break must not occur inside a comment, nor inside a string, and it must occur at the end of a logical line.
Name the newly-created partial files according to some convention. They are not fully-formed translation units, so don't name them *.cpp. They are not proper header files, so don't name them *.h. Rather, they are partially-complete translation units. Perhaps you could name them *.pcpp.
As for the basename, choose the original file name, with a sequentially-numbered suffix: MyProg01.pcpp, MyProg02.pcpp, etc.
Finally, replace your original file with a series of #include statements:
#include "MyProg01.pcpp"
#include "MyProg02.pcpp"
#include "MyProg03.pcpp"
Of course, you can always just #include the various CPP-files into one master file which is the one that the compiler sees. It's a very bad idea though, and you will eventually get into headaches far worse than refactoring the file properly.
whilst you can declare the same set of globals in many cpp files, you will get a separate instance of each as the compiler compiles each file, which will then fail to link as they are combined.
The only answer is to put all your globals in their own file, then cut&paste them into a header file that contains extern declarations (this can easily be automated, but I find using the arrow keys to just paste 'extern' in front of them is quick and simple).
You could refactor everything, but often its not worth the effort (except when you need to change something for other reasons).
You could try splitting the files, and then using the compiler to tell you which globals are needed by each new file, and re-introducing just those directly into each file, keeping the true globals separately.
If you don't want to do this, just #include the cpp files.
I've got a C/C++ question, can I reuse functions across different object files or projects without writing the function headers twice? (one for defining the function and one for declaring it)
I don't know much about C/C++, Delphi and D. I assume that in Delphi or D, you would just write once what arguments a function takes and then you can use the function across diferent projects.
And in C you need the function declaration in header files *again??, right?. Is there a good tool that will create header files from C sources? I've got one, but it's not preprocessor-aware and not very strict. And I've had some macro technique that worked rather bad.
I'm looking for ways to program in C/C++ like described here http://www.digitalmars.com/d/1.0/pretod.html
Imho, generating the headers from the source is a bad idea and is unpractical.
Headers can contain more information that just function names and parameters.
Here are some examples:
a C++ header can define an abstract class for which a source file may be unneeded
A template can only be defined in a header file
Default parameters are only specified in the class definition (thus in the header file)
You usually write your header, then write the implementation in a corresponding source file.
I think doing the other way around is counter-intuitive and doesn't fit with the spirit of C or C++.
The only exception is can see to that is the static functions. A static function only appears in its source file (.cor .cpp) and can't (obviously) be used elsewhere.
While I agree it is often annoying to copy the header definition of a method/function to the source file, you can probably configure your code editor to ease this. I use Vim and a quick script helped me with this a lot. I guess a similar solution exists for most other editors.
Anyway, while this can seem annoying, keep in mind it also gives a greater flexibility. You can distribute your header files (.h, .hpp or whatever) and then transparently change the implementation in source files afterward.
Also, just to mention it, there is no such thing as C/C++: there is C and there is C++; those are different languages (which indeed share much, but still).
It seems to me that you don't really need/want to auto-generate headers from source; you want to be able to write a single file and have a tool that can intelligently split that into a header file and a source file.
Unfortunately, I'm not aware of any such tool. It's certainly possible to write one - but you'd need a given a C++ front end. You could try writing something using clang - but it would be a significant amount of work.
Considering you have declared some functions and wrote their implementation you will have a .c/cpp file and a header .h file.
What you must do in order to use those functions:
Create a library (DLL/so or static library .a/.lib - for now I recommend static library for the ease of use) from the files were the implementation resides
Use the header file (#include it) (you don't need to rewrite the header file again) in your programs to obtain the function definitions and link with your library from step 1.
Though >this< is an example for Visual Studio it makes perfect sense for other development environments also.
This seems like a rudimentary question, so assuming I have not mis-read,
Here is a basic example of re-use, to answer your first question:
#include "stdio.h"
int main( int c, char ** argv ){
puts( "Hello world" );
}
Explanation:
1. stdio.h is a C header file containing (among others) the definition of a function called puts().
2. in main, puts() is called, from the included definition.
Some compilers (including gcc I think ) have an option to generate headers.
There is always very much confusion about headers and source-files in C++. The links I provided should help to clear that up a little.
If you are in the situation that you want to extract headers from source-file, then you probably went about it the wrong way. Usually you first declare your function in a header-file, and then provide an implementation (definition) for it in a source-file. If your function is actually a method of a class, you can also provide the definition in header file.
Technically, a header file is just a bunch of text that is actually inserted into the source file by the preprocessor:
#include <vector>
tells the preprocessor to insert contents of the file vector at the exact place where the #include appears. This really just text-replacement. So, header-files are not some kind of special language construct. They contain normal code. But by putting that code into a separate file, you can easily include it in other files using the preprocessor.
I think it's a good question which is what led me to ask this: Visual studio: automatically update C++ cpp/header file when the other is changed?
There are some refactoring tools mentioned but unfortunately I don't think there's a perfect solution; you simply have to write your function signatures twice. The exception is when you are writing your implementations inline, but there are reasons why you can't or shouldn't always do this.
You might be interested in Lazy C++. However, you should do a few projects the old-fashioned way (with separate header and source files) before attempting to use this tool. I considered using it myself, but then figured I would always be accidentally editing the generated files instead of the lzz file.
You could just put all the definitions in the header file...
This goes against common practice, but is not unheard of.