Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.object,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!ames!agate!howland.reston.ans.net!swrinde!sgigate.sgi.com!enews.sgi.com!lll-winken.llnl.gov!uop!csus.edu!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality (was Re: cost of malloc)
Message-ID: <hbaker-0108950939380001@192.0.2.1>
Sender: hbaker@netcom3.netcom.com
Organization: nil
References: <9507261647.AA14556@aruba.apple.com> <3v8g7l$cge@jive.cs.utexas.edu> <3vac07$ptf@info.epfl.ch> <3vb382$dtr@jive.cs.utexas.edu> <3vbl70$bht@fido.asd.sgi.com> <hbaker-3107951026250001@192.0.2.1> <justin-0108951458440001@158.234.26.212>
Date: Tue, 1 Aug 1995 17:39:38 GMT
Lines: 59
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:4938 comp.lang.misc:22428 comp.lang.lisp:18504 comp.object:36134 comp.arch:60026

In article <justin-0108951458440001@158.234.26.212>, justin@logcam.co.uk
(Justin Forder) wrote:

> In article <hbaker-3107951026250001@192.0.2.1>, hbaker@netcom.com (Henry
> Baker) wrote:
> 
> [snip]
> 
> > My own pet peeve is _weak_ language type systems like Ada and C++ that
> > _force_ you to break apart a single object into a number of smaller
subobjects
> > _that are separately mallocated_ even when you know how to manage the
> > object as one object in assembly language.

> I'm puzzled - in C++, using a pointer is the price you pay for polymorphism.
> 
> The design space for C++ classes has two "safe corners":
> 
> 1) for user-defined data types, with value semantics and no inheritance
>    or virtual member functions, and with the relevant operators defined
>    to make them well-behaved C++ data types,
> 
> 2) the other for object-oriented programming, with inheritance, virtual 
>    member functions and destructors (and possibly protection
>    against copying or assignment).
> 
> These are Coplien's two "canonical class forms". Objects of the first kind
> (values) normally live on the stack or are directly embedded in larger
objects.
> Objects of the second kind (instances) normally live on the heap, and give
> rise to all the memory management problems.
> 
> Things get more interesting when you move into the middle of the design space,
> or produce hybrid approaches (e.g. for large values with copy-on-write, or
> as with the many kinds of smart pointers).
> 
> You are right to say that C++ throws a large problem over to application
> writers, but by doing this it does allow a great variety of solutions, and
> once you have chosen a solution it is often possible to package it in a way
> that can be used easily and concisely.

All you've said, is that if you go along with Stroustrup/Coplien's
programming styles, you can get the job done, sort of.  However, I would
argue that following their advice can cost you 3X - 100X in performance,
because you drive the poor allocator/deallocator crazy.

Forcing a program to go 2 indirections to access array/string elements because
C++ has no way to store the length of the array/string along with the
array/string is probably the most irritatingly obvious indication of the
problem, but the problem is a good deal more widespread than this.

Stroustrup/Coplien argue that you now need to 'solve' this problem by using
type-specific allocators.  Well, if C++ allowed you to do it correctly in
the first place, you would have no (or certainly much less) need for this
sort of hacking.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
