I am using CppUTest in eclipse-cdt(ubuntu 14.0).
For inherits of C function in CppUTest I should write,
extern "C" {
}
Is any alternative to inherit all C project into Cpp for CppUTest ?
What is the disadvantages of extern in CppUTest?
Well, one "alternative" is of course to move the extern "C" declarations into your C-project's headers, protected by #if defined __cplusplus of course. That will, however, mean that you have to go through the entire project and fix it. It sounds as if just doing the above in your test code, which is where you're using C++, would be easier.
Many people do that, as a way to make their C code usable from C++. Personally I think it's a bit "dirty", since you're mixing languages ("don't cross the streams!"), but it's still very common.
See this question for lots of discussion about this.
Related
I know I can include C methods inside a C++ project using the extern "C" thing. But lets us now suppose that I'm thinking in creating a C++ project that would use quite a lot of C methods coming from both libraries made by me as well as libraries made by other people/companies whose developing details and compilation specifications I'm simply not aware of.
Is it possible that some of this methods of C libraries, with unknown compilation and configuration details, could not be included in my C++ project with extern "C"? Or are all C methods necessarily 100% compatible with C++ code insofar extern "C" is used?
It's possible that some of the functions exported by C use names that collide with C++ keywords. You wouldn't be able to declare those using extern "C".
Functions exported by assembler could even use names that conflict with C keywords.
Those and functions declared static can still be called via function pointer, as long as the library gives you a way to get one.
Headers might not be parse-able in C++ mode for the same reasons -- things like the restrict keyword.
Other than naming issues, C++ has full support for the C calling convention. That's what extern "C" is all about.
C has constructs for interfaces that are not compatible with C++, in particular variable length arrays. In modern C you would write
void matMult(size_t n, size_t k, size_t m, double A[n][k], double B[k][m], double C[n][m]);
this interface can not be included as such in C++ compilation units.
Although rather unlikely, one possible issue that might arise with extern "C" in-place is when a function pointer declared extern "C" points to a C++ function that is not declared extern "C". See the last part of this page for more details.
I would like to be able to use C/C++ functions from python using ctypes python module.
I have a function int doit() in the .c / .cpp file. When I try to load the shared library:
Frr=CDLL("/path/FoCpy2/libFrr.so")
Frr.doit(c_int(5))
i find it working really well when the .c variant is used. When C++ is called the good way to call this function is (found out using nm libFrr.so using nm -gC libFrr.so produces just plain doit()):
Frr._Z4doitv(c_int(5))
I have read on Stackexchange that there is no standard way to call C++ from python, and there is "nonstandard name mangling" issue. Is the "Z4" a part of that issue? I guess the nonstandard name mangling would appear for more advanced language features such as class methods, templates, but also for such basic functions? Is it possible to force using simple C function names in simple cases for the C++ code?
You can use extern "C" to make the functions "look like" C functions to the outside world (i.e., disable name-mangling). And yes, you are correct, name-mangling is needed mostly for the more complicated features and types of functions that C++ has, and the name-mangling scheme has never been standardized (nor the binary compatibility) and so it varies from compiler to compiler and between versions (but most main-stream compilers have settled to something permanent now, but still different between compiler-vendors). And the reason that mangling is also required for plain old free functions is because C++ supports overloading (same function names but with different parameters), and thus, the compilers will encode the parameter specification (e.g., types) into the mangled names. Of course, if you use extern "C" you lose all features for which name-mangling is needed, so, it more or less boils down to C functions only.
You can use extern "C" either on a per-function basis, like so:
extern "C" int doit();
Or for the overall header:
extern "C" {
// all the function declarations here ...
};
However, for Python specifically, I highly recommend that you use a library that allows you to construct Python classes and functions that are a reflection of your C++ classes and functions, that makes life a lot easier and hides away all this extern "C" business. I recommend using Boost.Python, see this getting started page, it makes exporting functions and classes to Python a breeze. I guess others would also recommend SWIG, but I have never used it.
Calling c++ library functions is always a mess, actually even if you're using C++ you have to use the same compiler, etc. to make sure it works.
The only general solution is to define your c++ functions as extern "C" and make sure you follow the involved limitations - see here for an explanation of it.
Can I have a project that has some parts written in c and other parts written in c++ ?
Is this possible ?
Yes.
If you have control of the C code, then inside your C header files you should have:
#ifdef __cplusplus
extern "C" {
#endif
// normal header stuff here
#ifdef __cplusplus
};
#endif
That way they can be properly interpreted when included by both C and CPP code files.
If you include C code in your C++ via a header, and it doesn't include the code above, and you don't have enough control of it to make the necessary modifications, be sure to use e.g.
extern "C" {
#include "some_c_header.h"
};
Note that you can use this as a modifier for declarations too, e.g.:
extern "C" void someFunction();
Note that C++ has this mechanism for importing C functionality. C doesn't have one for importing C++, and trying to include C++ code in a C compilation unit will pretty quickly end in a bunch of error messages. One consequence of this is that your main function will need to be C++.
You need a compiler that can compile both languages (I have not heard of a C++ compiler that cannot do that), or compile them with a fitting compiler each and link them (in which case the answer of #sje397 applies). There is a good explanation on the subject in the C++ FAQ Lite.
How to mix C and C++:
http://www.parashift.com/c++-faq-lite/mixing-c-and-cpp.html
Yes it is very much possible. In fact usually legacy systems refactored later on usually have legacy code which is C as the core but with C++ wrappers on top of it.
Yes you can. C++ is mainly a superset of C. There might be some exceptions, but for the most part it is quite normal to include stuff written in C in your C++ projects.
Yes, you can have a project with both C and C++ code.
I did used snippet found from Internet for this kind of linking, and it works. Now I would like to gain more understanding on this topic, i.e. what should I pay attention to if my C++ code is going to be export/linked by non-C++ code. Could somebody points me to any resources useful for this? Thanks.
The key concepts in native code interoperability are name mangling, and calling conventions.
But the real point here is that in general, if you want your code to be callable from other languages (you don't specify any in your question), you have to adopt a lowest-common-denominator approach. Usually that means avoiding objects and thinking functionally, wrapping your code in DLLs and using a C-style interface. You'll probably have to define your DLL's api functions using the STDCALL calling convention.
Also, if you use structures in your interface, you have to worry about structure packing. To get proper interop with Delphi using packed records, for instance, I think you'd have to set the struct member alignment to 1 byte in your C compiler.
use extern "C" functionality... see here. This allows interfacing at the "C" level which is probably much more "cross-platform/language".
This should pretty much explain it all: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++
Also.... In conjunction with Bob Moore's answer...you can prevent name mangling by using #ifdef
#ifdef __cplusplus
extern "C" {
#endif
/* function prototypes and global variable declarations */
#ifdef __cplusplus
}
#endif
That __cplusplus directive, found in <stddef.h> is defined as standard to the best of my knowledge...
Hope this helps,
Best regards,
Tom.
I have a C++ library that provides various classes for managing data. I have the source code for the library.
I want to extend the C++ API to support C function calls so that the library can be used with C code and C++ code at the same time.
I'm using GNU tool chain (gcc, glibc, etc), so language and architecture support are not an issue.
Are there any reasons why this is technically not possible?
Are there any gotcha's that I need to watch out for?
Are there resources, example code and/or documentation available regarding this?
Some other things that I have found out:
Use the following to wrap your C++ headers that need to be used by C code.
#ifdef __cplusplus
extern "C" {
#endif
//
// Code goes here ...
//
#ifdef __cplusplus
} // extern "C"
#endif
Keep "real" C++ interfaces in separate header files that are not included by C. Think PIMPL principle here. Using #ifndef __cplusplus #error stuff helps here to detect any craziness.
Careful of C++ identifiers as names in C code
Enums varying in size between C and C++ compilers. Probably not an issue if you're using GNU tool chain, but still, be careful.
For structs follow the following form so that C does not get confused.
typedef struct X { ... } X
Then use pointers for passing around C++ objects, they just have to be declared in C as struct X where X is the C++ object.
All of this is courtesy of a friend who's a wizard at C++.
Yes, this is certainly possible. You will need to write an interface layer in C++ that declares functions with extern "C":
extern "C" int foo(char *bar)
{
return realFoo(std::string(bar));
}
Then, you will call foo() from your C module, which will pass the call on to the realFoo() function which is implemented in C++.
If you need to expose a full C++ class with data members and methods, then you may need to do more work than this simple function example.
C++ FAQ Lite: "How to mix C and C++ code".
Some gotchas are described in answers to these questions:
[32.8] How can I pass an object of a C++ class to/from a C function?
[32.9] Can my C function directly access data in an object of a C++ class?
Main gotcha: exceptions can not be caught in C. If there is the possibility of an exception rising in the C++ code, either write your C code or your C++ wrappers very carefully. Conversely, exception like mechanisms (i.e., longjump) in the C code (as found in various scripting languages) are not required to invoke destructors for C++ objects on the stack.
you can mix C/C++ code. If your main() function in in C++, then you just need to make sure your c functions are declared
extern "C"
If your main is C, then you are probably OK except for static variables. Any constructors with your static variables are supposed to be called before main() start. This won't happen if C is your main. I you have a lot of static variables, the best thing to do is to replace static variables with singletons.