Situations where "old" C features might be better than newer C++ ones?

Question

Recently i had a discussion with my boss (a long time C developer) who discouraged me in using C++ streams and stick to "good old" printf & friends. Now i can understand why he is saying this and believe me i did not follow his advice.

But still this is bugging me - are there things in C that are still better in some cases than newer C++ implementations of the same/similar thing? By better i mean for example performance, stability or even code readability/maintainability. And if so, can someone give me examples? I'm mainly talking about similar differences like printf/streams, not about features like inheritance or OOP for that matter. The reason why i'm asking all this is that i consider myself a C++ developer and as such I always try to code the C++ way.

Answer 1

When you're writing C++, write C++. When you're writing C, write C. Whoever says different is probably uncomfortable with the differences, or thinks of C++ as a "better C". That isn't the case; C++ is its own language with its own features, and is mostly C-compatible for the sole purpose of easing conversion.

Answer 2

As far as performance goes, I used to be a USACO competitor. I quickly found that 98% of one of my programs' runtime was spent using C++ IOStreams. Changing to fscanf reduced the overhead by a factor of ten. Performance-wise, there's no contest at all.

Answer 3

I think C style is better when you need raw memory management. It is a bit cumbersome to do that with C++ constructs and you don't have realloc() for example.

Someone who down voted that, probably never tried to explore the topic.

Answer 4

C printf()-style output is typically faster than C++ ostream output. But of course it can't handle all the types that C++ output can. That's the only advantage I'm aware of - typically, because of aggressive inlining, C++ can be a lot faster than C.

Answer 5

I sometimes prefer pointers and memcpy over iterators and std::copy when I don't need generic code.

Same for iostreams, they are convenient and extensible but there are a lot of situations when [f|s]printf / scanf are as simple.

Answer 6

Good old C! Ah, the pre-ANSI days... <sarcasm>I certainly miss having practically no type checking on arguments and returns values or having the compiler assume anything untyped is an int and not an error.</sarcasm>

Seriously, though - there is a fairly good argument against using exceptions as error handling. I read a fairly decent argument against exceptions for system level work and mostly I think the problem is that you can't simply read a block of code and know it won't throw in C++, whereas you can read most C and say "all the errors (at this level) are trapped" or "the ones that aren't don't matter".

Answer 7

I couldnt give you a conclusive answer; however i found this rather dated comparison interesting.

http://unthought.net/c++/c_vs_c++.html

Answer 8

There is one thing that C programmers sometimes point out and that is worth considering: If you stay away from macros, then it's mostly obvious what a line of C code does. Take for example this:

x = y;

In C, this is an assignment and only an assignment. The value of y is (after a possible conversion) copied into x.

In C++ this could literally mean anything.

• A simple assignment,
• a user defined conversion operator in y which deletes the internet and returns a value that is of the same type as x
• There is a constructor which makes an object of x's type from y, after melting down a nuclear power plant. This value is assigned to x.
• There is a user defined assigment operator which allows assignment from a bunch of other types, for which y has a conversion operator or which are in some other ways obtainable from y. The assignment operator has a bug which might create a black hole, because its a part of the LHC operation software.
• more of the above.

To make it even more interesting, every single operation might throw an exception in C++, which means that every line must be written in a way that it can rollback what it changed, which is sometimes hard when you can't say what a line actually does. And to make it worse, your program might crash instantly, because the exception happens because the assignment is called during a exception unwind. In C++ things tend to become "vertically complex", which poses its own requirements to the capabilities and the communication skills of the developers.

Answer 9

I dont think using printf style functions generally over iostreams is justified. iostreams just greatly speed up development time and debugging time, and are much less error prone (e.g. think of buffer overflows, wrong % type specifiers, wrong number of arguments ... and the biggest problem is that the compiler cant help you at all). And if you dont use endl when it isnt needed, cout isnt that much slower than printf.

So generally you should go with C++ iostreams, and only if profiling shows that critical sections take too much time because of iostream calls, then optimize those sections with C style functions, but make sure to use the safer versions of the functions like snprintf instead of sprintf.

Examples:

Consider you have a int foo variable, which you printf in a number of places, later during development, you realize you need foo to be a double instead. Now you have to change the type specifiers in every printf style call which uses foo. And if you miss one single line, welcome in the land of undefined behaviour.

Recently i had a case where my program crashed because i missed a simple comma, and because of the great printf-style command, my compiler didnt help me: printf("i will crash %s" /*,*/ "here");. This wouldnt have happened with iostreams either.

And of course you cant extend the behaviour of printf and friend to work with your own classes like you can with iostreams.

Answer 10

Where using C++ features might be problematic:

• portability: IMHO C is still more portable
• mixed language programming: calling a C function from another language is almost never problematic, with C++ you quickly get in trouble because of name mangling etc.
• performance issues: features like templates may lead to code bloat, temporary object creation may have a huge impact too, etc...
• maintainability: Since C++ is more complex than C, Restrict use to language features you expect the person who is later maintaining your code to be capable of.

However, some/most of C++ features are quite handy and useful if used with care. Remember the saying "With C++ it's harder to shoot yourself in the knee, but if you do, it will cost you the entire leg".