What would be C++ limitations compared C language?

Following are the benefits of C++

• C++ provides the specific features they are asking about
• Their C compiler is almost certainly really a C++ compiler, so there are no software cost implications
• C++ is just as portable as C
• C++ code can be just as efficient as C (or more so, or less so)

Are there any concrete reasons and specific scenarios, where one has to use C over C++?

Reference to this question:Library for generics in C

Not a duplicate, because this question is asking about language limitations and not about should/shouldn't learn one language over another.

Peter Kirkham's post was for me the most informative, particularly with regard to C99 issues which I hadn't considered, so I've accepted it. Thanks to all others who took part.

> This is prompted by a an answer I gave to a current question which asks about a generics library for C - the questioner specifically states that they do not want to use C++.

C is a complete programming language. C is not an arbitrary subset of C++. C is not a subset of C++ at all.

This is valid C:

foo_t* foo = malloc ( sizeof(foo_t) );

To make it compile as C++ you have to write:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

which isn't valid C any more. (you could use the C-style cast, it which case it would compile in C, but be shunned by most C++ coding standards, and also by many C programmers; witness the "don't cast malloc" comments all over Stack Overflow).

---

They are not the same language, and if you have an existing project in C you don't want to rewrite it in a different language just to use a library. You would prefer to use libraries which you can interface to in the language you are working in. (In some cases this is possible with a few extern "C" wrapper functions, depending on how template/inline a C++ library is.)

Taking the first C file in a project I'm working on, this is what happens if you just swap gcc std=c99 for g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

In total 69 lines of errors, four of which are invalid conversions, but mostly for features that exist in C99 but not in C++.

It's not like I'm using those features for the fun of it. It would take significant work to port it to a different language.

So it is plain wrong to suggest that > [a] C compiler is almost certainly really a C++ compiler, so there are no software cost implications

There are often significant cost implications in porting existing C code to the procedural subset of C++.

So suggesting 'use the C++ std::queue class' as an answer to question looking for an library implementation of a queue in C is dafter than suggesting 'use objective C' and 'call the Java java.util.Queue class using JNI' or 'call the CPython library' - Objective C actually is a proper superset of C (including C99), and Java and CPython libraries both are callable directly from C without having to port unrelated code to the C++ language.

Of course you could supply a C façade to the C++ library, but once you're doing that C++ is no different to Java or Python.

I realize it's neither a professional nor a particular good answer, but for me it's simply because I really like C. C is small and simple and I can fit the whole language in my brain, C++ to me has always seemed like a huge sprawling mess with all kinds of layers I have a hard time grokking. Due to this I find that whenever I write C++ I end up spending far more time debugging and banging my head against hard surfaces than when I code C. Again I realize that a lot of this is largely a result of my own 'ignorance'.

If I get to choose I'll write all the high level stuff like the interface and database interaction in python (or possibly C#) and all the stuff that has to be fast in C. To me that gives me the best of all worlds. Writing everything in C++ feels like getting the worst of all worlds.

Edit: I'd like to add that I think C with a few C++ features is largely a bad idea if you're going to be several people working on a project or if maintainability is priority. There will be disagreement as to what constitutes a 'a few' and which bits should be done in C and which bits in C++ leading eventually to a very schizophrenic codebase.

C++ simply isn't supported in some real-world environments, like low-level embedded systems. And there's a good reason for that: C easily good enough for such things, so why use something bigger?

A couple of reasons might be:

• Lack of support - Not every C compiler is also a C++ compiler. Not all compilers are particularly compliant with the standard, even if they claim to support C++. And some C++ compilers generate hopelessly bloated and inefficient code. Some compilers have terrible implementations of the standard library. Kernel-mode development generally makes use of the C++ standard library impossible, as well as some language features. You can still write C++ code if you stick to the core of the language, but then it may be simpler to switch to C.
• Familiarity. C++ is a complex language. It's easier to teach someone C than C++, and it's easier to find a good C programmer than a good C++ programmer. (keyword here is "good". There are plenty of C++ programmers, but most of them have not learned the language properly)
• Learning curve - As above, teaching someone C++ is a huge task. If you're writing an app that has to be maintained by others in the future, and these others may not be C++ programmers, writing it in C makes it a lot easier to get to grips with.

