From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA30207 for caml-redistribution; Sun, 10 Oct 1999 23:17:44 +0200 (MET DST) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA12094 for ; Sun, 10 Oct 1999 22:44:44 +0200 (MET DST) Received: from postbox.dai.ed.ac.uk (postbox.dai.ed.ac.uk [129.215.41.196]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id WAA25513 for ; Sun, 10 Oct 1999 22:44:43 +0200 (MET DST) Received: from buckie (buckie.dai.ed.ac.uk [129.215.41.224]) by postbox.dai.ed.ac.uk (8.9.3/8.9.3) with SMTP id VAA14748; Sun, 10 Oct 1999 21:44:40 +0100 (BST) Date: Sun, 10 Oct 1999 21:44:40 +0100 Message-Id: <24938.199910102044@buckie> From: William Chesters MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable To: caml-list@inria.fr Subject: Re: Stdlib regularity In-Reply-To: <38002650.6DD48411@maxtal.com.au> References: <199910092226.PAA02183@fiji01.liquidmarket.com> <38002650.6DD48411@maxtal.com.au> X-Mailer: VM 6.22 under Emacs 19.34.1 Sender: weis skaller writes: > =09No. This isn't necesarily the case. There are other > solutions. In C++, the philosophy is to provide as much protection > as possible, without costing at run time, and with protection > that does cost at run time being optional. Are you sure that initialising arrays etc. carries enough cost to be worth avoiding? After all, one of the two problems, namely the requirement to keep legal values in slots at all times, is quite easy to work around when you have to---my basic Vector is about 100 lines, generously spaced---while the other, performance, worry seems a priori likely to be misplaced, because if you are constructing an array then your time complexity is presumably at least k=D7n for some nontrivial k= , so that the extra few instructions =D7 n are unlikely to make a big difference to the overall program, however annoying they look "in the small". ocaml already goes some way beyond what C++ considers acceptible inefficiency. That's fine for a vast number of applications on modern desktop hardware.