Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!xait!mirror!ssi3b1!ssibbs!jcrotinger
From: jcrotinger@ssibbs.UUCP (James Crotinger)
Newsgroups: comp.sys.amiga
Subject: Re: C++ (Lattice) -- First impressions...
Summary: comments
Keywords: C++,review
Message-ID: <32@ssibbs.UUCP>
Date: 28 Oct 88 05:57:48 GMT
References: <16021@agate.BERKELEY.EDU>
Organization: Sangho's Public Access Unix, Cambridge, MA
Lines: 93

In article <16021@agate.BERKELEY.EDU>, pete@violet.berkeley.edu (Pete Goodeve) writes:
> 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. 

> On the flip side, I have one MAJOR nit to pick.  There is NO way that I can
> find to redirect the error messages anywhere but the console! 

  Yes, they output the error messages, etc, to stderr, which cannot be
redirected from the CLI. Tim said he'd try to change this in the next 
release.


> information that you need.  They did manage to make it a little harder to
> read than it should have been by printing identifiers in the same font as
> the rest of the text; as they had chosen nice meaningful names for these,
> sentences could get rather confusing. 

  This does get confusing. A nice typewriter font for identifiers would
definitely make it easier to follow.

> that it's not a complete description of all the C++ features.  Luckily I
> had Stroustrup's article in IEEE software handy to clear up some points; I
> probably will have to get his book for the final word.

   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.

> As an exploratory mission, I thought I would implement a true "string" type
> (i.e. "class") -- one that manages its own storage dynamically.  [I'm sure
> that someone must have done this already, but my cursory search of the
> handy literature didn't turn one up, so I went ahead anyway.] 

  Stroustrup does this in his book.
> 
> My big gripe, though, is that C++ makes a big deal about its "Object
> Orientation" and "Data Hiding", but to my way of thinking it doesn't really
> meet those qualifications very well.  I'm probably more of a "Data Hider"
> than an "Object Lover", so I was looking forward to creating classes where
> I could wall off the implementation from the user modules.  The reason is
> not just to hide my bad code, but so that I could CHANGE the representation
> if I wanted to WITHOUT having to recompile all the user modules, as long as
> I didn't modify the public interface of the class.  For example, one might
> want to change a "stack" class from an array storage implementation to a
> linked list, leaving the "push()" and "pop()" etc. the same.  Actually a
> couple of remarks in the references suggest one should be able to do this,
> but I made a quick check and the Guru gave me his True Word immediately:
> You CANNOT change the private section of a class and expect it to run with
> the old user modules.
> 
> In fact, I can't see how it could be otherwise.  The only indication of how
> much storage a class needs, for instance, is in its definition, so wherever
> a module invokes a "new" operation for the class it must have the complete
> information in the header file.  You would need to actually store the
> information in the executable file somewhere -- and how would you know
> which information to store if not all the headers were the same?  Maybe
> some other implementation has solved this somehow, but as the Lattice
> version comes straight from AT&T I doubt it.

  Right, user modules have to be recompiled with the new headers. You may
be able to get around this with 2.0 as it allows you to overload the new
operator. Even so, the data IS hidden in that the user doesn't have to be aware
of how the private section is implemented, and he certainly has no direct
access to the private section, but he does have to compile with an up to date
header file.

>                                         -- Pete --
> 
> ... and, yes -- the list price ($500) SHOULD be lower.

   Definitely. For a limited time, registered Lattice C 4.0 owners can
upgrade for $300. Also, fortunately for me, they have a 50% educational
discount (only applies to new packages, not upgrades). But even at $250-$300
I doubt it'll revolutionize the way most Amigans compute. 

   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. Currently it takes about 2 minutes to compile and link Hello.cp
on my 3 Meg A1000 w/hard drive.
-- 
                                        
                               Jim Crotinger
                               crotinger%mit.mfenet@nmfecc.arpa