# This is not a C vs. C++ thread...

This topic is 4355 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I don't want a battle on which language is better, C or C++. Rather, are there certain things that C does more effectively than C++? I am already aware of the advantages of C++ with object oriented programming and the like, though I am currently only programming in C for classes and my own practice. I know some people claim that C code can result in faster binaries and compiles but that's not really what I'm getting at and I also know that C++ people will take issue with that claim. I'm looking for other things, if there are any. Does C perhaps give a slightly lower level of control than C++? Or does C++ contain ALL (as in every last bit) of C's low level functionality? Any insights and even random opinions are appreciated.

##### Share on other sites
My random opinion is that cows are nicer the horses.

My not-so-random opinion is that all C programs should (iirc) run using C++, so C++ should have everything that C has.

##### Share on other sites
Quote:
 Original post by Nice CoderMy random opinion is that cows are nicer the horses.My not-so-random opinion is that all C programs should (iirc) run using C++, so C++ should have everything that C has.

C99 has features that make it incompatible with C++ though. And I thought there were a few others before C99 as well...

##### Share on other sites
This page outlines the differences between the two. Designated initializers and restricted pointers are a couple examples of features that C++ lacks.

##### Share on other sites
No, It's a picture of a C vs. C++ thread...

Ok, sorry.

IMO, C++ is more or less a superset of C. Some things - as listed earlier - aren't but those features are rarely used AFAIK and easily done in different ways.

That said, C++ is generally considered slower, mainly because of the bells and whistles that it has. Classes themselves don't add a particularly significant overhead [ie none in release mode], but if you have stuff like RTTI [real time type identification] then there's the overhead. Throwing exceptions has an overhead in every function that they throw to IIRC.

That said, asembly-wise, the code generated should be pretty similar. In some situations, C is faster, particularly when you're dealing with uber-tight calling loops on singleton-pattern objects... something like:

for (int i=0; i<this->indexes; i++)
{
this->pushVertex(this->index[i]);
}

Mainly because you know that there's only going to be one this pointer, and you can store your data one dereference closer to the application. In C++, the compiler has to actually send in a this*. And dereference this->index[i].

In C, this process would basically be:
if i>=indices jump out
call pushVertex(index+i)
jump back to start

In C++, this process would be
if i>=&obj->indices jump out
call pushVertex(&obj, &obj->index+i)
jump back to start

This is where C is naturally faster than C++.

As far as I understand it, speedwise, if you don't use any of the fancy features of C++, like classes, then the compilers will generate basically the same assembly. Which means the same speed. For me, it really comes down to convenience - I _like_ some of the features that C++ holds over C.

I think I'm done ranting. I hope everything here is true, but I'm no expert in C.

--CJM

##### Share on other sites
I like C. Its biggest advantage is that people can't go crazy with their code, i.e., develope a templated polymorphic RTTI multiple-inheritance class structure when some crafty C (or C-style) code does the same thing but far simpler, faster, and more robust.

But whenever I write in C I sorely find myself missing std::string and std::vector, and having to deal with pointer nonsense avoidable with references.

##### Share on other sites
Quote:
 This is not a C vs. C++ thread...
Yeah right!

Now, don't think of pink elephants. Wait, I said ... oh never mind.

##### Share on other sites
Quote:
 Original post by etothexI like C. Its biggest advantage is that people can't go crazy with their code, i.e., develope a templated polymorphic RTTI multiple-inheritance class structure when some crafty C (or C-style) code does the same thing but far simpler, faster, and more robust.

Heh. You haven't seen die-hard C programmers and the macros they write.

Anyways, at this point, the primary advantage of C is that it is really easy to write a C compiler for an arbitrary given platform. Because of this, it's often the language of choice for embedded platforms.

(BTW: keep in mind that the page dcosborn posted refers specifically to C99, which is not widely implemented.)

