I need to write my 4-5 .cpp and .h file to c code. In C++ code we have defined a class, constructor, destructor, function.
How to convert them in C code?
Can somebody give me example of it so that i can implement it or provide link so that I can better explore it to my C code?
How to implement all the functionality i mean constructor,destructor,functions of class in C ?
convert all classes to data structures (typedefs)
replace constructors and destructors with functions that use malloc/calloc and free and return/take pointers to your typedef'd structures
eliminate polymorphism; if this is not possible then implement a message-dispatching function for each typedef (a big switch statement) and represent messages as constant integers
alter all functions to take a pointer to the appropriate typedef
Note that typedefs do not support subtyping, so all inheritance will have to be converted to composition.
There are a lot of considerations and things that need to change, but I think what you want to do is emulate object oriented code in C.
Basically for each of your classes you need to take out the functions and leave only the data members inside the class/struct (you will rename class to struct and remove public/private/protected specifiers).
Then you need to add a first parameter to each of those functions which is a pointer to the struct to operate on.
Nearly all typical OO C++ code is just snazzy syntax around the old technique of creating libraries that created a "cookie" and required it to be passed into every call. So if none of the classes have virtual methods (no runtime dispatch) you should be able to do the following:
Think of all class names as "facility" or "library" names.
Put all data members of the class into a struct named classname (what the class used to be named)
Turn all the methods into functions named classname_methodname.
Add a pointer to the classname struct to the parameter list of all the functions (methods) for that class.
Turn the constructors into a functions named classname_construct(# for overloads perhaps) and the destructor into a function named classname_destruct.
Change all the method calls in other code from objectname.methodname (...) to classname_methodname (objecname, ...).
This is the tricky part: You will have to put in code to call the destructors manually, since those are automagically called in C++.
Taking the example given in the comments:
class QtCommandData {
public:
QtCommandData(unsigned short net, unsigned short command,
unsigned long n_data_bytes, unsigned short flgs,
unsigned char* data = NULL);
QtCommandData();
~QtCommandData();
public:
unsigned char* m_pData;
int m_Async;
protected:
unsigned int m_nDataBytes;
unsigned int m_BytesAllocated;
protected:
int Fill_Trailer();
};
...becomes (I'll abbreviate the "facility name" from QtCommandData to QtCD):
typedef struct {
unsigned char* m_pData;
int m_Async;
unsigned int m_nDataBytes;
unsigned int m_BytesAllocated;
} QtCD;
QtCD_Construct(QtCD * handle,
unsigned short net, unsigned short command,
unsigned long n_data_bytes, unsigned short flgs,
unsigned char* data);
QtCD_Destruct(QtCD * handle);
QtCD_Fill_Trailer (QtCD * handle);
That's the general idea. Templates and dynamic dispatch and a few other things may throw you a monkeywrench or two, but I'm sure you are up to the challenge. :-)
For functions you also need to prevent the C++ compiler from name mangling if you want to link a C++ library to a C program, so you add blocks in your headers like
#ifdef __cplusplus
extern "C" {
#endif
/* Some functions here */
#ifdef __cplusplus
}
#endif
C does not directly support the OOP paradigm. Translating an OO design or code to C is a fairly simple mechanical process but not one that could not reasonably be fully covered here perhaps. There is at least one thread on the subject already: Can you write object-oriented code in C? with links to resources.
If your code uses the more complex C++ features such as generic programming, polymorphism and multiple inheritance, your work may be more difficult than it is worth. However C and C++ can interoperate fairly easy. Why would you not just provide a C wrapper around your C classes?
Related
I've always been a little confused about what's going on here:
#include <stdio.h>
int main() {
timeval tv;
tv.tv_sec = 1;
for (;;) {
select(0, 0, 0, 0, &tv);
printf("%s\n", "Hello World!");
}
}
Sorry if that doesn't compile, just wrote it as a quick example.
Code like this won't compile under gcc unless I add the keyword struct prior to the use of the struct timeval. g++ on the other hand handles it fine as is.
Is this a difference between how C and C++ handle structures or is it just a difference in the compilers? (I'm very C++ oriented, and the use of struct in C on lines like this has always somewhat baffled me).
Syntactically both treat struct almost the same. Only C++ has added an extra rule that allows to omit the struct (and class) keyword if there is no ambiguity.
If there is ambiguity, also C++ requires the struct keyword in some places. A notorious example is stat on POSIX systems where there is a struct stat and a function stat.
Consider the original idea of C++ (or, when it was just an idea, "C with classes"), that of an OO-oriented language that was compatible with C to the point where most valid C programs were also valid C++ programs.
C++ built its class model by starting with C's struct and adding some further functionality:
Inheritance (though you can come close in C with having the first member of a struct the struct you want to "inherit" from).
Information hiding (through public, private etc)
Member methods (which were originally turned by macros into C code outside the struct with an added this parameter - many implementations are still similar in practice).
At this point there were two problems. The first is that the default access had to be public, since C has no information hiding and therefore from a C++ perspective has everything public. For good OO one should default to private. This was solved by adding class which is pretty much identical to struct except for the default is private rather than public.
The other is that this OO perspective should have timeval or any other class/struct on the same "footing" as int or char, rather than constantly annotated in the code as special. This was solved by relaxing the rule that one must place struct (or class) before the name of the type in declaring a variable of that type. Hence struct timeval tv can become timeval tv.
This then influenced later C-syntax OO languages, like Java and C# to the point where, for example, only the shorter form (timeval tv) would be valid syntax in C#.
I would say it's a design decision of both languages.
Structs in C are just structured records and have different usage then built-in type.
C++ has ctors and operator overloads and so they act as types.
struct foo x; // create a structure of pattern foo
typedef foo foo_type; // "define" a type
foo_type x; // create an instance of type foo_type
C++:
foo x; // create an instance of type foo
As a side-note, struct foo is still allowed in C++. struct foo is easier to parse then typedef'dfoo as the name-lookup is simpler.
It's just how C looks like. Therefore, the following patterns is pretty common in C:
typedef struct YourStructure
{
int x;
// more fields
} YourStructure;
Then you can reference it the same way like in C++.
It's simply a difference in the languages. C++ is more permissive in its struct syntax.
The way C does it came first, of course. Structs and classes in C++ are nearly identical, and it would have been very inconvenient to require class with every class variable so it was simplified for both.
Essential COM, Don Box
Chapter 1, Abstract Bases as Binary Interfaces, Page 18
If you do not have a copy of this book, and are curious about Component Object Model (COM) scroll down to the bottom where I give some further background information.
The IFastString interface class is defined as
// ifaststring.h
class IFastString
{
public:
virtual void Delete() = 0;
virtual int Length() const = 0;
virtual int Find(const char*) const = 0;
};
extern "C"
IFastString* CreateIFastString(const char* psz);
The FastString class is defined as
// faststring.h
#include "ifaststring.h"
class FastString : public IFastString
{
private:
const int m_ch;
char *m_psz;
public:
FastString(const char *psz);
~FastString();
void Delete();
int Length() const;
int Find(const char *psz) const;
};
Finally, here is the implementation of FastString
// faststring.cpp
#include <string.h>
#include <faststring.h>
IFastString* CreateFastString(const char *psz)
{
return new FastString(psz);
}
FastString::FastString(const char *psz)
: m_ch(strlen(psz))
, m_psz(new char[m_ch + 1])
{
strcpy(m_psz, psz);
}
FastString::~FastString()
{
delete [] m_psz;
}
void FastString::Delete()
{
delete this;
}
int FastString::Length() const
{
return m_ch;
}
int FastString::Find(const char *psz) const
{
// find algorithm implementation goes here
}
When I first saw this code it appeared slightly "odd" to me. I am confused as to why the creation function is not defined in a similar way to the delete function.
It would seem to me there are two possible modifications to this code. As far as I can see, both of the following choices would work.
1: The creation function could be made a member function. (?)
I initially thought this would be possible however I now believe this cannot be done because C++ class member functions cannot be defined with extern "C" linkage.
Therefore the choice to define the creation function as a non-member is not completely arbitrary.
2: The deletion function could be made a non-member function. It would then more closely match with the creation function.
// h (interface)
extern "C" // is this needed?
void DeleteIFastString(IFastString *s);
// cpp
void DeleteIFastString(IFastString *s)
{
delete s;
}
// remove the virtual void Delete() function from both
// IFastString and FastString classes
The only reason I can think for this decision not being taken is that it polutes the global namespace with another non-member function. However on the other hand, having a syntactically similar "deleter" to your "creator" function is arguably desirable.
Is there any other reason why the deleter has been implemented as a member function?
Further Background Info (COM)
The purpose of the ideom in the above example is to solve two problems:
A dynamic library should be designed with a defined interface which does not change.
This is so that the implementation can be changed without requiring modification to client code. Someone can update the "FastString" dynamic library keeping the interfaces constant so that client code can link to a new version of the dynamic library without requiring changes to the client source.
A dynamic libary should be designed with an exposed object size which does not change.
This is so that a changed dynamic library can be shipped to a client and the compiled client code can load the dynamic library code, and functions will access data at the correct offset.
Consider the following: If member variables of an interface class are changed, then the offsets or locations of where those data are stored in memory will change. If an interface class is exposed to client code, then different compiled versions of that interface class will be binary incompatiable.
If the client code is compiled with a different compiler to the compiler used to compile the dynamic libary code, then the dynamic libary should be loadable at runtime by the client and work as expected.
The reason this may not happen is if the compilers used compile code in an incompatiable way. For example, virtual functions have multiple possible implementations, as the C++ standard does not define how polymorphism and virtual functions should be implemented. Different compilers may produce different binary codes which are incompatiable.
Don Box describes this in more precision than I have here over the course of several pages. Hopefully I presented enough information for this to be understandable.
COM solves the above three issues by defining an interface class with no member variables, along with an implementation class the data members and functions of which are completely inaccessible to client code. In addition to this, all functions which touch member data of the implementation class are compiled with the same compiler. (The compiler used to compile the dynamic library.) This means that the functions and data are compiled by the same compiler and are thus binary compatiable. Finally, user accessible functions are defined with external C linkage so that they are compatiable and can be linked with client code compiled with a different compiler.
It is worth noting that the above assumes the archetecture is the same. For example, COM does not solve the problem of x86 code being incompatiable with ARM systems. (Probably obvious but worth mentioning to avoid confusion.)
COM doesn't expose C++ class constructors or static class member functions for instance creation. The COM function is CoCreateInstance, but that's not the only possibility.
Some COM interfaces are constructed via a method on IClassFactory, but you'll still need a mechanism to acquire an IClassFactory (CoGetClassObject)
COM doesn't use a Delete method, the relevant member function is Release. All COM interfaces inherit from IUnknown.
It's the responsibility of the object exposing the interface to know how to dispose of itself if all references to it are released.
You could be running code that accesses different implementations of the same interface on different objects that have different sizes,
and are implemented in different DLLs. Which static function would you call to delete it? It's not your problem.
That's the point of going through interfaces - you don't care what the implementation is.
It's possible to construct COM interfaces in languages other than C++, and the caller wouldn't know.
The point #2 above is irrelevant; the size of the object doesn't matter to the caller. COM exposes interfaces, not objects. What matters is the binary layout of the interface, which is (in practice) defined as "What the MS compiler does with this C++ definition".
gcc 4.4.4 c89
I was just reading a discussion at DevX about calling C++ code from C since I have to do something similar. I am just wondering what user Vijayan meant by "make sure that non POD types in C++ are opaque to C clients."
Many thanks for any suggestions,
C can only deal with POD types.
Consequently, you cannot pass objects of non-POD types to C programs (by value). Also, if you pass pointers of non-POD types to C programs, they can't interact with the objects pointed to.
POD = Plain old data structure = C structs, no virtual methods, etc. You need to write wrapper functions for C to access non-POD types (i.e., classes).
More on POD:
http://en.wikipedia.org/wiki/Plain_old_data_structure
For a type to be opaque means you can't look inside it: it's a "black box" that can be passed around but not inspected or manipulated directly by the C code. You typically refer to the object using either heap-allocated memory and void*s, or using functions to determine the necessary length and buffers.
For example, a C++ object might contain a std::string, but the layout of a std::string is not specified in the C++ Standard, so you can't write C code that directly reads from or writes to the string (at least, not without having a total understanding of the std::string layout, manually revalidated every time the compiler/STL is updated).
So, to allow C code to access the object, you might write C-callable functions such as:
#if __cplusplus
extern "C" {
#endif
void* object_new();
const char* object_get_string(void* p_object);
void object_set_string(void* p_object, const char* s);
void object_delete();
#if _cplusplus
}
#endif
With C++ implementation ala:
class Object { std::string string_; ... }
void* object_new() { return new Object; }
const char* object_get_string(void* p) { return ((Object*)p)->string_.c_str()); }
...
Here, the object_XXX functions provide the C code with a safe way to use the Object.
Making the type opaque means, as per the line in the link:
typedef struct base base ; /* opaque */
makes the name of the handle available to C code, but not the definition of the type. This means that the C code cannot access any members directly, but has to go through the interface functions.
Note that you do not have to make a cast to a generic , i.e. void*, pointer, although doing so is one option, as per 9dan's answer.
Note that such a style of interface is in my experience a very nice way to manage encapsulation even in pure C code, just as in the standard C streams library.
Making opaque to clients means nothing special. C stream file I/O (FILE* f = fopen) API is the typical example that present opaque handle to clients.
Apparently C can not handle non-POD type so you must hide C++ implementation from C clients but provide access method.
Example:
C++ Implementation
class MyLibrary {
MyLibrary();
~MyLibrary();
int DoSomething();
...
}
Declaration for C clients
typedef void* OPAQUEHANDLE;
extern OPAQUEHANDLE MyLibrary_OpenLibrary();
extern void MyLibrary_CloseLibrary(OPAQUEHANDLE h);
extern int MyLibrary_DoSometing(OPAQUEHANDLE h);
Implementation for C clients (in .cpp file)
extern OPAQUEHANDLE MyLibrary_OpenLibrary()
{
return new MyLibrary;
}
extern void MyLibrary_CloseLibrary(OPAQUEHANDLE h)
{
delete (MyLibrary*) h;
}
extern int MyLibrary_DoSometing(OPAQUEHANDLE h)
{
return ((MyLibrary*)h)->DoSomething();
}
So it's been a while since I've used straight C. And I'm on a project where I'm working on an API in C++. Most of these methods are just C anyway, and all of the return values are C structures. Except one. One method I need to return a vector<string>. Now here's my question. Is C++ methods/libraries/whatever callable from C? I ask because I don't know if the people using the API are going to be writing in C or C++, and I feel like I should be returning only C structures. That would require me to return a char**, right?
I hope that made sense, if not:
tl;dr version - Can I call a C++ method from C if it returns a C structure, and if so is the best (only?) equivalent return value of vector<string> -> char**?
Update: The C++ methods are simply global methods. There's no classes or object oriented stuff in them. The ONLY thing that's specific to C++ other than my vector question is a few stringstreams
No, C cannot use C++ features that are not also available in C. However, C code can make use of C++ code indirectly. For example, you can implement a C function using C++, and you can use opaque types in the interface so that the signature uses void*, but the implementation uses a C++ class.
The equivalent of vector<string> in C is probably closer to:
typedef const char* c_string_type;
typedef struct c_string_array {
c_string_type* c_strings;
int c_strings_count;
} c_string_array_t;
With opaque types, you would have something along the lines of:
typedef void* c_string_array_t;
int c_string_array_length(c_string_array_t array);
const char* c_string_array_get(c_string_array_t array, int index);
You could then secretly (in the C++ implementation) cast std::vector* to void*.
You can technically call anything from C, as long as a C-visible function name is given (prototypes etc. are ignored at the ABI level). Of course you can't expect correct results if C isn't able to generate the parameters in the expected fashion. Generally the obvious solution is to simplify the interface down to the C level. char ** is an excellent choice for greatest common denominator with a vector<string>. Not only that, if you know what you intend to do with it, quite possibly faster (and cleaner IMHO).
With respect to the C visibility: The function name cannot be shared with any other C visible functions. If you wish your C++ function to be callable from C, this might be a good example of the prototype:
extern "C" char **lots_of_strings();
If the parameter signature differs, C++ will let you overload with functions visible only from C++, and allow them to coexist with the C version:
vector<string> lots_of_strings(int);
extern "C" char **lots_of_strings();
If you wanted to provide several ways to call it, appropriate for the calling language, you might try this (ignoring the evils of late initialization, and the fact that bool exists in C):
bool lots_of_strings(vector<string> &);
extern "C" int lots_of_strings(char ***);
Whatever lots_of_strings(SomeArrayType &);
Keeping in mind that in every case, C++ will choose the definition with the best matching signature to the call site, and C will take whatever it can (which is always a single function with a matching name).
You'll find it useful to hide C++isms from C by combining #ifdef with the macro __cplusplus.
See this FAQ. Basically, you can't call C++ methods (member functions), but you can call free-standing functions if they're declared with extern C. char ** is not the only possibility, but it's probably the most straight-forward. You can return a dynamically allocated array of char *. You will have to use an out parameter to provide the length to the caller (you could NULL-terminate it, but that's probably not ideal). E.g.
char **get_string_list(size_t *len)
{
char **array;
size_t actual_len;
// ...
*len = actual_len;
array = (char **) malloc(sizeof(char *) * actual_len);
// ...
return array;
}
You must somehow free the memory. Either provide a function or document how the caller should do it. Don't forget to free the individual strings if they're dynamically allocated.
I read some lines about this some time ago, and iirc you can use c++ code/structures that would compile in C. But there is some thing about static initialisation, if i understood correct, you should write your main function in c++ to guarantee that this s.i. is done, C main does not do.
If you intend to offer the same functionality to both C and C++ I would try to offer two entry points so that you can adapt one to the other. Note that while you can settle for an interface that can be used both from C and C++, in most cases the C interface will not be ideal for C++ usage (using char** might be a good solution for C, but having users convert that back to C++ types and performing cleanup can clutter user code) and vice versa.
If you have the possibility to modify the code that you're calling I would suggest changing the function from returning an vector to something like:
unsigned int MyFunction(char* buff, unsigned int numLines, unsigned int stride)
Where numLines is the amount of allocated strings and stride is the size of the strings. That way your function doesn't need to allocate any memory that you need to worry about later. It's all handled by the caller. The return value of the function is the amount of strings that was used.
I read that early C++ "compilers" actually translated the C++ code to C and used a C compiler on the backend, and that made me wonder. I've got enough technical knowledge to wrap my head around most of how that would work, but I can't figure out how to do class inheritance without having language support for it.
Specifically, how do you define a class with a few fields, then a bunch of subclasses that inherit from it and each add their own new fields, and be able to pass them around interchangeably as function arguments? And especially how can you do it when C++ allows you to allocate objects on the stack, so you might not even have pointers to hide behind?
NOTE: The first couple answers I got were about polymorphism. I know all about polymorphism and virtual methods. I've even given a conference presentation once about the low-level details of how the virtual method table in Delphi works. What I'm wondering about is class inheritance and fields, not polymorphism.
In C anyway you an do it the way cfront used to do it in the early days of C++ when the C++ code was translated into C. But you need to be quite disciplined and do all the grunt work manually.
Your 'classes' have to be initialized using a function that performs the constructor's work. this will include initializing a pointer to a table of polymorphic function pointers for the virtual functions. Virtual function calls have to be made through the vtbl function pointer (which will point to a structure of function pointers - one for each virtual function).
The virtual function structure for each derived calss needs to be a super-set of the one for the base class.
Some of the mechanics of this might be hidden/aided using macros.
Miro Samek's first edition of "Practical Statecharts in C/C++" has an Appendix A - "C+ - Object Oriented Programming in C" that has such macros. It looks like this was dropped from the second edition. Probably because it's more trouble than it's worth. Just use C++ if you want to do this...
You should also read Lippman's "Inside the C++ Object Model" which goes into gory details about how C++ works behind the scenes, often with snippets of how things might work in C.
I think I see what you're after. Maybe.
How can something like this work:
typedef
struct foo {
int a;
} foo;
void doSomething( foo f); // note: f is passed by value
typedef
struct bar {
foo base;
int b;
} bar;
int main() {
bar b = { { 1 }, 2};
doSomething( b); // how can the compiler know to 'slice' b
// down to a foo?
return 0;
}
Well you can't do that as simply as that without language support - you'd need to do some things manually (that's what it means to not have language support):
doSomething( b.base); // this works
Basically, structs-within-structs.
struct Base {
int blah;
};
struct Derived {
struct Base __base;
int foo;
};
When you want to, say, cast a Derived * to Base *, you'd actually return a pointer to the __base element of the Derived struct, which in this case is the first thing in the struct so the pointers should be the same (wouldn't be the case for multiple-inherited classes though).
If you want to access blah in this case, you would do something like derived.__base.blah.
Virtual functions are normally done with a special table of function pointers that is part of each object, a rudimentary sort of "what is my type" record.
Here is how COM does it for C language. I am a bit rusty at this , but the essence works like this. Each "class" member variables is just a struct.
struct Shape
{
int value;
};
struct Square
{
struct Shape shape; // make sure this is on top, if not KABOOM
int someothervalue;
};
all the methods, are actually just normal functions. like this
void Draw(Shape * shape,int x,int y)
{
shape->value=10; // this should work even if you put in a square. i think...
}
then, they use the preprocessor to "trick" the C code into displaying something like this.
Square * square;
square->Draw(0,0); // this doesnt make sense, the preprocessor changes it to Draw(square,0,0);
Alas, i dont know what kind of preprocessor tricks are done to make the C++ looking function call resolve into a plan vanilla C call.
DirectX COM objects are declared this way.
Dr. Dobb's had a moderately detailed article on this topic, Single Inheritance Classes in C.
Structs-within-structs is common, but it makes it a pain to access inherited fields. You either need to use indirection (e.g. child->parent.field), or casting (((PARENT *) child)->field).
An alternative I have seen is more like this:
#define COUNTRY_FIELDS \
char *name; \
int population;
typedef struct COUNTRY
{
COUNTRY_FIELDS
} COUNTRY;
#define PRINCIPALITY_FIELDS \
COUNTRY_FIELDS \
char *prince;
typedef struct PRINCIPALITY
{
PRINCIPALITY_FIELDS
} PRINCIPALITY;
This gives types with direct access to inherited fields. The resulting objects can still be safely cast to the parent type, because the parent's fields and the inherited fields start at the same place.
The syntax can be improved a little with macros. I saw this in the older POV-Ray source (but I think they've since converted to C++).
If you want a good reference on how this stuff works take a look at the glib/gdk/gtk open source libraries. They have pretty good documentation and the entire framework is based on C OO.
You can simulate an object by writing constructors, setters, getters, and destructors with the hidden this pointer called out explicitly.
Inheritance is handled by having the derived object include a pointer to the base object in the structure of the derived object.