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.
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++).
This might be a stupid question, but I'm not 100% sure and can't find a good answer via googling, so I thought I should ask it.
I'm building a few C libraries on a new compiler that will be linked with C++ code. I'm compiling the libraries from scratch because I'm moving up compiler versions from gcc4.x to gcc5.x, which requires me to recompile all of my C++ libraries with -std=gnu++14 (the language standard I'm targeting). My question is, do I need to add -std=gnu++14 to my CFLAG values when compiling to C libraries? I don't think I do, but want to confirm that I won't run into major issues down the road.
Thanks.
No. When you are compiling C code with a C compiler, you can specify the version of the C language you are using, but you cannot specify the C++ language version. It would not make sense to specify a C++ language version because there is no sensible effect that such a setting could have.
Since C++ compiler will mangle symbol names, you'll want to surround C code with a extern C { block. The common idiom is like so.
#ifdef __cplusplus
extern "C" {
#endif
/* My C symbols, functions, etc */
#ifdef __cplusplus
}
#endif
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).
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.