Bill Pursell said:
Use C when it's appropriate.
Better advice would be "use the *most* appropriate tool for the job". The
choice of "most appropriate tool" depends on the job, the tools available,
the various (and often conflicting) requirements of efficiency,
portability, ease of maintenance, development time constraints, and
familiarity. It would (probably) be very unwise to write a C program to
process a business transaction, however easy that might be for you, if the
other 10,000,000 lines of the suite are written in COBOL, because most of
the available maintenance expertise is going to be in COBOL, not C. But if
you're starting a new project and picking a brand new team (or going it
alone), you might well look at Python and Perl and so on for your text
processing application, and then think to yourself, "sheesh, I'd be much
happier writing this in C, simply because I know C so much better, so I'd
find it easier to write, easier to read, easier to debug..."
If you are writing a program
in C++, you may end up writing a lot of low-level routines
that are perfectly valid C. If at that time you recognize that
you are writing C, it increases the flexibility of your code
if you compile those sections as C and create a C library,
and then use them from C++, since they will also
be useable from C applications.
Agreed.
Some people argue that C++ makes it easier to program,
I, on the other hand, would argue that sticking with what you know makes it
easier to program in the short term. That isn't necessarily the best
choice, though.
Just the other day, I found myself about 20 lines into a C program, when I
thought, "hmmm, to do *this*, I'm going to need to do *that*, which means
I'll have to write some routines to do *the other*, and by the time I've
done *that*, I'll have implemented about half the STL - so why not just use
C++ and save myself a lot of time?" So I did.
but this is often because they lack sufficient knowledge
of how to apply object-oriented programming techniques
in their C-code. In my (limited experience), C++ tends to
encourage difficult to maintain, hideous crap that is
just annoying to read.
Then I suggest you spend a little time developing your ability to write
easily maintainable, non-hideous, jewels of C++ that are a delight to read.
It isn't easy! But it is certainly possible.
The STL is an extremely nice feature of C++, but it
is often horribly inefficient.
I agree, but often it doesn't matter, because "horribly inefficient" is a
relative term. When I use the STL, I am sacrificing a certain amount of
performance in favour of ease of writing, ease of reading, and ease of
maintenance. If I can save myself 40 hours of development time and end up
with a program which runs in 10 seconds using STL, when my own hand-written
C routines might be able to perform the same task in 8 seconds, then I'm
likely to jump at the chance *unless* those extra 2 seconds become a
significant part of the equation. Let's simplify matters, and assume I'm
the only person who will ever run the program. If so, then my payoff for
using C comes only when I run the program for the 72001st time(!). If, on
the other hand, I have many users lined up for the program, then the
equation changes. Even then, it might be worth writing the C++ version
simply to get the users up and running, and then re-writing it in C if and
only if I start to get a lot of complaints about performance.
The data structures are
designed to be flexible and generic, and as a result
they are not the perfect match for any programming
situation. When you code in C or C++, one of
the primary reasons for that language choice is
speed...so why kill yourself on the performance side
by using overly generic data structures?
Because "killing yourself" isn't the only choice. C++'s "overly generic"
data structures are nevertheless no slouches at performance. Yes, maybe you
can beat them with customised routines, but those customised routines take
time to write and get right. If the payoff is worth it, by all means do so,
but don't just *assume* that the payoff will be worth it.
I will freely acknowledge that I have a strong bias
against C++.
So do I. It's only my *second* favourite language.
I think I've met 3 people who write C++
code that doesn't make me vomit.
I suggest that you consult a doctor.
Several C++
coders I know have expressed such amazing
ignorance of C as [...]
Well, we can't blame the language for its users!
In summary, use C when it is appropriate,
and use C++ never.
....except when it is appropriate. Or, better still, use the best tool for
the job.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: normal service will be restored as soon as possible. Please do not
adjust your email clients.