I'd still prefer writing in C++ when I can get away with it, and overall, I think the benefits outweigh the disadvantages. But I can also see the argument for using C in some cases.

There are loads of arguments about embedded programming, performance and stuff, I don't buy them. C++ easily compares to C in those areas. However:

Just recently after having programmed in C++ for over 15 years I've been rediscovering my C roots. I must say that while there are good features in C++ that makes life easier there are also a load of pitfalls and a kind of "there-is-always-a-better-way" of doing things. You never actually get quite happy about the solution you did. (Don't get me wrong, this could be a good thing, but mostly not).

C++ gives you infinite gunfire. Which could be arguably good but somehow you always end up using too much of it. This means that you are disguising your solutions with "nice" and "pretty" layers of abstractions, generality, etc.

What I discovered going back to C was that it was actually fun programming again. Having spent so much time modeling and thinking about how to best use inheritance I find that programming in C actually makes my source code smaller and more readable. This is of course depending on you level of self-discipline. But it is very easy to put too much abstractions on straight forward code, which is never actually needed.

C has the main advantage that you can just see what is really going on when you look at some piece of code (yeah preprocessor: compile with -E and then you see it). Something that is far too often not true when you look at some C++ code. There you have constructors and destructors that get called implicitly based on scope or due to assignments, you have operator overloading that can have surprising behavior even when it's not badly misused. I admit I'm a control freak, but I have come to the conclusion that this is not such a bad habit for a software developer who wants to write reliable software. I just want to have a fair chance to say that my software does exactly what it is supposed to do and not have a bad feeling in my stomach at the same time because I know there could still be so many bugs in it that I wouldn't even notice when I looked at the code that causes them.

C++ also has templates. I hate and love them, but if anyone says he or she fully understands them I call him/her a liar! That includes the compiler writers as well as the folks involved in defining the standard (which becomes obvious when you try to read it). There are so many absurdly misleading corner cases involved that it's simply not possible to consider them all while you write actual code. I love C++ templates for their sheer power. It's really amazing what you can do with them, but they can likewise lead to the strangest and hardest to find errors one can (not) imagine. And these errors actually happen and not even rarely. Reading about the rules involved to resolve templates in the C++ ARM almost makes my head explode. And it gives me the bad feeling of wasted time having to read compiler error messages that are several 1000 characters long for which I need already 10 minutes or more to understand what the compiler actually wants from me. In typical C++ (library) code you also often find a lot of code in header files to make certain templates possible which in turn makes compile/execute cycles painfully slow even on fast machines and requires recompilation of large parts of the code when you change something there.

C++ also has the const trap. You either avoid const for all but the most trivial use cases or you will sooner or later have to cast it away or to refactor large parts of the code base when it evolves, especially when you are about to develop a nice and flexible OO design.

C++ has stronger typing than C, which is great, but sometimes I feel like I'm feeding a Tamagotchi when I try to compile C++ code. A large part of the warnings and errors I usually get from it are not really me doing something that wouldn't work, but just things the compiler doesn't like me to do this way or not without casting or putting some extra keywords here and there.

These are just some of the reasons why I don't like C++ for software that I write alone only using some allegedly robust external libraries. The real horror begins when you write code in teams with other people. It almost doesn't matter whether they are very clever C++ hackers or naive beginners. Everybody makes errors, but C++ makes it deliberately hard to find them and even harder to spot them before they happen.

With C++ you are simply lost without using a debugger all the time but I like to be able to verify the correctness of my code in my head and not having to rely on a debugger to find my code running on paths I would never have anticipated. I actually try to run all my code in my head and try to take all the branches it has, even in subroutines etc. and to use a debugger only occasionally just to see how nicely it runs through all the cosy places I prepared for it. Writing and executing so many test cases that all code paths have been used in all combinations with all sorts of strange input data is simply impossible. So you might not know of the bugs in C++ programs but that doesn't mean they are not there. The larger a C++ projects gets the lower becomes my confidence that it will not have lots of undetected bugs even if it runs perfectly with all the test data we have at hand. Eventually I trash it and start anew with some other language or combination of other languages.

