Paul said:
I agree with you folks, we can't compare every thing with every thing
else. But in my profession as a programmer, I many times encounter a
word "Portability" and a phrase "C is Portable across platforms". Some
of the projects in which I was involved where C++ is a best fit, my
boss chose C defeating us with that one word. This is just because not
all platforms have a C++ compiler. Then it makes me wonder is it a
right decision and why are we forced to use C just for the sake of
PORTABILITY (modular) where C++ (OOAD) would have been better.
Hmmm, from my (biased) viewpoint, that sounds great, where do you
find a boss who thinks like that? Usually, it's been me (as a
non-boss) who has felt that there are hidden "synergistic"
advantages (future-looking) to using C over C++ (in *some*
instances), while the boss/corporate-thinker types have insisted
on using C++, not always in problem domains where there were
obvious advantages to that (again IMO).
The fact of the matter is that, with discipline, one can use OO
methodologies with C, and often one should. C++ provides more
out-of-box support for that, obviously; but conversely, it is
sadly all too possible to program in non-OO (or otherwise
braindead) ways, using C++ or any other "trendy" language.
I think managers like C++ because of the *perception* that it
can somehow "force" better programming practices, but although
it can perhaps do so in some of the "small" ways, it's just as
encumbent upon the individual programmer to enforce good practices
on him/herself, or else the "big picture" ends up just as much of
a scrambled, bug-prone mess as it can with C. The tired old quip
rears its head again: one can write crap code in any language.
The reality is that C (meaning, C89/90) *is* much more portable than
almost any other language. The fact that it is both easy and (perhaps
more importantly) commercially compelling to write a C compiler for
every new platform, from the smallest to the largest, is IMO not
something to overlook. Sure, if you *know* your product is only
going to be deployed on a single architecture, or a narrow range
of architectures (e.g., a big GUI app intended for desktops, with
no danger of being ported to Palm Pilots or embedded nanobots based
on (what else) the 8051 core), then the equation tilts one way.
My opinion has always been (well, or has become) that *if* it can sanely
be written in C, then it should be: I view it as a form of "strength
reduction", like refactoring an old-school multi-chip 74-series
logic design to use fewer different chip numbers from the family,
or more-common ones.
I view C++ and other such languages more like specialized libraries: they
are great and powerful if they address the need at hand; but if you
can get by equally well without them, then it's better to not
introduce the sensitive dependence on a moving target that may not
support all your future directions and platform choices. People keep
claiming that C is a dying language, but here's my prediction: in 100
years, C++ will be long-gone, replaced by shiny new languages that we
can hardly imagine at this point. But C (and the music of the Beatles)
will still be around. In fact, I'll bet a virtual beer on that (I hope
my offspring come to share my love of C...).
If you are required to use C and you'd rather be using C++, and the
*only* excuse "they" have for forcing the use of C is "portability",
then perhaps something like cfront might be of interest (if only for
a rhetorical point when making your case to the brass...).
--Benjamin