What are the bad habits of C programmers starting to write C++?

Question

A discussion recently ended laughing at the bad habits of programmers that have been too exposed to a language when they start programming in another language. The best example would be a Pascal programmer starting to #define begin { and #define end } when starting to write C.

Goal is to try to catch the bad habits of C programmers when they start using C++.

Tell about the big don't that you encountered. One suggestion by answer, please, to try to achieve a kind of best of.

For the ones interested in good habits, have a look at the accepted answer to this question.

Answer 1

My favourite is the C programmer who writes a single method with multiple, optional, arguments.

Basically, the function would do different things depending on the values and/or nullability of the arguments.

Answer 2

Not using the STL, especially std::string,

and/or

using std::strings and reverting to old c string functions in tight corners.

Answer 3

Using raw pointers and resources instead of RAII objects.

Answer 4

Not fully understanding the semantics of pointers and references and when to use one or the other. Related to pointers is also the issue of not managing dynamic allocated memory correctly or failing at using "smarter" constructs for that(e.g. smart pointers).

Answer 5

• using char* instead of std::string
• using arrays instead of std::vector (or other containers)
• not using other STL algorithms or libraries like boost where appropriate
• abusing the preprocessor where constants, typedefs or templates would have been better
• writing SESE-style (single-entry single exit) code

Answer 6

Assuming said programmers have already made the mistake of attempting to learn C++:

Mistakes

• Not using STL.
• Trying to wrap everything in classes.
• Trying to use templates for everything.
• Not using Boost. (I know Boost can be a real PITA, and a learning curve, but C++ is just C+ without it. Boost gives C++ some batteries).
• Not using smart pointers.
• Not using RAII.
• Overusing exceptions.

Controversial