##### Share on other sites
C also benefits of having a standardized ABI. Most languages are designed to interface with that ABI. Most libraries offer C bindings, regardless of what language they actually were written in.

This is why C++ has that extern "C" construct, after all.

##### Share on other sites
Quote:
Original post by Sneftel
Quote:
 Original post by etothexI like C. Its biggest advantage is that people can't go crazy with their code, i.e., develope a templated polymorphic RTTI multiple-inheritance class structure when some crafty C (or C-style) code does the same thing but far simpler, faster, and more robust.

Heh. You haven't seen die-hard C programmers and the macros they write.

Anyways, at this point, the primary advantage of C is that it is really easy to write a C compiler for an arbitrary given platform. Because of this, it's often the language of choice for embedded platforms.

(BTW: keep in mind that the page dcosborn posted refers specifically to C99, which is not widely implemented.)

LOL, I have seen some crazy macros. They're just as bad as the overkill C++ people.

But at least with macros you can preprocess it to something useful :) Also C99 roxxors and you don't even have to use macros...well...most of the time

##### Share on other sites
Quote:
 Original post by etothexBut at least with macros you can preprocess it to something useful :) Also C99 roxxors and you don't even have to use macros...well...most of the time

The problem with macros is that they exist outside of the language. And with C++, you don't *have* to use the more obscure features either. [smile]

##### Share on other sites
Basically C tends to optimise better (read 'is easier to optimise') and support across compilers tends to be more consistant (more advanced C++ features tend to be somewhat less consistently implemented - for example metatemplate programming, which effectively wasn't supported by MSVC until VC7.1). Also some of the features of C++ can lead to the famed 'code bloat'. Generally this is most problematic to embeded software engineers (like myself, which is why we stick with C).

In many ways C can be regarded as a lowest common denominator - it is well supported across most platforms where as C++ isn't necessarily. C++ has nice features but, either through poor support or unacceptably high penalties (in a given context), the engineering judgement is not in C++'s favour.

##### Share on other sites
There's nothing in C++ that makes it inherantly slower, when people make the assertion that C++ is somehow slower, they generally mean that some C++ code hides the real code from the programmer. Things like constructors, implicit conversions, operator overloads, and "hidden" constructors as a result of returning a class by value. A specific example of this might be an overloaded multiplication operator in a matrix class. In the code you see M1 * M2 and it doesn't appear to be a big deal, however behind the scenes there are severall multiplies and adds. Somehow, a C-style mulMatrix(M1, M2) tends to make us think more about the performance implications behind the code. Though, really, this is more an issue of the programmer ignorance than an inherent flaw in C++, in fact, its a by-product of the fact that C++ classes, by design, are intended to give a higher level of abstraction. Of course, C++ classes can be designed efficiently with a good understanding of how the language and compiler work.

Some C features not present in C++ at this time do allow for optimizations that are currently impossible in C++. The restrict keyword which has been mentioned already allows the compiler to assume that the contents of pointers do not overlap, allowing the compiler to perform faster copies that would be unsafe without that assumption. Hopefully, C++ will be getting the restrict keyword in the next revision.

##### Share on other sites
Thanks for all the great replies so far. I'm checking out a few of the links now.

##### Share on other sites
Quote:
Original post by Fruny
Quote:
 Original post by etothexBut at least with macros you can preprocess it to something useful :) Also C99 roxxors and you don't even have to use macros...well...most of the time

The problem with macros is that they exist outside of the language. And with C++, you don't *have* to use the more obscure features either. [smile]

well my complaint is that people don't have to use them (but do regularly, even when unnecessary) There's the same problem with C, but fortunately there aren't as many obscure features and macros and non-typesafe code are frowned upon.

all this is moot if you're working with people who know what they are doing. In which case language is largely irrelevant. (and c++ is a cool compromise)

##### Share on other sites
Quote:
 Original post by etothexall this is moot if you're working with people who know what they are doing. In which case language is largely irrelevant. (and c++ is a cool compromise)

