C vs C++? 2

[cpjust]

Hi,
I've seen some job listings for plain C programmers, so I was wondering... other than for maintaining existing C code, is there any reason why someone would choose to start a new program in C rather than C++?

 

[WebDrake]

Number-crunching code, for starters, can be much faster in C with its relatively simple variable types and operations, than in C++. Any introduction of C++ objects slows down code. Just compare the performance of code using ordinary arrays versus the C++ vector structure.

C++ vector, however, is useful in its own right for other things, as are objects in general. Generally you're faced with a tradeoff between ease of coding (you can program faster and with more elegant notation in C++) and speed of the result. With many computer programs that speed difference doesn't matter, but if you're running serious number-crunching code, it does.

This applies even within C: using structs, for example, can allow for more elegant programming but can slow down code.

 

[chipperMDW]

Here's what the GNU Coding Standards say about using C instead of C++ specifically for writing Free Software.

When you want to use a language that gets compiled and runs at high speed, the best language to use is C. Using another language is like using a non-standard feature: it will cause trouble for users. Even if GCC supports the other language, users may find it inconvenient to have to install the compiler for that other language in order to build your program. For example, if you write your program in C++, people will have to install the GNU C++ compiler in order to compile your program.

C has one other advantage over C++ and other compiled languages: more people know C, so more people will find it easy to read and modify the program if it is written in C.

So in general it is much better to use C, rather than the comparable alternatives.

So the Free Software Foundation, at least, thinks there's a reason to write a new program in C instead of C++.

 

[DaveSinkula]

In embedded systems, there are often two choices: C or assembly.

 

[cpjust]

I don't know much about embedded systems, but from everything I've learned so far, the tendancy seems to be to write stable, modular software in C++. Then only once you're finished, you measure the performance and optimize areas where you've proven there to be an unacceptable level of efficency...

I guess I can understand where you'd have to fall back onto C on systems that don't support things like exceptions. I definitely don't agree with that GNU suggestion though. You can't hold back progress just because it requires people to install g++ on top of gcc. They could have made the same argument about switching from Assembly to C.

That quote sounds kind of old too if it says that more people know C than C++. Most of the new Computer Science graduates I've seen know all about object oriented programming, but they've never used malloc() and don't know anything about bitwise operators...

 

[DaveSinkula]

With 2 choices for 99% of micros, it's often quite easy for me to choose not to use something I can't. Although the bigger chips are out there somewhere, I rarely see them. Nor do I see the C++ compilers for the micros I don't see.

 

[xwb]

If you have code that is supposed to work over several platforms, C is a lot simpler to port and maintain than C++. Some of the C++ compilers don't even support templates so if you are coding in C++, it has to be a very basic form. Java doesn't exist on some of these platforms so that doesn't even come into the picture.

There is also the problem of <iostream> and <iostream.h>. The ones that don't support templates still use <iostream.h>.

 

[Salem]

Certainly for a desktop environment, using C++ for large scale new code would seem to be the sensible choice. The compilers and tools are readily available, and the various downsides which make C++ awkward for embedded work don't apply.

Performance:
This is really down to the skill (or lack of) of the programmer rather than the language. A bubble sort in C is just as sucky as a bubble sort in C++.

I don't think there is anything inherently poor about C++ performance (plenty of C++ code looks pretty zippy to me), but there is more scope for programmers to abuse the features on offer. What might be harder to do however is figuring out which C++ constructs are more expensive than others. In addition, the degree of performance difference across several compilers for the same construct could also vary quite widely.

I'd certainly prefer C++ over whatever macro-fest gets invented to try and support 'OO' on top of C.
One thing which C++ has (officially) over C is inline functions. Sure, you can use macros in C but that's a whole new can-o-worms.

Then only once you're finished, you measure the performance and optimize areas where you've proven there to be an unacceptable level of efficency...

My sentiment exactly!.

Portability:
xwb brings up and interesting point, and is one which I've recently come across as well. C++ compilers for embedded platforms in particular vary quite widely in their degree of C++ support.

Availability:
As already mentioned by Dave, nearly every embedded processor gets a C compiler, but it's only the higher end and wider market processors which get a C++ compiler.

Maturity:
Modern C++ in all it's full glory is a pretty large language, and coming up with a compiler which implements the whole language efficiently is no small task.
Another problem is that it's also a lot for a programmer to learn how to use all of it well. It seems to me that C++ programmers will end up using some favoured subset, and in a group environment, the common ground will be an even smaller subset.

