Thread: Can someone provide TIPS in order to convert C++ code into C code?

Originally Posted by rohit99

1. Ok.. I will convert classes into structs, but do structs in C contain functions? If yes, are functions declared and defined in struct body itself? Also, what to do if I want to declare func in struct but define outside it?

No. Structs can't contain functions.
Welcome to C.

2. How to replace operator overloading kind of thing? Will struct vars behave just like class objects?

User-defined functions that you call (explicitly), of course.
There are no "objects" in C. They will behave like variables. No more, no less.

3. How to replace object handling kinda stuff? E.g. If I have an object of a class as member of some other class in C++, will simply replacing two classes with two diff. structures suffice? And in that order, struct vars. of these 2 diff. classes will behave like objects behaved in C++?

Yes and no. Yes, it will work, but it might not work depending on what you do.
Overloaded operators will stop working, for example.
Private/public/protected will stop working.
Etc.

Originally Posted by rohit99

well, I was not too keen to convert C++ code into C code.. but my teacher says compiled C code is less in size compared to C++ code.. i dont knw if it's true.. i have read it depends on the compiler.. n generally it shouldn't be true but specifically it somehow comes out to be true..

n the code I wanna convert is cryptographic algo..

So what does it matter?

One more thing.. can you plz explain with example how C++ class function will be bound to a particular struct even when func is not declared or defined in it??

It isn't, it won't and it can't. Usually, a function would simply take a pointer to the actual struct.

Do you guys have more pieces of advice?

If possible, don't convert C++ code into C.

well, I was not too keen to convert C++ code into C code.. but my teacher says compiled C code is less in size compared to C++ code.. i dont knw if it's true.. i have read it depends on the compiler.. n generally it shouldn't be true but specifically it somehow comes out to be true..

Hand crafted assembly language code can result in even smaller executables compared to C code.

Doing everything in hardware results in executables of zero size, and in fact the AES algorithm was selected partly due to ease of implementation in hardware.

C++ could bloat the size of executables a bit, especially with templates. It depends on the code and the compiler.

> but my teacher says compiled C code is less in size compared to C++ code
If your C++ code is fairly simple (none of the inheritance / polymorphism / operator overloading etc) which has no good equivalent in C, then a simple mechanical translation of

foo::func ( var )
to
foo_func( &instanceOfFoo, var )

isn't going to save you a great deal, as it's what C++ does anyway.

One wonders what to say if your C answer ends up bigger than the C++. Does that prove or disprove the tutor's assertion?

It is my opinion that C++ and C code performing the same task, written in efficient code, will not be hugely different in performance and size.

It is perfectly possible to write inefficient and unnecessarily large code in both C and C++ - and I guess C++ can HIDE the complexity of a complicated piece of code - but in the end, someone who knows what he/she is doing should be able to produce good, efficient code in both languages, and unless you have good evidence that the code is inefficient, translating an encryption algorithm from C++ to C will just make your life hard, without much benefit.

The task of translating C++ to C when it's heavily relying on C++ functionality can be quite hard, as has been stated.

--
Mats

Originally Posted by SevenThunders

What might be interesting is to try to find an old compiler that converts C++ to C prior to compilation, which is how it used to be done. I think Objective C is still done this way by some compilers.
http://users.pandora.be/stes/compiler.html

You might be able to find something similar for C++.

Yes, you'd be looking for CFront - which is the "first" C++ compiler - it was a front end that basically pre-processed the C++ file into C.

However, there is absolutely no benefit in this, as it will just produce the same (or sligthly worse) binary as the corresponding native [1] C++ compiler. It would be slightly worse in cases where a native C++ compiler can do optimizations that are not visible once the code has been translated to C - for example knowing the type of an object and calling a virtual function without the vtable would not be possible in C, since that information has been lost.

Also, you probably can't expect CFront's output to be "nice and readable" C code (although I have never looked at it closely).

[1] Native here means a C++ compiler that takes C++ code and directly generates assembler/machine code.

--
Mats