In article <3aq9vq$nqb at decaxp.harvard.edu>, robison at lipid.harvard.edu (Keith Robison) writes:
|> 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,
... (other reasonable stuff omitted)
Since we have gotten over into C++ where I have spent some time lately,
I want offer a couple of similar observations:
-- Different problems call for different tools. While this is well known,
its application to applying programming techniques is sometimes overlooked.
Computing with square matrices, with strings, or with connected graphs
put different emphasis on techniques. OOP-like C will work in some
cases; it will be a mess in others. Forcing every program in to a pure
OOP model will work in some cases; it will be a mess in others.
-- C++ has long since passed the computer-science recreation phase.
This language fills a need or it would not find the support from
users and producers that it enjoys. That is not to say that it fills
every need nor that it will fill a particular need better than C or
FORTRAN, but it cannot be dismissed as unnecessary generally.
-- C++ is a complex, difficult to learn language. However, mastering
C++ is trivial compared to mastering of any scientific field. Learning
computer programming techniques and key elements of software engineering
is a greater challenge, but one that has become vital to progress in
scientific computing. Its time that training in these skills be
integrated with scientific education in a way comparable to conventional
mathematics.
-- As noted by Keith Robison, recent additions to C++ have real portability
problems. On the plus side, with so much commitment by so many
different people to make C++ portable and effective on virtually every
computer, programming projects based on C++ are as safe a bet as we
are likely to find in this area.
--
John.
John J. Barton jjb at watson.ibm.com (914)784-6645
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598