A good C compiler is comparatively easy to write, and as a language its not that hard to get reasonably comforable with all of it.

Bootstrap:
Again for the embedded side of things, the amount of assembler you need to craft to establish a 'C' runtime environment is pretty small.

--

 

[WebDrake]

I don't think there is anything inherently poor about C++ performance (plenty of C++ code looks pretty zippy to me), but there is more scope for programmers to abuse the features on offer. What might be harder to do however is figuring out which C++ constructs are more expensive than others. In addition, the degree of performance difference across several compilers for the same construct could also vary quite widely.

Yep, that's pretty much what I was getting at, but better put. If I take a piece of number-crunching code I've written in ANSI C and compile it instead with a C++ compiler, the performance difference will likely be negligible.

But let's take an example like this: suppose I have a function,

int f(int a, int b, int c)
{
   /* I do stuff with a, b and c */
}

Perhaps it might be convenient instead to pass a struct containing three integers,

int f(struct threeint *T)
{
   /* Now instead I use T->a, T->b and T->c */
}

In my experience the second function will be slightly slower than the first, whether in C or C++. Most of the time it's unnoticeable but if I'm calling the function 10 million times, you'll start to notice. My impression is that the added complexity of the data type sent to the function makes optimization less easy.

In this case it's a trivial example, but it's not so difficult to think of cases where passing structs might be preferable for coding elegance, but would slow down code.

Anyway, my impression is that in the same way, C++ objects---which are again more complex data types---have a similar effect of creating slower code, but with the benefit that the code becomes much more elegant, easy to read and quicker to write.

In many programming cases this is much more important than absolute speed, which is why in many complex programs C++ (or sometimes slower but even more elegant languages like Java, LISP, Perl, Ruby, Python...) can make more sense than C.

However, getting the algorithms right is by far the most important thing in terms of fast code, in my experience.

 

[adrstan1]

There are some domains in which C is usually preffered to C++:
- compiler development
- kernel development, device drivers, ...
- embedded development

Usually, the C code is faster than C++ code doing the same.
But there are exception to this rules. One is using functors in C++ instead of function pointers, since it may give the possibility to the C++ compiler to inline the function.

One advantage of C++ would be the speed of application development (specially if one is using templates and STL). Unfortunately the same can lead to performance problem (the code using STL tends to execute quite slow).

Unfortunately writing C++ code to be portable across platforms and compilers can be a tough cookie.
You can take a look on the Mozilla site, they have and ad-hoc set of rules to write C++ code as portable as possible.

I personally use C++ in most of the situations, it fits fine in my case

 

[ArkM]

WebDrake,
in your example above the 2nd function must be:

int f(struct threeint T) { ... }

(pass by value, as in the 1st function). The 2nd function (pass a pointer or pass a reference in C++) has different semantics (can modify argument).
I think pass-struct-by-value variant has the same speed (because of it uses direct stack addressing as the 1st variant).
Or compare the 2nd with (obviously slow) semantically identical

int f(int* pa, int* pb, int* pc) { ... }

Apropos, C++ STL number-cranching data structure is not a vector, it's (a very efficient and as usually not safe valarray...

 

[WebDrake]

(pass by value, as in the 1st function)

Oops, well, not surprising, since I really don't use C++ at all; I was using C syntax, and just quoting it as an example of how something like a struct, or an object, which can create easier notation and more elegant code, can have a negative effect on performance.

In C, anyway, I always use typedef with structures, so I can write things like,

int f(alienspaceship *T) { ... }

;-)

 

[WebDrake]

Whoops, I got the wrong end of the stick there. Yes, of course, to be comparable you'd have to pass the struct by value rather than passing a pointer.

In the actual practical case where I was doing something like this, and tried both the notationally efficient method of using a struct, versus the more fiddly method of passing everything separately, it was absolutely necessary that I pass pointers rather than values, because modification was necessary. And sadly (because it allowed much easier code) the struct was slower. :-(

It's interesting you cite passing the int *'s as slow; I remember being told that, unless it was absolutely necessary to use a piece of data destructively, passing pointers was more efficient, although I imagine it would depend on the situation. Mind you, sizeof(pointer) versus sizeof(int) is identical. Any thoughts on that?