C vs C++

by Sanjay Mishra

While developing software for embedded systems we are often faced with the choice of using C vs C++. Some proponents of C++ push C++ with all the zeal of new converts, saying that it offers the one true path to programming nirvana - object oriented programming. C proponents push size and efficiency.

The reality of C vs C++ is more complex. C++ offers more than Object Oriented Programming and very often you can derive the benefits of OOPs while still programming in C.

I would suggest you examine the domain you are targeting before making a choice in C vs C++.

If you are at an application level with lots of RAM available, C++ will allow you to be more productive. However take a look at languages like Java and C# also. Development in these langauges is often more productive than that in C++. If you are only going to target Windows environments C# may be a good choice. Java may be good choice if you want the widest possible deployment range from mobile phones to enterprise class servers.

Here we will examine the question of C vs C++ with special attention to their use in embedded systems. Embedded systems are often severely constrained in memory while still requiring high performance. It would be great if we can take advantage of the advanced features built into C++ while limiting the impact that they sometimes have on performance and memory use.

There are two ways of utilizing more advanced features while programming

  • Using C intelligently, with constructs that enable us to implement advanced features in C
  • Using C++ selectively. Using only those features that give us the most advantage while having an acceptable impact on performance and memory use.

We will list the most prominent features of C++ , examine their performance impact and see if we can achieve comparable performance in C. Knowing this list will allow you to use the C++ compiler to generate efficient embedded code suited for the size of your application, or allow you to implement advanced features in C code.

Standard C Library

You can continue using the standard C library (as implemented for your target system) in both C and C++.

Standard C++ Library

C++ Standard Library is much bigger than C Standard Library. It contains useful functions though. For deeply embedded systems I have not used C++ Standard Library. For functions that I find useful like string functions, I implement similar functions in C.

Information hiding, data abstraction, modular programming

C++ private and public keywords are not available in C. However one can use static to make a function private within a file. See Modular Programming .

These are compile time checks and should not impact run time performance. You can use them without penalty if you are using C++.

Function and Operator Overloading

This is a compile time feature of C++. You can use it without run time penalty.

There is no correspondence to these in C. You can emulate function overloading by using functions with slightly different names. You can use functions to emulate operator overloading in C.

Object Oriented Programming and Implementation

You can do object oriented programming(OOPs) in C. C++ provides language features that makes OOP easier to do. However there is a small run time penalty for doing object oriented programming. This penalty is roughly the same whether C or C++ is used.


C++ constructors and destructors may be implicitly called by the compiler for you. You will have to be careful about this. If you are doing OOP in C you will be calling the constructor explicitly so you will be aware of all such calls.

Simple Inheritance and Virtual functions

These have a slight overhead. This is acceptable in most embedded systems. If the situation is such that you have to be concerned about this slight overhead, you should probably be using hand optimized assembly. And no, no matter what they say, for critical loops no compiler out performs assembly in the hands of an expert.

Multiple inheritance

It is possible to implement so in C. However multiple inheritance comes with its own intrinsic problems and increased overhead so I would advise against using it in an embedded system. Many modern languages (for example Java and C#)do not allow multiple inheritance because of the problems associated with it.

Run Time Type Identification

This feature is available only in C++. C++ keeps information at run time about the type of an object. This results in both performance and memory overhead. I would not use it in a memory and performance constrained embedded system. Having RTTI enabled is necessary for dyanmic_cast, type_id and exceptions to work.

Although it is possible to implement RTTI in C, I have not ever had occasion to implement it.


These allow a function or a class in C++ to work on many different data types without being re written for each of them.. One can think of defining generic function as defining verbs which can be applied to any object. Templates lead to extra code being generated and are best avoided for embedded programs.

You can in some cases simulate templates with macros in C. For example the following code will work irrespective of whether the arguments passed are char, int or doubles.

#define minimum(x,y) ((x) < (y) ? (x) : (y))

Personally I am not a big preprocessor user.


In C special return codes from functions are used to report error conditions.

In C++ try catch and throw keywords are used to implement an exception handling mechanism. Implementating C++ exception handling usually results in a performance and size penalty irrespective of whether an exception is thrown or not. I would not use C++ exception handling where performance and size are critical.

Top of C vs C++

Need More Help? Have An Opinion?

Do you need more help to solve your problem? Would you like to ask the author a question about your specific problem? Do you have a great idea about this?

We will post an answer within 2 business days. If you need more immediate assistance or you would like to discuss your issue privately, please use our contact us form or call us at 1-888-215-8557. We love solving technical issues and there is no charge if we solve your problem over email or over a short phone call.

[ ? ]

Author Information (optional)

To receive credit as the author, enter your information below.

(first or full name)

(e.g., City, State, Country)

Submit Your Contribution

  •  submission guidelines.

(You can preview and edit on the next page)