[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: c code vs c++ code

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.

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.

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.

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.

> 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.

> 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.

The first C++ implementation (which I used for a couple of years)
was a translator from C++ into C.  You could see that the lines of
C code it produced were simple and there weren't large numbers of

> but I wouldn't
> think that file handling would be something that needed to be highly
> optimized for speed.

No - but I just dislike overloading operators - it leads to *nasty*
suprises and extremely subtle bugs of the "blow your leg off" kind.

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.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net>    WorkEmail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net