From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,8eff44ec1bcf8433
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-10-15 13:31:06 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!logbridge.uoregon.edu!news.huji.ac.il!not-for-mail
From: "Ehud Lamm" <mslamm@mscc.huji.ac.il>
Newsgroups: comp.lang.ada
Subject: Re: Container reqs
Date: Mon, 15 Oct 2001 22:08:50 +0200
Organization: The Hebrew University of Jerusalem
Message-ID: <9qfgla$7sb$3@news.huji.ac.il>
References: <9qctpn$lil$1@news.huji.ac.il>
 <3nCy7.29644$ev2.35903@www.newsranger.com>
NNTP-Posting-Host: di4-3.dialin.huji.ac.il
X-Trace: news.huji.ac.il 1003177451 8075 132.64.14.3 (15 Oct 2001 20:24:11
 GMT)
X-Complaints-To: abuse@news.huji.ac.il
NNTP-Posting-Date: Mon, 15 Oct 2001 20:24:11 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Xref: archiver1.google.com comp.lang.ada:14590
Date: 2001-10-15T22:08:50+02:00
List-Id: <comp.lang.ada>


Ted Dennison <dennison@telepath.com> wrote in message
news:3nCy7.29644$ev2.35903@www.newsranger.com...

>
> I agree, but I'd take it a bit further. The "unbounded" containers should
try to
> not perform heap operations outside of adding/removing items. That would
allow
> their use in real-time apps that perform all initializations at startup
time.
> Any operations that potentially affect the heap should be commented as
such.

OK. Esp. the docuemntation part.
As long as unbounded heap allocations versions exist, I don't see any
problem with this.

>
> I would not be in favor of "dumbing down" the library so that beginners
can pick
> it up quickly. Making it easy to use properly should be a goal, but not
the
> primary overriding one (as it is with any facility). If it ends up being a
> hierarchy of generics, that's fine. But in that case there should ideally
be
> some default instantiations (or default generic parameters), to take some
of the
> work out of it. I realise that an educator's view of this situation is
going to
> be directly reversed from mine, but there it is. Perhaps we can find
something
> that works for both goals.

Right.
The way I see it, if it is impossible - or just very hard - to provide
default instantiaions, it is likely that the design is bad anyway.

Ehud