Take the 2-minute tour ×

As I've been developing my position on how software should be developed at the company I work for, I've come to a certain conclusion that I'm not entirely sure of.

It seems to me that if you are programming in C++, you should not use C style anything if it can be helped and you don't absolutely need the performance improvement. This way people are kept from doing things like pointer arithmetic or creating resources with new without any RAII, etc. If this idea was enforced, seeing a char* would possibly be a thing of the past.

I'm wondering if this is a conclusion others have made? Or am I being too puritanical about this?

share|improve this question
There's a performance improvement from using "C-style"? Are you sure? –  user16764 Nov 7 '12 at 18:19
If user16764's comment is not clear enough, well written templates are usually faster than C-style "generic" code with void*s, because the templates can be better inlined by the compiler. –  Jan Hudec Dec 3 '12 at 9:22
add comment

4 Answers

up vote 10 down vote accepted

It is basically the way standard C++ is intended and encouraged (by the committee and the community) to be used:

  • use C++ language idioms (mostly based on RAII, like smart pointers)
  • don't use C language idioms until you can't avoid it (which still happen regularly, when interfacing with C interfaces)

This is what we have been calling "modern C++" for almost 10 years now. But most C++ developers start only now to realize it makes code looks like there is no much need for raw pointers, writing new/delete, and other error-prone constructs.

Now these constructs (C or not) are still there both for retrocompatibilty and for allowing you to write libraries to, again, free the other developers from having to play with them. Also, C should be used to interface with C libraries, for low level constructs that require C-style code. Any other case, you can avoid using C idioms when you have C++ available.

For clarification: using C style doesnt improve performance (assuming you understand C++ constructs and RAII). In fact, a lot of algorithms written in C++ are faster than the same in C, just because C++ give more info to the compiler to make him optimize in calling context (I'm thinking about template algorithms/types for example).

So performance is not a valid reason to use C idioms when you write C++.

share|improve this answer
"Now these constructs (C or not) are still there both for retrocompatibilty and for allowing you to write libraries to, again, free the other developers from having to play with them.": Would it be possible to remove them for good through separate compilation, i.e. define a subset of C++ that does not use old constructs? –  Giorgio Nov 7 '12 at 18:01
No, first because C++ versions are highly retro-compatible (you can take C++98 code, if you didn't use auto or some obscure features, you will compile with a C++11 compiler), second because maintaining C interfacing is essential to continue to use C++ everywhere and with any other language's library. C is still the interface language between languages. –  Klaim Nov 7 '12 at 18:14
Yes but one could interface with C or with C++98 using separate compilation. Using the same method one can even interface Haskell with C. Regarding retro-compatibility, maybe one can use compiler switches to give a warning or error message when using a "forbidden" feature. My question is rather technical, i.e. whether it would be possible to eliminate dangerous stuff like new and delete and still have a working language, or whether there are other, higher-level features of the language that depend on the lower-level features in order to work. –  Giorgio Nov 7 '12 at 18:23
You can't remove them without losing the ability to implement from scratch. The language would only be able to "utilize" features like RAII rather than "implement" them. It would become a high-level language rather than an systems implementation language. How do you think RAII and smart pointers were implemented? –  mike30 Nov 7 '12 at 21:06
"It would become a high-level language rather than an systems implementation language.": I am a bit confused, because some claim that C++ is a high-level language. But yes, as long as it retains low-level constructs inherited from C I guess you are right that it is rather a low-level, system implementation language. –  Giorgio Dec 3 '12 at 9:43
show 8 more comments

C++ is a language that provides a lot of features that you may chose to use or not. Your decisions should be based on

a) Frameworks you use

b) The domain of your application

c) Your current code base


Some frameworks lend themselves to specific styles. For example, if you are using Qt/KDE/Wt you will usually use their memory model and will not have your own smart pointers. You're unlikely to use exceptions as much. Qt's MOC also has certain implications for templates that limits how much you can do with them.

At the same time, code that is heavily based on boost tends to be heavy in what others have described as 'Modern C++'.

Then you have Google-stylized C++ which is essentially C with classes. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Application Domain

If you are coding software where performance is critical (financial, embedded,etc), a lot of the 'niceties' of C++ might go out the window in favour of limiting memory footprints or CPU cycles. There are situations where C is the 'right' language to use for a small part of the program, but not for the whole thing; C++ allows you to do that so that you can have your pointer arithmetic when doing crazy matrix math but have high level abstractions when combining the modules that use it.

Current Code Base

In the real world, if you are in a shop with 10 C coders who don't want or like C++ you will have a much better time sticking to something like the Google style guide than something that is more 'Modern'. If all your libraries are written in C and you are only gluing them together in C++ then char * might make more sense than going to and from std::string all the time.


C++ is not a langauge that is ideal in any academic sense, but it is a pragmatic compromise that worked out very well. So when using it, you should also have a very pragmatic approach to the problem and not get too bogged down on 'The Right Way Of Doing Things'.

To answer your question: you may or may not be too puritanical, but that depends on the specifics.

share|improve this answer
Google's C++ code makes heavy use of templates and permits or encourages other C++ techniques such as smart pointers, (parts of) Boost, etc. Saying that Google-stylized C++ is merely C with classes might be an overstatement. –  Josh Kelley Nov 9 '12 at 14:22
@JoshKelley I agree with you, it might be too strongly worded in that sense. But I am trying to identify a differnt direction of coding style which is never really clear-cut, and they will always overlap. –  MrFox Nov 9 '12 at 16:41
from the google style guide: "Use only approved libraries and language extensions from C++11 (formerly known as C++0x). Currently, none are approved." Uhmmmm... Time to upgrade the style guide ... –  Emilio Garavaglia Nov 9 '12 at 20:55
add comment

The new c++ has some advantages, this is much clearer than two 'c' style loops in i,j:

int array[5][10]; int i;
for_each(array, array+5,
share|improve this answer
I'd be very curious to see you write out the two nested loops side by side with above code segment so we can all compare and see which one is clearer :) –  DXM Nov 7 '12 at 18:33
this is much clearer than two 'c' style loops Is it? I suppose it depends on who is reading it. –  Caleb Nov 7 '12 at 18:34
@DXM I was going to but I couldn't work out what the hell the C++ example was calculating! –  Martin Beckett Nov 7 '12 at 18:41
@Caleb - sorry, I'm British and an engineer = assume everything is irony –  Martin Beckett Nov 12 '12 at 1:37
@Martin Beckett: Got the irony now. +1! –  Giorgio Dec 3 '12 at 10:31
show 1 more comment

There is one case where you definitely should write in C style, and this is hardware-related programming. The main reason why the "raw C" is preserved in the C++ language is not just backwards compatibility, but the "raw C" also enables C++ to be used in bare bone hardware applications: when you are accessing hardware directly, when there is no OS present, or when you are writing the OS itself.

There is also the performance argument. Idealists will tell you that you shouldn't use raw arrays, you should only use std::vector, and it should be equally fast as a plain array - if not then the compiler is bad. This is utopia, we have yet to see it. So far, STL and templates remain slower than "bare bone" code. However, the more C++ programmers that use templates, STL abstraction etc, the more pressure there will be on the compilers to produce faster code for it.

If the C features where removed from C++, then it wouldn't be as much of a general-purpose language as it is today. It wouldn't be used as much in embedded systems or performance-critical applications, it would become yet another desktop-only language like Java or C#.

share|improve this answer
add comment

Your Answer


