Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.object
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!news.maz.net!news.ppp.de!news.Hanse.DE!wavehh.hanse.de!cracauer
From: cracauer@wavehh.hanse.de (Martin Cracauer)
Subject: Re: C++ Productivity
Message-ID: <1995Feb13.114214.22909@wavehh.hanse.de>
Organization: The Internet
References: <1995Jan23.193745.7044@boole.com> <D3FuGq.Kwv@da_vinci.ecte.uswc.uswest.com> <1995Feb4.210947.718@mole-end.matawan.nj.us> <1995Feb6.132028@di.epfl.ch> <3hdugu$l2q@calvin.st-and.ac.uk>
Date: Mon, 13 Feb 95 11:42:14 GMT
Lines: 55
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:112495 comp.lang.smalltalk:20783 comp.object:26649

ajry@st-andrews.ac.uk (Alistair James Robert Young) writes:

>In article <1995Feb6.132028@di.epfl.ch>,
>Robb Nebbe <Robb.Nebbe@di.epfl.ch> wrote:
>>In article <1995Feb4.210947.718@mole-end.matawan.nj.us>, mat@mole-end.matawan.nj.us writes:
>>Unfortunately C++ templates don't define an contract with the client
>>that uses them. This means that you have no way of knowing when any
>>change you make is going to break existing code or not. Furthermore,
>>the last time I checked the semantics were ambiguous.
>>
>>From a software engineering point of view C++ templates are rather
>>sloppy.

>IMO, from a software user's point of view, C++ templates are a thing of
>nightmares. We already hear complaints every day about the ever-increasing
>size of .EXE files for applications; now along comes C++ with its convenient
>way of generating dozens of chunks of code identical in *everything* but the
>type that they handle! The reduction in code size I achieved by replacing
>a B-Tree template for eight types with a class for a B-tree of (void *)
>and derived classes to for each type was quite amazing.

>Don't mistake me, I like most of C++, but for their effect on code size I
>nominate templates the Code Construct from Hell of 1995.

On the other side, templates or something similar are neccecary to do
static binding and maybe inlineing for elements of a container (Ok,
you can use casts in C++). With dynamically-typed languages like
Smalltalk and Objective-C, which can hold any object type in one
single container instance (and therefore require only one copy of the
code), you'll always have messagecall-overhead.

Additionally, it sucks in hybrid OO languages (those that can operate
both over objects and low-level-types) like ObjC, that you define a
container that you cannot use for integers or chars without manually
copying the code. C++'s template enable you code to operate both over
Objects and low-level-types.

I think it might be possible to reduce code explosion when the
compiler detects messages in the container that in fact are
independend of the template type to operate on. In the meantime, you
can do this by putting such message in a seperate non-templated class
and inherit your template class from it.

The Sather compiler at least trows out every piece of code that is
accessible from inside the program. This is not possible with the
object files C++ currently uses and doesn't make sense in image-based
languages like Smalltalk/Lisp/Dylan.

Btw, if you were on UNIX, all this would be so bad. Almost all modern
UNIXes load only the needed fraction of a file from disk. Additionally
some can load compressed (gziped) executables directly (FreeBSD).
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Private email Martin.Cracauer@wavehh.hanse.de Fax +4940 522 8536. No NeXTMail!
 No guarantee for anything. Anyway, this posting is probably produced by one
 of my cats stepping on the keys. No, I don't have an infinite number of cats.