• Moving to C++. Don't do it.
• Try to convert C stdio to iostreams. Iostreams SUX. Don't use it. It's inherently broken. Look here.
• Using the following parts of the libstdc++ library:
  • strings (beyond freeing them for me, go the hell away)
  • localization (what the hell does this have to do with c++, worse yet, it's awful)
  • input/output (64 bit file offsets? heard of them?)
• Naively believing you can still debug on the command line. Don't use C++ extensively without a code crane (IDE).
• Following C++ blogs. C++ blogs carp on about what essentially boils down to metadata and sugar. Beyond a good FAQ, and experience, I've yet to see a useful C++ blog. (Note that's a challenge: I'd love to read a good C++ blog.)

Answer 7

using pointers instead of references

Answer 8

1. Writing class definitions that are 2000 lines of code.
2. Copying and pasting that class definition into 12 different places.
3. Using switch statements when a simple virtual method would do.
4. Failing to allocate memory in constructor and deallocate in destructor.
5. Virtual methods that take optional arguments.
6. Writing while loops to manipulate char* strings.
7. Writing giant macro's that are a page in length. (Could have used templates instead).

Answer 9

Making everything in a class public. So, data members that should be private aren't.

Answer 10

Very experienced developers not understanding casting or even object oriented programming:

I started helping out on a project and one of the senior guys was having a problem with some code that used to work and now didn't.

(Class names have been changed to protect the innocent, and I can't remember the exact names) He had some C++ code that was listening to incoming message classes and reading them. The way it had worked in the past was that a Message class was passed in and he would interogate a variable on it to find out what type of message it was. He would then C-style cast the Message as another specialised class he'd written that inherited from Message. This new class had functions on it that extracted the data how he wanted it. Now, this had been working for him fine but now was not.

After many hours looking through his code he could not see a problem and I had a look over his shoulder. Immediately I told him that it's not a good idea to C-style cast Message to a derived class which it was not. He disagreed with me and said he'd been doing it for years and if that was wrong then everything he does is wrong because he frequently uses this approach. He was further backed up by a contractor who told me I was wrong. They both argued that this always works and the code hasn't changed so it's not this approach but something else that has broken his code.

I looked a bit further and found the difference. The latest version of the Message class had a virtual function and hadn't previously had any use of virtual. I told the pair of them that there was now a virtual table and functions were being looked up, etc, etc.... and this was causing their problem, etc, etc.... They eventually agreed and I was presented with a comment that I will never forget: "Virtual completely screws up polymorphism and object oriented programming".

I forwarded them a copy of a decorator pattern as an example of how to add a function to an existing class but heard nothing back from them. How they fixed the idea I have no idea.

Answer 11

Using C-style casts.

C++ allows you to independently choose whether to allow casts between unrelated types, and whether to allow changes to const and volatile qualifiers, giving considerable improvements to compile-time type safety compared with C. It also offers completely safe casts at the cost of a runtime check.

C-style casts, unchecked conversions between just about any types, allow whole classes of error that could be easily identified by more restrictive casts. Their syntax also makes them very difficult to search for, if you want to audit buggy code for dubious conversions.

Answer 12

Not leaving well enough alone, and using C instead.

Answer 13

One word: macros. I am not saying macros have no place at all in C++, but former C programmers tend to use them way too much after they switch to C++.

Answer 14

Writing using namespace std because everyone does and then never reflecting on its meaning. Or knowing what it means but saying "std::cout << "Hello World" << std::endl; looks ugly".

Answer 15

Not using templates when creating algorithms and data structures (example). It makes things either too localized or too generic

I.e. writing

void qsort(MyStruct *begin, size_t length);  //too localized
void qsort(void *begin, size_t length, 
           size_t rec_size, int(compare*)(void*,void*));  //too generic

instead of

template <class RA_Iter>
void qsort(RA_Iter begin, size_t length);
  //uses RA_Iter::value_type::operator< for comparison

Answer 16

Adding using's into header files so they can avoid names like std::string in type declarations.

Answer 17

Passing objects with pointers instead of references. Yes, there are still times when you need pointers in C++, but references are safer, so you should use them when you can.

Answer 18

Declaring all the variables at the top of a function instead of as close as possible to where they are used.

Answer 19

Confused uses of structs vs. classes, overuse of global methods that take object pointers as arguments, and globally-accessible instance pointers, a la:

extern Application* g_pApp;
void RunApplication(Application* app, int flags);

Also (not saying it's totally useless, but still):

const void* buf;

Answer 20

Well, bad program design transcends languages ( casts, ignoring warnings, unnecessary precompiler magic, unnecessary bit-twiddling, not using the char classification macros ) , and The C language itself doesn't create too many "bad habits" ( Ok, Macros, esp from the stone ages ), and many of the idioms translate directly. But a few that could be considered:

Using a feature just because it's in C++ and so therefore it must be the right way to do something. Some programs just don't need Inheritance, MI, exceptions, RTTI, templates ( great as they are ... the debugging load is steep ), or Virtual class stuff.

Sticking with some code snippet from C, without thinking if C++ has a better way. ( There's a reason you now have class, private, public, const (expanded beyond C89) , static class funcs, references.

Not being familiar with the C++ i/o lib ( its BIG, and you do need to know it) , and mixing C++ i/o and C i/o.

Answer 21

He thinks that C++ is just a little more different language from C. He will continue programming C masked by C++. No advanced use of classes, the structs are considered less powerful than classes, namespace, new headers, templates, nothing of these new elements are used. He will continue declaring integer vars without int, he will not provide functions prototypes. He will use malloc and free, unsafe pointers and preprocessor to define inline functions. This is just a small list ;)

Answer 22

Declaring all the variables at the start of the function itself even if the variable will be used only after 100 lines or so.

Happens especially for local variables declared inside a function.

Answer 23

1. Solving the problem instead of creating a class-based monstrosity guaranteed to keep you in health insurance and 401K benefits.

2. Implementing lisp in a single file and doing the design in that.

3. Writing normal readable functions instead of overriding operators?

4. Writing in a style which can be understood by the junior programmers which see good practice as "not writing in C++".

5. Talking to the OS in it's own language.