I have successfully extended my python code in C following this:
Call a Python function from within a C program
I have compiled the code and created a .dll. However, when I opened it with the dependencywalker I have seen that it still requires the python code. I want the dll to be standalone, so it doesn't depend on the script .py. I thought that using the tag -static in g++ would be enough but it doesn't work for me.
The Python documentation has a chapter on Extending and Embedding Python with C.
With good enough coding conventions this can by applied to C++ code. You will use extern "C" to declare functions coded in C++ callable from C.
Be careful to avoid throwing a C++ exception to Python code.
On Linux, see also dlopen(3) and dlsym(3) and the C++ dlopen mini howto.
Python is open source. You should consider downloading its C source code and studying it.
Be aware of the GIL in Python. Multi-threading C++ code will be tricky.
Consider also generating C or C++ code with tools like RefPerSys or ANTLR, or writing in Python your C or C++ code generator.
Perhaps use static source code analyzers (like Frama-C or Bismon) on your C source code.
Be aware that C and C++ are different programming languages. See this and n1570 and n3337 or better.
PS. For Bismon or RefPerSys please contact me by email to basile#starynkevitch.net and basile.starynkevitch#cea.fr, but mention the URL of your question here in your email.
Related
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++).
So I'm having the following problem:
I have an MEMS board that runs on FreeRTOS and includes gyro, accelerometer and magnetometer.
I cannot change any existing code (All in C).
Now I have a basic motion detection library written in C++ and I extended this library with some functions (All in C++).
I thought I can just use a C++ compiler and compile everything but I'm getting hundreds of errors.
I found some solution how to use C functions inside C++ but I don't know how to use C++ functions (or libraries) inside C.
Is there a feasible way? Can I somehow wrap all my C++ code in an easy way?
I'm using Keil uvision to compile the code for my embedded system in case that is important.
There are a few differences between C and C++ that may make a compiler stumble over some of the code. See for example the wikipedia page on this topic.
I'd suggest that you split your project into two projects, one being the RTOS and application in C, the other being the motion detection library. Then you have to write a C wrapper around your C++ library API. Here's a good SO post on writing a C wrapper for C++ code.
Then you would have to link your RTOS + application project to your library, which you compiled in your other uVision project.
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).
Context -- Trying to use Boost.Python set of C++ libraries to interface with C++ code.
Main idea is to test C++ code (.so files) by using them like python from a QA point of view.
Questions now;
BOOST_PYTHON_MODULE wrapper, do we really need to include in every .cpp to be interfaced from Python? Say we have test.cpp, can't we have Boost wrapper written test_qa.cpp so that actual dev code is not changed in the process?
Looked Boost.org site to get more clarity, what is the difference between Boost.Build and Boost.Python?
From the Boost Build documentation:
Boost.Build is an easy way to build C++ projects, everywhere.
From the Boost Python documentation:
... a C++ library which enables seamless interoperability between C++ and the Python programming language
I would say the difference between these two parts of Boost should be pretty obvious.
Can APIs written in C or C++ always be made into a library, given source code, and consequently be called from Python, due to the intrinsic callable nature of an API?
In other words, given a C/C++ API can you run a setup.py script using distutils on the source and effectively use the C/C++ API from python programs?
It's a bit more involved than running a setup.py script, but there are tools to wrap C/C++ libraries so you can use them from Python. Some popular ones are:
Cython - you write Python-style code, but you can cimport C libraries and call their functions. Cython code is then translated to C and compiled. There's an unsupported tool called cython-codegen to automate writing a simple wrapper.
boost.python - For wrapping C++ libraries.
SWIG
ctypes - Load compiled libraries and call them directly from Python. ctypesgen tries to automatically write a wrapper based on header files.
Certain projects use other tools to generate Python bindings, and they could probably be reused (with varying amounts of effort). PyQt4 uses SIP, PySide (another Qt binding) has shiboken, and GTK et al. have Gobject introspection.
It's not exactly that simple, but basically you can do that using SWIG, which will generate the necessary wrappers to bind your python and C/C++ code. http://www.swig.org/Doc1.3/Python.html
There is no intrinsic or automated mechanism for binding a C++ API to Python. It must be done manually. The best tool I've seen for this purpose is Boost Python.
Of course, given the clean mapping between C++ Object Oriented programming and Python OO code, it shouldn't be too difficult to create a script which parses C++ headers and produces the binding declarations. GCC-XML will give you an xml representation of parsed headers, which can be easily queried by a python script to produce the bindings. That said, there's probably a great deal of detail I've not anticipated which could prevent this approach from working.