Back to General and Gameplay Programming

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

General and Gameplay Programming Programming

Started by Ned_K January 11, 2006 11:53 PM

20 comments, last by Way Walker 18 years, 3 months ago

1,658

January 12, 2006 02:19 AM

Quote:Original post by etothex
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

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]

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan

Anonymous

January 12, 2006 02:38 AM

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.

Ravyne

14,306

January 12, 2006 02:39 AM

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.

throw table_exception("(? ???)? ? ???");

Ned_K

175

Author

January 12, 2006 02:42 AM

Thanks for all the great replies so far. I'm checking out a few of the links now.

etothex

728

January 12, 2006 03:00 AM

Quote:Original post by Fruny
Quote:Original post by etothex
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

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)

Fruny

1,658

January 12, 2006 03:17 AM

Quote:Original post by etothex
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)

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>

snk_kid

1,312

January 12, 2006 04:07 AM

Quote:Original post by Ned_K
C99 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]

Bregma

9,461

January 12, 2006 08:33 AM

Quote:Original post by Ned_K
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 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.

Stephen M. Webb
Professional Free Software Developer

ZQJ

496

January 12, 2006 09:09 AM

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.

Way Walker

745

January 12, 2006 12:57 PM

Quote:Original post by Ravyne
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.

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:
- More information available on the internet (in my experience)
- 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).

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

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

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

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines