Path: utzoo!attcan!uunet!husc6!bu-cs!mirror!ssi3b1!ssibbs!jac
From: jac@ssibbs.UUCP (James Crotinger)
Newsgroups: comp.sys.amiga
Subject: Re: C++ (Lattice) -- First impressions...
Summary: inline functions
Keywords: C++,review
Message-ID: <37@ssibbs.UUCP>
Date: 4 Nov 88 03:29:38 GMT
References: <16021@agate.BERKELEY.EDU> <32@ssibbs.UUCP> <16220@agate.BERKELEY.EDU> <614@quintus.UUCP>
Organization: Sangho's Public Access Unix, Cambridge, MA
Lines: 30

In article <614@quintus.UUCP>, pds@quintus.uucp (Peter Schachte) writes:
> 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?
> 
   The correct term is 'inline function' and this is a prime example of 
why they are there. You can make the data private and then provide an
inline accessor function to read it, write it, etc. This is a very good
practice. The combination of inline functions and function/operator 
overloading make it possible for user defined data types to be as easy
to use and as efficient as the regular data types. Some good applications
are given in Stroustrup's book, like the complex data type and the vector/
matrix data types. The catch is that as the number of accessor functions,
etc. increase, the compile time and the amount of memory required also
increases, and it already takes 1.5 Megs to run. Tim said that the memory
constraint and compatibility problems were the main reason he didn't do
a more object oriented version of the system routines. You can always do
it yourself, of course, by deriving your own classes from his. He has
a couple of examples of window classes that are derived in this manner.

> -Peter Schachte				"Clean water?  I'm for clean water."

     Jim

   
-- 
                                        
                               Jim Crotinger
                               crotinger%mit.mfenet@nmfecc.arpa