I could go on but I guess I made my point clear by now. All of this has made me feel unproductive when I program in C++ and made me lose confidence in the correctness of my own code which means I won't use it anymore, while I still use and rely on C code that I wrote more than 20 years ago. Maybe it's simply because I'm not a good C++ programmer, or maybe being quite good in C and other languages allows me to recognize what a lamer I actually am when it comes to C++, and that I will never be able to fully comprehend it.

Life is short...

In a low-level embedded environment some of the "software engineers" will have an EE background and have barely mastered C. C++ is more complex and some of these guys are simply afraid to learn a new language. Thus C is used as the lowest common denominator. (Before you suggest getting rid of these guys, they're at least as important as the CS majors who don't understand the hardcore analog stuff.)

Speaking from experience in having inherited and maintained both: a horrible design in C is difficult to understand, unwind, and refactor into something usable.

A horrible design in C++ is infinitely worse as random layers of abstraction send your brain careening around the codebase trying to figure out which code is going to be executed in which circumstance.

If I have to work with engineers who I know will not produce great designs, I'd much rather have the former than the latter.

I do not see any reason other then personal dislike, even for programming embedded systems and similar things. In C++ you pay overhead only for features you use. You can use the C subset of the C++ in some specific situations where C++ overhead is too high for you. This said, I think some C programmers overestimate the overhead of some C++ constructs. Let me list some examples:

• Classes and member functions have zero overhead compared to normal functions (unless you use virtual functions, in which case there is no overhead compared to using functions pointers)
• Templates have very little overhead (most often no overhead at all)

One valid reason would be when you are programming for a platform which does not have a decent C++ compiler (no C++ compiler at all, or a compiler exists, but is poorly implemented and imposes an unnecessary high overhead for some C++ features).

Why limit speaking in English? Perhaps you'd be a more creative author in Serbian.

That's the same argument, with obvious fallacies. If you have a task, and your comfortable tools solve the task efficiently, you'll likely use your comfortable tools for good reason.

C++ has a much longer learning curve. C has only few constructs you need to be aware of and then you can start coding powerful software. In C++ you need to learn the C base, then the OO and generic programming, exception, etc. And after a time you may know most of the features and you porbably can use them, but you still don't know how the compiler will translate them, what implicit overhead they have or not. This takes much time and energy.

For a professional project this argument may not count, because you can employ people that already know C++ very well. But in Open Source Projects, where C is still widley used, the people pick the language they like and they are able to use. Consider that not every OS-programmer is a professional programmer.

I'd like to follow up on Dan Olson's answer. I believe that people fear the potentially dangerous and counter-productive features of C++, and justifiably so. But unlike what Dan says, I do not think that simply deciding on a coding standard is effective, for two reasons:

1. Coding standards can be difficult to strictly enforce
2. It can be very difficult to come up with a good one.

I think that the second reason here is much more important than the first, because deciding on a coding standard can easily become a political matter and be subject to revision later on. Consider the following simplified case:

1. You're allowed to use stl containers, but not to use templates in any of your own code.
2. People start complaining that they'd be more productive if they just were allowed to code this or that template class.
3. Coding standard is revised to allow that.
4. Slide a slope to an overly complicated coding standard that nobody follows and use of exactly the kind of dangerous code that the standard was supposed to prevent, combined with excess bureaucracy surrounding the standard.

