Re: c code vs c++ code

[Steve Baker <sjbaker1@airmail.net>]

Gregor Mückl wrote:
> Steve Baker wrote:
>> 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).

That's a *stupid* example.

The IOCCC contains DELIBERATELY OBFUSCATED C code.

Trust me - if there was an IOC++CC, things would be *MUCH* nastier.

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

Let's see - we'll overload the '+' operator between integers to 
implement addition of factorials of it's parameters and unary minus
to perform a square-root - we'll swap multiply and divide.

...if you *wanted* to obfuscate C++, it would be horrific.

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

I'm not a big fan of STL either - most of the objects it provides
can be written in a matter of moments - avoiding the overheads caused
by flexibility and checking that you don't need in your application.

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

There have been problems with portability of STL in the past - but
I think they are largely solved these days.

> You can produce reliable code either way. But you need a lot of 
> experience to do that.

Agreed - I've been programming for thirty years.  I learned C on
UNIX version 6 on a PDP-11 and used a pre-release version of AT&T's
C++ translatores before Bjarne officially released it.

I've been bitten too many times by some of the fancier C++ features -
hence my preference for using a self-imposed "C with classes" subset.

Derived classes are great - virtual functions are amazingly powerful
if used intelligently.  OTOH: Multiple inheritance is *death* - avoid
it like the plague.

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

(Yeah - like *ALL* of them!)

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

Right - so don't use those things.  If the language feature isn't
making you more productive why the heck would you want to use it?

"Because it's in the standard" - is not an acceptable answer.

The C++ standard is produced by people who live, breathe and die
understanding the subtle details of 'correctness' and 'type safety'.
I doubt that any of them write computer games for a living.

I'll bet that you know more about the subject area you work in than
the compiler experts and language lawyers.   So - why would you take
their advice on what language features are good for you?

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

I didn't know that.  Wow.

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