The problem as I see it is that people aren't really encouraged to "know what they are doing", but rather inherit a whole set of superstitions, both from teachers and from other mediocre programmers. </rant>

##### Share on other sites
Quote:
 Original post by Ned_KC99 has features that make it incompatible with C++ though. And I thought there were a few others before C99 as well...

The current C++ standard is superset of C90, there are proposals to incorporate all additions of C99 in the next standard revision.

Also there are talks of both standards do something that prevents C and C++ diverging like as of current with C99 and C++03 TC1 like making some kind of joint standards committee or something similar such that C++ is always a true superset of C.

Going back to the question, as far as i'm concerned writing C code in purely procedural way may generate more efficient code than C++, which highly doubt since it's compilable in a C++ compiler (if it's C90 compliant and even in some cases for C99 with language extensions) and you can typically can disable stuff like RTTI by setting flags/options in the compiler.

However writing C code that emulates some of C++'s features and/or extra paradigms it supports in C will not be more efficent and isn't candidate for optimizations because those are not standardized features in C. You'll be hard press to out do a C++ compiler with your equivalent hand-written repetitive boilerplate C code. So really this is all moot.

[Edited by - snk_kid on January 12, 2006 4:07:33 AM]

##### Share on other sites
Quote:
 Original post by Ned_KI don't want a battle on which language is better, C or C++. Rather, are there certain things that C does more effectively than C++? I am already aware of the advantages of C++ with object oriented programming and the like, though I am currently only programming in C for classes and my own practice.

I spent years programming in C, and years programming in C++.

It is my opinion that C++ is an order of magnitude "better" than C, because it allows me to not have to worry about a lot of low level stuff with any runtime cost. That said, I've got decades of experience with both languages and have learned how to avoid most of the costlier hazards of C++ (though I continue to make the same hazardous errors in C).

C++ will do anything C will do, since it's a superset (yes, C99 added restricted pointers to do what a C++ compiler will already do with references, and it added "overloads" of math functions already in C++, but that was to catch up with C++). C++ can also produce faster code than C in many circumstances (eg. qsort() vs. std::sort()).

C++ was designed with the idea in mind (unlike competing languages like Java and C#) that if you don't use a feature, you shouldn't pay for it. Generally speaking, the cost of using a feature is the same as the cost of doing it yourself in C. For example, the cost of using a virtual function in C++ is the same, or cheaper, than the cost of a function lookup table and explicit indirection in C. The cost of passing an implicit "this" pointer in C++ is the same as explicitly passing a pointer to a data object in C. The list goes on.

Some will argue that they can accomplish the same thing in C as a C++ programmer could in that language, but on closer examination I find they have always meant they can accomplish less, but do it quicker. For example, it's faster to ignore return status values and not have error handling than it is to throw an exception. They are comparing apples and oranges.

The is no doubt C wins hands down when it comes to distributing software, since most major platforms ship with the C runtime. If they ship with the C++ runtime, it may not be the one for the compiler, or version of the compiler, that your program was compiled with. Runtime loadable modules run into the same problem: they may not be compatible with the program they are loaded or dynamically linked to. You end up either statically linking the runtime (huge executables), shipping your own copy of the dynamically-loaded runtime (effectively the same as static linking), or in the case of DSOs, wrapping everything in an 'extern C' interface.

So, in short there is nothing you can do in C that you can't do as well or better in C++, except distrubte software in a hassle-free way.

##### Share on other sites
Much as I am a C addict I am coming round to C++. Some measurements I made with gcc (4.0) not long ago seemed to indicate some odd overhead to doing certain things (e.g. vector maths as C++ inline operators against C macros), but it wasn't very big and was probably more or less down to luck of the draw you get with optimized assembler generation. The things about C++ I find difficult are the fact that it's very easy to do something very badly (std::list.size() != 0 for instance) and not really realize it, which is not a problem I've ever had in C.

All that aside, I think C++ itself is dying for a couple of features: the typeof operator (as in gcc), and something like Ds static if for templates (templates in D are far inferior to C++ though). Less incomprehensible error messages would also be a major bonus.

##### Share on other sites
Quote:
 Original post by RavyneThere's nothing in C++ that makes it inherantly slower, when people make the assertion that C++ is somehow slower, they generally mean that some C++ code hides the real code from the programmer. Things like constructors, implicit conversions, operator overloads, and "hidden" constructors as a result of returning a class by value. A specific example of this might be an overloaded multiplication operator in a matrix class. In the code you see M1 * M2 and it doesn't appear to be a big deal, however behind the scenes there are severall multiplies and adds. Somehow, a C-style mulMatrix(M1, M2) tends to make us think more about the performance implications behind the code. Though, really, this is more an issue of the programmer ignorance than an inherent flaw in C++, in fact, its a by-product of the fact that C++ classes, by design, are intended to give a higher level of abstraction. Of course, C++ classes can be designed efficiently with a good understanding of how the language and compiler work.

I think everyone should read this again. This is the only reason C is/can be faster than C++. One of the guiding principles behind C++ is "If you don't use it you don't pay for it" (hence instance functions are by default non-virtual, even though I've heard many argue that virtual functions better fit the idea of OO (and are more common in other OO languages)).

The two biggest incompatibilities between C and C++ are (in my opinion) interpretation of the const keyword and C++ not allowing implicit conversions from void *. Basically:
const size_t D_SIZE = 20;double *d = (double *)malloc(D_SIZE * sizeof *d);

is neither good C nor good C++. (#define is usually better than const in C, shouldn't cast malloc in C, should use new (or, better yet, std::vector) in C++)

The biggest advantages of C over C++:
- C works with everything (you have to turn off C++'s name mangling with extern "C" if you want to interface with other code)
- 100% standard compliant implementations of C89 are common (I think there's only one 100% compliant C++ compiler?)
- Simpler language, less chance of someone using a feature you aren't familiar with
The biggest advantages of C++ over C:
- Better abstraction (I'm a big fan of RAII)
- Better tools for large development (namespace/class to group things)

That said, I usually prefer C (personal preference, YMMV, and probably does).

##### Share on other sites
Quote:
 Original post by Way WalkerI think everyone should read this again. This is the only reason C is/can be faster than C++.

Technically no longer true (see keyword 'restrict'). Of course, that's a "can be". "is" is meaningless to compare the speeds of languages.

Is a highway "faster" than a road? You probably can drive as fast on the road, if you don't get caught. But it's a totally meaningless thing to say, because neither the highway nor the road *itself moves at all*.

##### Share on other sites
Quote:
Original post by Zahlman
Quote:
 Original post by Way WalkerI think everyone should read this again. This is the only reason C is/can be faster than C++.

Technically no longer true (see keyword 'restrict'). Of course, that's a "can be". "is" is meaningless to compare the speeds of languages.

Is a highway "faster" than a road? You probably can drive as fast on the road, if you don't get caught. But it's a totally meaningless thing to say, because neither the highway nor the road *itself moves at all*.

Wow, I just typed a whole thing about how it actually is meaningful to say one language "is" faster than another, but then realized it's off topic. So, here's the on topic portion of my post:

How many compilers take advantage of the restrict keyword? I'm honestly curious.

Something I'm less curious about is the state of C99: It hasn't really caught on. C89 (or, more correctly, C94, I suppose) is still the standard most C programs/implementations are based on.

In any case, the part I quoted is still the main contributor to C being faster than C++. C forces you to do more things explicitly which has two consequences:
1) You're likely to use a method that requires less typing (which, in general, means the code is doing less)
2) You're likely to be more aware of when you're doing something expensive (which makes you more likely to find a cheaper way to do it)

##### Share on other sites

This topic is 4355 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628707
• Total Posts
2984313

• 23
• 11
• 9
• 13
• 14