I'm trying to use the HTML parser - Gumbo (written in C) in my C++ Builder XE6 project.
When I compile, I get many errors (E2140 Declaration is not allowed here etc.), which appear to be coming from the file char_ref.rl.
I've tried a lot to avoid these errors but I didn't succeed.
Has anyone ever used Gumbo in a C++ Builder project, or at least in a C++ project?
Thank you
Note: extern "C" doesn't mean "compile this code as C". It means that the C++ code inside the block should be compiled so that any external names etc. are published in a way compatible with the C ABI. And such a block shouldn't include any function definitions. You may be using extern "C" incorrectly in your code but it's hard to say without seeing your code.
Anyway, the C compiler part of bcc32.exe doesn't seem to allow mixed statements and declarations, even if you give the flag -An which is supposed to mean "Use C99 keywords and extensions".
You will have to either do a 64-bit build or make a whole bunch of changes to this C source for compatibility with the dinosaur that is bcc32. Or you could build Gumbo as a DLL with a modern compiler (if it supports that option, IDK).
Related
When I write some Objective-C source code, I can use clang -rewrite-objc FILENAME.m to translate this code to C++ source code. What is the relationship between the C++ source code and the original Objective-C source code?
Objective-C is a superset of C (but not C++) so why can Objective-C be translated to C++, not C? When Objective-C code is compiled, linked and run on iOS or macOS, is it precompiled to C++, then linked and so on?
Objective-C can be translated to straight C still. There isn't anything in the ObjC runtime API that requires C++, though the innards are implemented in C++ here and there. I don't think this has changed. The rewriter, however, may be generating C++ simply because that is the most convenient/efficient target to generate.
There is no translation step in Xcode's build process. It compiles native Objective-C code; that is, the ObjC is converted straight to the interim format that the compiler uses to then generate executables, just like C++, C and any other language the compiler natively supports.
The translator exists explicitly because there is no Objective-C compiler in Visual Studio. Prior to the rewriter, a different compiler was used to compile ObjC code into libraries on Windows and then combine those libraries with code compiled in Visual Studio to yield the final applications.
It worked, but debugging was really really complicated because any call stack that walked between the two code generation styles could not be debugged from a single debugger!
I have a project written in C (on Linux) and now want to use a third-party C ++ library that provides .h and .c source files.
I renamed the .c file to .cpp and then include this library in the C project. However, the following error appears when compiled:
unknown type name ‘class’
Added: The third-party library is here https://github.com/0xmalloc/c-log
The author say it's friendly to both C and C++
There are two options here:
you make your whole project a C++ one - this doesn't mean you need to convert your C code to C++ but rather that you will probably have to touch this and that part of it and also go for a C++ and not C-only compiler
provide wrappers - usually if you write C++ code in C style (no classes etc.) you will only have to do that extern "C" void foo() routine for your C++ functions. However the moment you start working with features that C doesn't support you will have to provide wrappers for your C++ functionality so that it can be exposed to the C part of your application. Such procedure can be from very easy to incredibly complex. For example many modern C/C++ API also provide Python API. In order to do that without having to rewrite everything in Python the authors create wrappers that translate the C/C++ functionality to Python. Depending on how well this is done features of the target language (Python in case we go from C/C++ to Python) can be used to allow better error handling, type checking, readability, native (to the target language) data containers etc.
I do believe that the author of the library misled you since the library is clearly for C++ (the classes in the header are definitely the most obvious thing that just screams C++).
I am developing a project which I have to develop a compiler(actually a parser) besides the main project. I am using Qt 5.3 and Windows (But the result is almost the same on Ubuntu 14.04).
I am experienced in using flex and bison, however this time, firs I develop a Scanner and then Parser. I test the scanner carefully and made sure it is error less. but as I add the parser to the project many errors occurred.(for example undefined reference to yylex(), however I declared extern int yylex() and I cannot use library as I will mention) and after that when I eliminate the parser, some features which worked before are not working now! for example, now I cannot use #include <QDebug>!
When I use this header file, Compiler say there are many errors(77 error) in this library! I got confused, it has been two days I am working on this and there is no progress.
I used "Custom Build Steps" and I set the path to ${sourceDir}. In addition I added lex.yy.c,y.tab.c in SOURCES and y.tab.h in HEADERS in .pro file.
I learned how to use flex and bison via here for the first time. and for those errors I read the followings:
Undefined Reference to yylex()
How to Integrate Flex and Bison
and some other links...
Qt programs are in C++, not C.
If you have not-too-ancient versions of flex and bison, you will have no problem compiling their generated code using C++, but you need to tell the compiler that they are to be compiled in C++. (Using a combination of C and C++ is certainly possible but it requires some care.)
Using gcc, it should be sufficient to make sure that the names of the files generated by bison and flex have a .cc extension instead of .c, which you can do using the -o command-line option. (That's highly recommended in any case because it lets you choose more meaningful filenames then y.tab.c and lex.yy.c.) That requires some adjustments to your Makefile. (You can also use the %output "filename" directive in bison and %option outfile="filename" in flex, but you'll still need to adjust the dependencies in your Makefile.)
Another, less recommended, option is to use the -x c++ command-line option to gcc.
Without more details about the toolset you are using on Windows, it is not easy to give more advice, particularly for me (since I have 0 experience in Windows toolsets). But the key is to ensure that both files are compiled as C++.
From the fact that you are trying to #include a Qt header, it seems like compiling the scanner and parser as C programs is not practical. But if I am misunderstanding your project and neither the scanner nor the parser require C++, then you can do so; you'll need to declare extern "C" int yylex(); in the C++ translation unit which calls yylex. (Don't put this declaration in the scanner.l file; it won't work if you're compiling with C.)
C++ setup of flex/bison is tricky. Check out this example project:
https://github.com/ezaquarii/bison-flex-cpp-example
It is a complete, working C++ Flex and Bison "interpreter", encapsulated in a class. In fact I used it few times with Qt 4.8.
I would like to extend my library, which currently compiles only using gcc, to be used by Solaris Studio as well.
My idea is to do the following:
Write wrapper functions in C, which expose the relevant parts of the interface with extern C linkage.
Then build this library using gcc. The resulting c-header and binary are compiler independent as there is no name mangling anymore.
Include the c-header and link into the project compiled with Solaris Studio.
Question: Is this a feasible approach or is there a better solution to this problem?
Note: Besides name mangling, also watch out for problems related to exception handling.
Your plan is correct.
As long as your library exposes a C API compatible with platform ABI (sizes and alignments of C types, calling conventions) and does not throw C++ exceptions you are not going to have troubles linking your library using other compilers or languages.
You could also add a C++ header only wrapper for your C API to make it easily reusable from C++ and exception safe.
Is it possible to compile Apache and its list of modules using a C++ compiler?
That would make addition of C++ modules easier too. Right now I am working on adding some C++ modules, but if Apache itself were compiled as a C++ binary, that would make life much easier.
C++ and C are interoperable. You may link C++ code with C code and vice versa (although C++ methods called from C must be declared extern "C" so as to not be mangled, and you lose the overloading which name mangling provides).
In fact, in the days when dinosaurs roamed the Earth, C++ compilers just emitted C and passed it down to a C compiler.
So, in a sense, you're already compiling Apache using a C++-compatible compiler (although its source is not C++): you shouldn't have any trouble at all writing a module as C++ and linking it in.