Learning C when you already know C++

[jloftus576]

How hard is it to learn C if you already know C++? I'd like to get a feel for how difficult for me it would be to take on a project that mainly involves C programming when C++ is what I know best. Thanks and sorry if this is on the forum.

[mitakeet]

Since C++ is (nearly) a superset of C, presumably if you know all the capabilities of C++ you would know all those of C. However, most good C++ programmers stay far away from most of the common pitfals of C (C++ was designed to shore up those pitfals, doanchano), so they tend to not know the things that work in C but won't work in C++. IO is the most obvious, then is memory management. No contructors or destructors, though you can emulate it a bit with at_exit(). Generally speaking, it is best to use a C++ compiler to do C coding as most of the errors/warnings that C++ compilers output are high-probability bugs in C anyway. I coded in C for nearly a decade before switching over to C++ nearly full time, so I would hardly recommend going 'backwards' unless you have a real strong reason for it. A lot of things that are simple, trivial and safe in C++ are nightmarishly complex and buggy to reproduce in C.

[exterminator]

A bird with wings asking how to walk??

Go ahead...nothing is impossible and nothing is easy until you try. If you gotta do it ..do it..

It is fun...

[polus]

Since C++ is (nearly) a superset of C, presumably if you know all the capabilities of C++ you would know all those of C. However, most good C++ programmers stay far away from most of the common pitfals of C (C++ was designed to shore up those pitfals, doanchano), so they tend to not know the things that work in C but won't work in C++. IO is the most obvious, then is memory management. No contructors or destructors, though you can emulate it a bit with at_exit(). Generally speaking, it is best to use a C++ compiler to do C coding as most of the errors/warnings that C++ compilers output are high-probability bugs in C anyway. I coded in C for nearly a decade before switching over to C++ nearly full time, so I would hardly recommend going 'backwards' unless you have a real strong reason for it. A lot of things that are simple, trivial and safe in C++ are nightmarishly complex and buggy to reproduce in C.

What about embedded applications? Driver Development...etc?

[mitakeet]

While often compilers for embedded applications lack support for STL and possibly a couple of other constructs, it should be possible to build the exact same C application with a C++ compiler, same memory footprint, same size binary. Whether there is a decent C++ compiler for your particular embedded hardware is another story, though keep in mind the early C++ 'compilers' were nothing more than preprocessors that converted the C++ source to C source for use in a C compiler.

[mitakeet]

WRT driver development, there are often wrappers you can put around your C++ code to create a suitable interface for the OS (most OSs are still written in C, mostly due to legacy reasons), if not, you can still use the C++ compiler to write and debug your code, then use a suitable C compiler to create the finished binaries if necessary.

[jloftus576]

Most of the coding is for an embedded application. And C is what it is written in. That decision is not up to me.

Thanks for your input.

[CJ1]

In a nutshell C is all about pointers and memory management (IMHO), if you feel comfortable with pointers you are well on your way.

C is really one step above assembler (IMHO), the language syntax is simple and you already know/use it in C++.

For embedded applications you will be exploiting memory and pointers to access the hardware, so you may see something as ugly as

*((unsigned short *)0x1234) = myVar;

for memory mapped I/O.

Before you start I would suggest that you master pointers and pointer arithmetic.

Your greatest challenge may just be trying to understand the legacy code and that is true in any language.

[Skoons]

It` possible, but they are qute different and similar at once. I have problem that my c++ programs have c programming style, not long ago i begin to use all c++ capabilities, so some my programs in c++ have c style, but any way it`s working, and c++ style on c, will be working also but it will be very unfmiliar to c++ programmers, And you need to forget virtual functions and use function pointers instead. I recommend you Steven Parta book aon C. Good luck

[NMTop40]

When I programmed in C having used C++ extensively, I still designed my code with the mentality of objects. I found others did the same.

If you start off with an object-orientated design, you can then implement it in C. You can even encapsulate to a point - this can be done by keeping your type "incomplete" to the user. And C allows incomplete types to be passed to functions as pointers.

You will normally have Create and Destroy functions for each object thus:

CreateX( params ):

creates an X and returns an X*.

You then have

DestroyX( X* x );

To destruct the object. Of course you have to use malloc() and free() yourself, but don't force your users to call them. In some ways you are doing a "placement new" in that your "constructor" (your create function) allocates the memory then initialises it. (No initialiser lists, of course).

You can implement reference counting too if you really feel you want to. AddRefX( X* x ) for example and SubtractRefX (X * x) which can call DestroyX() if the reference count goes down to 0. You can also implement copy constructors with CopyX( const X* x );

If you want objects created on the stack rather than the heap, then you will need to use POD structs. Remember that there are no "destructors" called automatically when they go out of scope though. Perhaps you can give such structs a function (A function that takes a pointer to one) to release any internal resources.

You can achieve a certain amount of polymorphism by function-pointers (and callbacks).
You will have to do a lot more casting.
There are no exceptions. Instead you have to return error codes from functions that fail and keep checking for these error codes.

Continue using const - it is part of ANSI C too.

[CJ1]

Yes all true, in fact you can do object oriented programming in assembler if you want when you start with a clean slate.

In this case we are talking about working on existing C code for an embedded application which means working with an existing code base and probably limited resources.

The greates hurdle will always be to understand the existing code, and for that you will need some help, code comments (if any and if they are not out of date), code design document, calling trees, etc. and if you know the background of the original coders (so you can try to understand their coding style).

If you are any good in C++ (or any other language), learning C will be an easy task, learning and adapting to the existing code base will be your hardest task.