C: Good Habits re: Transitioning to C++

Question

I\'ve been learning C at Varsity for just shy of 2months now, and next year we\'ll be moving on to C++.

Are there any habits I should get into with my C programmin

Answer 1

My guess is that the C++ you will be learning is probably not going to be overly object oriented, at least it wasn't in my university anyway. We ran C++ programs essentially as C programs.

Definitely read up on how classes can be implemented, along with understanding the basics of pointers.

Your file I/O handling will be different as well...instead of fstream read up on the syntax of implementing the iostream functions.

Scour the web for tutorials on simple C++ programs...CodeProject is always a good resource.

Answer 2

There are already a lot of good answers. Mine will be more "mindset oriented".

Data vs. Action!

• In C, everything is done to think like "Apply this effect to this data".
• In C++, this is more like "Data should behave".

While the "Data should behave" can be done in C (and it is done!), in C++, everything needed to implement this easily is already accessible : Encapsulation, constructors, overloading overriding, templates, etc..

I found this "Data should behave" idea a very good guiding principle when coding in C++.

C++ syntactic sugar is not optional

You'll find a lot of C++ features that could be done in C, and some people use it as an excuse to not learn them. This mindset is dangerous (this is the part "treat C++ as a new language, and not an extension" seen in some posts).

A side effect of avoiding writing C++ the C++ way is that while a C++ developer is supposed to understand C++ code, he/she is not supposed to understand your little personal framework mimicking C++ sugar with C-only features. In fact, he/she won't be interested by your framework. Truth to be said, he/she will only feel pity/contempt for you because you lost precious time producing that. Ultimately, he/she will hate you if he/she must use your framework instead of the C++ sugar.

Guiding principles like "I can do this the C way" will just make you miss the wagon. Better not to start learning C++ at all if you already have this kind of C-centric mode of thinking.

Your language of choice is never the best. YOU are supposed to become the best. If you write C++ code, then write it the C++ way.

C-compatible C++ code is a semantic error

Typedefing your structs to make them compilable by a C compiler is a bad joke. Using pointers instead of references is a slap to your future self. The extern "C" will only make your code weaker, not stronger. And using void * for genericity will only increase the number of fellow C++ coders who will gladly pay to have your head removed in a spectacularly painful way.

Don't ever bother to write C-compatible code unless you really really really have to.

You'll just weight yourself down with a time-consuming coding style for a feature you'll never use.

The compiler is a powerful friend/enemy

Working low level has strange effects on some developers. They believe a lot on their control of the compiled code. Delegating this control to higher-level constructs is difficult for them.

A good example of that is ditching the constructor/destructor pattern because "sometimes, constructors takes too much time... Better to do it my way...".

The C++ compiler is quite able to optimize apparently unoptimized code. In fact, the code produced by the compiler can be quite different from the one you believe you produced.

Don't try to be better/smarter than the compiler is because:

1. You probably already lost the fight, as even old compilers will usually produce better code than you can dream to do today
2. Even if you did win the fight today, it will automatically turn into a defeat tomorrow, as compilers will become better and better in the future, so your "optimized code" of today will become the program bottleneck and refactoring subject of the next years (not mentioning shameful memories for you).

So, trust your compiler.

Don't micromanage the production of your code. Do your own work, and let the compiler do its own.

Note that this point should not be used to justify production of slow/inefficient code. If premature optimization is the root of all evil, you must still use your knowledge of the language and the compiler to produce good and efficient code (see the next point).

Know the advantages/drowbacks/costs of each C++ construct

For example, the fact virtual methods adds one indirection to the function call means for some people that performance will decrease dramatically. Truth is, performance problems are often elsewhere.

Ignorance is no excuse.

Know the code produced for each C++ construct (i.e. inlining, references, constructor, destructor, exception, function overload, function override, template, virtual function, etc.). Know what will be optimized away, and what won't.

This way, not only you won't pay for what you don't need (this is a guiding principle of C++), but you will also profit from what costs you zero but brings you a lot.

Be humble

There are people doing research in C++ that were better at C++ the day of their birth than most of us will ever be. Even if we ignore Stroustrup, names like Meyers, Abrahams, Alexandrescu, Sutter, etc. regularly crop up alongside new ideas. Despite (or as a consequence of) its alien outlook, STL is revolutionary library. And a library like Boost, despite its "small size" when compared to some complete frameworks (like Java or .NET APIs), is a massive repository of excellent code offered to you to study.

