On Sat, 29 Dec 2001 16:39:48 -0800 (PST), "Jeffrey W. Baker" <[EMAIL 
PROTECTED]> wrote:

> 
> 
> On Sat, 29 Dec 2001, Eric G. Miller wrote:
> 
> > For a good explanation of how C++ took all the problematic issues of C and
> > added new sources of errors, see http://www.elj.com/cppcv3/.
> 
> Hah!  More like this:
> 
> "For a vivid example of how much free time ivory tower academics have to
> weep and moan about languages other than their favorite, see
> http://www.elj.com/cppcv3/";

Well, I won't disagree there a bit of "ivory tower" in the essay.  And I'll
also agree that the pragmatic solution often overrides the better solution.
I'm also not sold on the fully OOP paradigm of languages like Java or
Eiffel.  But many/most of the criticisms are valid in light of sources of
confusion and the error prone nature of "C" and "C++".  Some of the
criticisms are plainly irrelevant unless you accept that OOP is the one
true way ("when you have classes, you don't need structs").

> If you ask an Eiffel programmer how to get the value of a byte at a given
> offset in the computer's memory, they'll start with an explanation about
> why the programmer shouldn't concern himself with computer memory; memory
> is in the "how" domain.  From there, they will launch a long lecture that
> probably won't answer the question but will result in something absurd
> like class ByteObserver (and its companion, class ByteObserverManager).
> A C programmer will just say *offset.

Yea, sometimes it's important to know.  Often it isn't.  More often what's
really wanted is an index into an array or other data structure and it
little matters whether that offset is a real memory location or it just
maps to one.  Obviously, it depends on the problem domain...

> Anyway, back to "A Critique of C++"...
> 
> Mr. Joyner's treatise shouldn't be considered anything other than a
> finely-ground axe.  Many of his specific criticisms start out "It is well
> known..." or "It hash been shown..." without reference to the place where
> it has been shown or the people to whom it is well known.  In one place,
> he complains that C++ is not suited to concurrent processing (without
> reference to the tremendous amount of existing concurrent C++ software --
> Mozilla is a modern example), but fails to mention that, at the time of
> his writing, Eiffel lacked support for concurrency altogether!

Well, you're not claiming concurrency is a part of C++ are you?  It is,
however, built into a language like Ada95.

Anyway, I think it's important to be cognizant of the shortcomings of
any language/platform and to actively look for alternatives.  Obviously,
it is not always feasible to change programming language for a project.

-- 
Eric G. Miller <egm2@jps.net>

Reply via email to