Andrew Martin (martin at bsm.bioc.ucl.ac.uk) wrote:
: David Mathog (mathog at seqvax.caltech.edu) wrote:
: : >Anything which can be expressed in C++ can be expressed in C
: : >(which is what Cfront does), but good C++ is much more readable,
: : >reusable, and maintainable.
: Only if you're familiar with C++ syntax!
C++ syntax, for both good and evil, is not very different from C syntax.
One major new motif (object.member) and a sprinkling of little things.
: I've been programming in C for
: several years and thought about moving to C++, but the effort involved
: simply doesn't seem worth it. I have built up an extensive library of routines
: for protein structure handling in C; they are all modular and, in that sense
: can be treated as `objects'. Recoding all this as C++ classes would take
: me ages! If C is well written in a modular form, it can be just as readable,
: reusable and maintainable as C++. Object orientation is a methodology
: which can be applied (in some fashion) to any programming language.
Agreed. But having a language which supports the methodology helps a
lot. And again, I am not suggesting you recode all your libraries as classes;
I am only asking that I not be required to recode my classes into C.
Also, I really think there are limits to how much OOP-techniques
can help you in a non-OOP language. For an example, I offer you the
NCBI Toolkit. A very nice piece of work -- powerful, reasonably well
documented, showing clear OOP but written in C. Now both of you
out there who use it regularly, raise your hands :-)
Seriously, the lack of inheritance
(due to the language not supporting it) oozes from
every seam. Almost everything gets passed in a type-unsafe manner,
because there is no inheritance. You have to really stare at the
documentation to figure out which types of pointers you should be
passing. And long names to the functions, due to no name
overloading.
There's all sorts of set-up and take-down the programmer
must remember (no constructors and destructors after all), including
an unsettling hack surrounding your main program. Plus, whenever the
programmers didn't quite cookie-cutter the various "classes" (i.e.
missing functions, slightly renamed functions, and different function
signatures), theres no obvious evidence until you can't compile
or run.
: Readable, reliable, reusable and maintainable code comes from carefully
: thought out programming and testing. It is perfectly possible to write
: unreadable, bug-filled, un-reusable C++ just as it is FORTRAN of C!
Of course! No tool can save you from foolishness. But some tools
do look over your shoulder better than others.
: : Second of all, C++ is a bit of a special case. So long as the developer
: : has the tools to convert their C++ code to ANSI C, and at least the C code
: : is distributed, then go ahead and write in C++. However, C++ compilers
: : are far rarer beasts than some of you would believe, and so C++ code should
: I don't think that's true with the availability of the Gnu C++ compiler on
: virtually every platform.
: : not be distributed alone since it fails the "generally available" compiler
: : criteria. I'm also concerned that the C++ standard may not be nearly so
: : well defined as those for the languages that I mentioned (feel free to
: : correct this if it's wrong).
: I think the standard is pretty well defined, BUT
: a) it is evolving and likely to change more rapidly than F77/F90 or ANSI C
: b) there aren't many compilers which implemenent the whole of the cuurrent
: standard.
I think you'll find that most of the language has settled down and most
things will run on all compilers (and I have the scars to know what
doesn't work :-) If you stay away from multiple inheritance, exceptions,
templates, and namespaces (and a few other recent additions), then you
should have relatively little portability problems. MI is in all compilers,
but it is a tiger-by-the-tail already and can lead to porting problems.
Most compilers now support templates and exceptions, and I think support
for basic templates has just about settled down (I don't use them, so
I don't know). In other words, choose judiciously what portions of the
language you use.
Keith Robison
Harvard University
Department of Cellular and Developmental Biology
Department of Genetics / HHMI
robison at mito.harvard.edu