(The alternative that the standard is not revised in step 3 is empirically too improbable to consider and wouldn't be that much better anyway.)

Though I used to use C++ for just about everything a few years ago, I'm beginning to strongly feel that C is preferrable in low-level tasks that need to be handled by either C or C++ and everything else should be done in some other language entirely. (Only possible exceptions being some specific high-performance problem domains, wrt. Blitz++)

I've never seen any arguments for using C over C++ that I'd consider convincing. I think most people are afraid of certain features C++ offers, often justifiably. Yet this doesn't convince me because one can enforce whether or not to use certain features through coding standards. Even in C, there's much you'd want to avoid. Discarding C++ entirely is essentially saying it offers no tangible benefits over C that would help one write better code, which is a view I consider to be quite ignorant.

Additionally, people always seem to raise the situation of platforms where no C++ compiler exists. Certainly C would be appropriate here, but I think you'd be hard pressed to find a platform like that these days.

I use C, or at least export a C interface when I write library code.

I don't want ill-defined ABI hassles.

One point I've not seen raised yet, which I think is the most important:

Most of the libraries I use on a daily basis are C libraries with bindings for Python, Ruby, Perl, Java, etc. From what I've seen, it's a lot easier to wrap C libraries with 19 different language bindings than it is to wrap C++ libraries.

For example, I learned Cairo once, and have since used it in 3 or 4 different languages. Big win! I'd rather write a program that can be used again in the future, and writing one that can easily be adopted to other programming languages is an extreme case of this.

I know it's possible to bind C++ libraries, but AFAICT it's not the same. I've used Qt (v3 and v4) in other languages and it's not anywhere near as nice to use: they feel like writing C++ in some other language, not like native libraries. (You have to pass C++ method sigs as strings!)

C++ is probably a better language if you're writing a function to be used once, or if you think all the world is C++. C seems like an easier language if you're designing for language-portability from the start.

Windows kernel development doesn't support c++ (sadly).

You can read an entertaining rant about why Linus Torvalds favours C here

Native code on a mac is objective-c. Native code on a PC is c (window.h) or c++ (mfc). Both of these environments will let you use c with little or no changes. When I want a library of code to be cross platform ansi c seems like a good choice.

I can think of several reasons.

There may not be a satisfactory C++ compiler. C++ is a much bigger language, and I've run C compilers on systems that would not be able to handle modern C++.

The questioner, or people he or she works with, may be familiar with C but not C++.

The project may be in C. While it's possible to add some C++ features to C, that can easily lead to an unmaintainable mess. I'd suggest picking one language or the other (usually C++, when practical).

The questioner may have an obsolete view of C++'s learning curve. (When approached correctly, it's easier than C's. Most introductory books I've seen don't approach it correctly.)

Remember that C and C++ are two different languages, and are getting more different over time. Coding in both at once is a bad idea, and using a C-like subset of C++ misses most of the advantages of C++.

1. C is a simple language, C++ is not. For many people, C++ is simply too complicated to fully master, see http://en.wikipedia.org/wiki/C%2B%2B#Criticism.

2. Because of the complexity, different programmers usually only master different subsets of the language. It makes reading other people's code painful.

3. The complexity, pitfalls of the language add too much distraction, and sometimes hurt productivity. Instead of focus on the job itself, I often found myself fighting with the language itself. Java/python are more productive alternatives.

4. Debugging a broken C code is usually much more straightforward than debugging a broken C++ code.

5. Unlike Java/C#, the C++ standard library achieves little beyond the scope of the C standard library.

6. Some famous programmers like Linus Torvalds (Linux) and Richard Stallman (Emacs) dislike C++.

I use C++ with C programming for two reasons:

• vector and string to get the array memory management away from me
• strict type checking and casts to warn and/or catch allthe nuisances I would miss otherwise.

So it is C really borrowing a few c++ but using the c++ compiler as much as I can. As someone else says in the answers, I find now I am actually picking up more C++ this way and where C would be too involving, I use C++. Monitor/Lock using RAII is one of these I've used recently when dealing with multi-threaded programs and another similar construct to open/close files.

I think C is more portable. I did some work about 5 years ago porting code to many flavours of unix (AIX,Irix,HPUX,Linux). The C code was easy to port but we had various problems porting some of the C++ code across. Maybe it was just immature development environments but i would much rather use C over C++ for this reason...

If you work in an environment with two languages, you might use C for some performance critical low-level functions and a more functional/high level language like C#/Java for the business logic. If C++ code is usedfor these functions ,C-Wrappers are required for JNI/unmanaged code around and this makes things more complex than solely using C.

I can follow many suggestions here in both directions. But in the end it comes down to a) comparable simple b) comparable complex.

I don't have an idea if someone has "invented" a sort of language complexity measurement.

On a scale from 0 - 10 I probably would rate C at 2 or 3 whereas C++ would be between 8-10. I'd argue C++ is one of the most complex languages but I do not know e.g Ada, PL1 or the like, so maybe it's not that complex in comparison to some other language.

C++ inherits all complexity of C so it can not be below the complexity level of C.

I for my part would be much more comfortable using some scripting language and C. So in the end one has to answer the following question. "Is more always better?"

