Path: utzoo!utgpu!attcan!uunet!super!udel!rochester!pt.cs.cmu.edu!andrew.cmu.edu!bader+
From: bader+@andrew.cmu.edu (Miles Bader)
Newsgroups: comp.sys.amiga
Subject: Re: C++ (Lattice) -- First impressions...
Message-ID: <YXPxhsy00Uka4C-uBu@andrew.cmu.edu>
Date: 3 Nov 88 04:07:20 GMT
References: <16021@agate.BERKELEY.EDU> <32@ssibbs.UUCP> <16220@agate.BERKELEY.EDU>,
	<614@quintus.UUCP>
Organization: Carnegie Mellon
Lines: 28
In-Reply-To: <614@quintus.UUCP>

pds@quintus.uucp (Peter Schachte) writes:
> In article <16220@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) write\
> s:
> About Lattice C++:
> >> > ALL the Exec and Intuition structures are now OBJECTS, with associated
> >> > methods to manipulate them.
> >> 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
> 
> Couldn't you get around this by making the accessors macros?  As I
> recall, Stroustroup's (sp???) book has several examples of this sort of
> thing.  So you get clean, safe, and efficient code.  What more could
> you ask for?

Absolutely.  When in doubt, I always provide access macros, rather
than have clients (people using my "object") access my data
structures.

You can also inline functions in c++.  I also think you can put the
entire body of short functions in the class declaration, in which
case they should get automagically inlined.

In any case, there's no reason to allow access to internal structure.
Disallowing access makes for MUCH easier future changes!

-Miles