Re: c code vs c++ code

[Gregor Mückl <GregorMueckl@gmx.de>]

Steve Baker wrote:

> Jason Stechschulte wrote:
>
> > The main reason I started trying to write games in Linux was to re-learn
> > C++.  I hadn't used it since my University days roughly 5 years ago.
> > Now I'm feeling comfortable with it once again, so I started downloading
> > other open source games and looking through the source code.
> >
> > I noticed that most games that are written using C++ code still use C
> > code for many things.
>
>
>     Caveat: Language debates make for LONG and painful flame wars.
>     In the end, everyone has their opinions.
>     However, I write in the style you are talking about and I'll
>     explain why.  There is no need for the "use all of C++" guys to
>     try to pursuade me otherwise.  I've been using C++ since the very
>     first AT&T C++ translator - written by Bjarne himself.
>
> Although C++ is the only language I use on a regular basis, I think it
> is cluttered, overly complex and very hard to understand if you use all
> of it's features.
>
> C is relatively clean and simple - but lacks classes - and
> Object-Oriented programming is the best new language paradigm
> since the discovery of Structured Programming.


I agree so far except that C code can be rather obfuscated 
(http://www.ioccc.org is the prime reference :) - I've never seen C++ 
which is that bad). But I must say that I haven't seen too much C++ code 
yet that I could not understand (and even then it was mostly because of 
some C++ syntax element I haven't seen before). Maybe I just haven't 
seen the real challenges yet.

>
> So, I tend to program in some kind of intermediate language which
> I guess you'd have to call "Object Oriented C".  C+ maybe.  :-)
>
> So, I still use the C standard I/O library - but I use classes,
> derived classes, virtual functions, overloaded functions, inlined
> functions and optional arguments.  But I steer clear of exceptions,
> templates, streams and all the rest of the C++ fluff.

I tend to use all of the C++ features, especially templates. I haven't 
tested it but I think that you can get some really fast code using 
templates. And the STL provides a good set of helpers for many situations.

But there is one argument for staying clear of the STL: some (especially 
older) implementations might be seriously broken and incomplete. I don't 
know the state of other implementations, but the one shipping with gcc 
2.x is incomplete (no binary streams, incomplete container support).

>
> That's a personal thing - but it's what I'm most comfortable
> and productive with.  I know a lot of people who use all of
> C++'s bells and whistles - and people who never got into classes
> at all - none of them write code with the speed and reliability
> that I do.

You can produce reliable code either way. But you need a lot of 
experience to do that. Over time you tend to write in a style you feel 
most comfortable with. Both C and C++ have the tendency to force 
restrictions on the programmer to be able to output maintainable code.

>
> Bjarne Stroustrup (who invented C++) once famously said:
>
>        "C makes it easy to shoot yourself in the foot;
>         C++ makes it  harder, but when you do,
>         it blows away your whole leg."
>
> That's a very true - and honest - expression of the situation.
>
> However, in my opinion, there is a happy medium - where it's
> sufficiently difficult to shoot yourself that you don't do it
> too often - but when you do, the size of the wound is tolerable.
>
> > I'm wondering if there is some benefit to using the C code rather than
> > the C++ code.  Is it possibly better for porting to other systems?  Or
> > is it simply programmer preference?
>
>
> Programmer preference - I'm sure.

Not quite. In C you can almost see the assembly when you look at the C 
code. The translation is pretty straightforward. C++ is not that 
transparent. You can have really nasty side effects in simple-looking 
code (the STL container classes are famous examples for this). This 
makes writing fast code in C++ a bit harder than in C. Still, it is 
possible. If you write really clever C++ code I dare say that you can 
even be a bit fastern using some extra compiler optimisations in your favor.

>
> > Since there is a standard for C++, I would think that it is probably
> > because the programmer is more familiar with C and is used to using it.
>
>
> No - I'm quite familiar with all the bits of C++ that I don't use.

Furthermore, there are compilers out there that claim to be C++ 
compatible, but don't implement the full standard. So you should 
carefully decide which C++ features you actually use. I know a very 
common compiler which doesn't fully support templates (I remember that 
because I had to work around it in a particularly ugly manner).

>
>
> > I know that C code is normally faster than C++ code...
>
>
> That's not true.  C++ *allows* you to write code that's much less
> efficient than C does - but it doesn't force you to.

But sometimes I find it really tempting, though. You can really "blow 
away your leg" if you are not aware of what you are doing and the inner 
workings of the code you're using.

> IMHO, stream I/O was originally just an example of how you could
> use operator overloading to change the way a subsystem like file I/O
> works.  I don't think Bjarne originally intended it to be THE ONE
> TRUE WAY to do file I/O.
>
> There was nothing wrong with stdio - it was a non-problem and it
> didn't need fixing.  You can argue that's not the case - but just
> look at the numbers of people who still use it in preference to
> stream I/O.

Especially on Linux there is a second reason for using stdio. C++ 
streams don't implement binary IO, at least not with a pre-3.0 GCC.

Gregor