Most programmers take it for granted that everyone considers quality a high priority. That's not always the case. If you're use to C, C++ might seem like it's doing too much for you behind the scenes. The strictness of type checking in C++ might also seem confining. Many people are willing to risk introducing the kinds of bugs that C++ can help prevent to avoid these "nuisances."

There are three reasons I can think of. One is that C is more suited for embedded systems, due to the small size of its binaries and the wider availability of C compilers on any system. The second is portability: C is a smaller language, and and ANSI C code will compile anywhere. It's easier to break portability in C++. The last one is the language itself. C++ is harder, and is most definitely a very poorly designed language. Torvalds gripes are reported above. You may also want to look at the C++ Frequently Questioned Answers (http://yosefk.com/c++fqa/).

Portability may be an issue. Different to Gordon Carpenter-Thomp's answer, I would suggest that it's rather the runtime support of different versions of libstdc++ on different linux/unix versions. See this link for a good discussion about this. A little excerpt:

> The runtime support code used by different parts of a C++ application needs to be compatible. If one part of the program needs to dynamic_cast or catch objects provided by another, both parts must agree on certain implementation details: how to find vtables, how to unwind the stack, and so on. > > For C++ and a few other GCC-supported languages with similar features, such details are specified by a C++ ABI. Whenever the ABI used by GCC changes you'll end up with incompatible libraries produced by the different GCC versions. The same is true for plain C, but the C ABI is much simpler and has been around a lot longer so it's fairly stable.

The most useful thing I found in C is the lack of namespaces and overloads: function and symbol names are unique identifiers. To find the places where these symbols are used you can just grep through the source code files and search results will shows the locations.

It's essential when wiring in a new feature or component to an old and tangled system.

You cannot do this easily in C++, without a sophisticated call graph building tool.

The following are all reasons why it may be beneficial to limit a project to C:

• faster compilation because the language is much simpler
• requires less runtime support, making it more suitable low-level environments
• much easier to interface with other languages
• supports variable sized arrays on the stack
• easier to read assembly code because there is no name mangling
• allows code produced by different compilers to be easily combined since it is the de facto standard application binary interface

There are various flavours of attempts of enhancing C into an object-oriented language: C++, C# and Objective-C. (Java and friends are just a flavour of C#, with even more problems)

C# implemented OO well and completely, but at the cost of the possibility of reverting to procedural design without introducing either hassle or code smell. Also, the introduction of a virtual machine made it difficult to write code that is anywhere near low level and it can never be self-hosted as the virtual machine itself have to be implemented in some language that can run natively. Java is even more problematic by making primitive types second-order citizen. (In C#, you have System.Int32 (a primitive type, int) : System.ValueType : System.Object, which makes primitive types still objects, but in Java primitive types are not objects at all). However, it is the most portable as compiled binaries that runs under virtual machines are inherently binary compatible under different platforms.

C++ did not use any virtual machine, and retained the C pointers, which make it still suitable for system development. (The kernel of OS X, Darwin, is largely written in C++, but a tight subset of which that does not have templates, multiple inheritance or STL, essentially a C++-looking dialect of Objective-C. Look at OS X IOKit documentation and you will find out) However C++ did not resolve those classical C issues at all while introducing more issues, including portability issues which is clearly the most obvious.

Objective-C went half ways in the middle of C++ and C#, as it is a simple mix of C (any version) and a modified Smalltalk dialect. Smalltalk, just like C#, treats everything as objects. It does not use a virtual machine as well, and it can still (requires!) use pointers, thus it can still be used as a system development language. (Weird why there is nobody doing it? I want to fork Minix and try implement a kernel with minimal assembler and C, and mostly Objective-C) With appropriate libraries Objective-C is largely code-compatible (that is, requires a recompile but no code change) between platforms just like C.

• Because the compiler vendor only provides a C compiler which is certified for safety critical applications
• Because the C++ FQA is scary. http://www.yosefk.com/c++fqa/

Most people seem to think that C and C++ are somehow related, but they are sadly mistaken. C++ is a completely different language than C.

In C++, you think in terms of objects and how they are related to each other. In C, you think in terms of APIs. It's like the difference between day and 17.

A poor analogy: if someone adds Chinese to English and calls it English++, you probably wouldn't feel comfortable to add a Chinese line to your latest love letter, because it's so much easier to express love in this part of English++.