[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: c code vs c++ code
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: <firstname.lastname@example.org> WorkEmail: <email@example.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net http://tuxaqfh.sf.net