Just because you find some new feature "strange" or "alien", don't underestimate it. Trying to understand it will PERHAPS bring you another tool at your disposal, and will ALWAYS increase your mastery of the language, and will ALWAYS make your brain work, which is a good thing in the dev business.

Most people I know who failed their "conversion to C++" just assumed this or this feature was useless because they did not bother to understand it.

RAII !!!!

If you don't know what it is, learn it.

Without RAII, your C++ code is just bugged code that avoided compilation error.

RAII is the single most important notion of C++.

Everything else is related.

Answer 3

Funny how many people here claim that C and C++ are "completely different", and how "C++ is object oriented, C is not"...

First off: C++ was initially designed as an extension of the C language. Actually, the C++ standard documentation refers to the C standard. It is true that many things are done different in C++ than in C, but to claim that the two are completely disjunct goes a bit far. Good C code can be compiled with a C++ compiler, and for some trivial problems, C and C++ solutions can look next to identical.

Second, don't let yourself be fooled into believing that C++ is "an object-oriented language". C++ is a language that supports object orientation, true. But it also supports generic programming, and procedural programming. Focussing only on the OOP aspect of C++ takes away much of its power.

As for habits to get into... don't become too attached to C-style strings (char *) and arrays (int foo[]). Both are very rarely used in C++, as there are the much more powerful (and convenient) replacements, string and vector.

Pay close attention to pointers, and dynamic memory allocations. While good C++ code has very little of them, you have to be aware of how they work. While doing so, you will also realize why good C++ code encapsules them, or replaces them with references, so they don't appear much in production-quality code.

When designing your C code, start with a struct holding relevant data (e.g. fields of an address), and then construct functions working on that type of struct (address_read( struct address_t * ), address_write( struct address_t * ), address_modify_name( struct address_t *, char * ) etc.). Add the main() function that calls those functions in appropriate order last. The data is the important part of the program, not the function. That's something that will make the step to C++ (and object-orientation) easier.

There is more, but I don't claim to be answering everything in one SO post. :-)

Answer 4

Here are some points :

1) Make sure you are proficient in Pointers. Focus on how Arrays and pointers works, what are the similarities and differences between them.

2) The best way to perfect c is to write programs. Write as many as you can. For starter you can write custom functions for some of the library functions.You may try your hands on Strcpy, strcmp, strncpy, memcpy, memmove.

3) Learn how to Debug.(Gdb is really cool).

4) Start following a particular coding style and try to stick with it.

5) Always furnish your code with meaningful comments.

Answer 5

The best advice is probably to treat them as completely separate languages. Yes, most C code can be compiled by a C++ compiler, but it's generally not a good way to go.

C is very much a low-level hackery language. What you see is what you get. It has pointers and structs, so you use pointers and structs. It has very little type safety, so you ignore type safety as much as possible.

C++ on the other hand, allows a huge number of abstractions. Rather than pointers, you'll typically want to use iterators, which behave conceptually as pointers, but aren't (or might not be).

Instead of throwing away type information (for example having functions accept a void* so they'll work with any pointer type), you can use templates to retain type safety and still be able to reuse the same single function definition.

And you're given an excellent standard library which enables you to express complex algorithms in terms of simple predefined building blocks.

C++ is a multi-paradigm language. Some answers here have said that C++ is object-oriented, which is partially true. It does have support for object-oriented code, yes, but that's not what C++ is.

C++ also has support for generic programming, which is often preferable over OOP. It has some limited support for functional programming as well. And of course, it still has support for C-style procedural programming as well. The trick in C++ is to understand all of these, so you know which to use when. That is C++'s strength, the ability to switch between and mix all these paradigms. People who call C++ an OOP language miss the point just as much as people who call it an improved C. It allows you to write code in either of these styles, but neither of these are really worthwhile in themselves. C is a better C-like language, and there are plenty of better OOP languages. If you want to stick to one single paradigm, use a language designed for that.

Answer 6

Keep the languages separate.

C and C++ can be appear similar, but they are different languages with different rules for similar constructs. If you can isolate one from the other, all the better.

When switching to C++ be ready to unlearn (learn a different, incompatible method) about:

1. preprocessor: In C++ you should not use the preprocessor as much as in C.
2. strings: C doesn't have them
3. pointers: C++ can be coded to handle them more safely