Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!agate!violet.berkeley.edu!pete
From: pete@violet.berkeley.edu (Pete Goodeve)
Newsgroups: comp.sys.amiga
Subject: Re: C++ (Lattice) -- First impressions...
Summary: 2nd stage response
Keywords: C++,review
Message-ID: <16220@agate.BERKELEY.EDU>
Date: 30 Oct 88 10:30:34 GMT
Article-I.D.: agate.16220
References: <16021@agate.BERKELEY.EDU> <32@ssibbs.UUCP>
Sender: usenet@agate.BERKELEY.EDU
Organization: University of California, Berkeley
Lines: 56


Responding to Jim Crotinger's reply <32@ssibbs.UUCP> to my original
posting:

> > By far the most impressive thing about this implementation is that ALL the
> > Exec and Intuition structures are now OBJECTS, with associated methods to
> > manipulate them.
>
>    This is nice but is not done as well as it could have been. Most of the
> data in the structures is not hidden. This does make it more nearly
> compatible with existing C code, but if you were starting from scratch
> in C++ you'd probably hide all that data and write accessor functions to
> access it.

I'm not entirely convinced of this yet.  Accessor functions mean a lot of
overhead, and in the majority of situations I don't think you need to be
paranoid about the user messing where he shouldn't.  At least as long as
the structures remain fixed, and the way the Kernel is currently designed,
we can probably be fairly sure that they will.  (Too many things would
break if they didn't.)  Now what WOULD be nice would be an ability to
specify members to be publicly 'const' -- they would then be WRITTEN to
only by suitably friendly accessor functions.

As I said in the last posting, I like "Data Hiding", but only where it
allows you to build a truly pnambic system, where you can implement things
however you like on the "backside" of the interface without bothering the
user at all, and C++ doesn't quite meet this spec.
[Mm..mm?  Oh -- "PNAMBIC" ... "Pay No Attention to that Man BehInd the
Curtain..."]


>    Note that Stroustrups book is somewhat out of date. A few things (like
> protected) have been added that aren't in the book. The book describes
> C++ as implemented in CFRONT 1.0. The newest version is 1.2 with 2.0 due
> out Real Soon Now (2.0 will have multiple inheritance). The Lattice CFRONT
> says that it is 1.1a. I don't know what the differences are between 1.1a
> and 1.2.

This is going to be one problem with C++ ... keeping up with an evolving
language.  I suspect I'll be hanging around comp.lang.c++ quite a bit from
now on.  In fact I've already run into some nasties that sparked a long
posting to that group.  My initial enthusiasm got tempered quite a bit
by those findings.  (They're too detailed to even think of cross posting.)


>    BTW, Tim Holloway mentioned on BIX that he wants to make the next
> release a real compiler, as opposed to a translator. That would definitely
> help.   [.....]

Yeah. It will also eliminate the hefty licence fee Lattice has to pay AT&T
for cfront, so it SHOULD be one way of bringing the price down...
>
>                                Jim Crotinger
>                                crotinger%mit.mfenet@nmfecc.arpa


                                                -- Pete --