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 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,470860aa3e635a7
X-Google-Attributes: gid103376,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!feeder3.cambrium.nl!feed.tweaknews.nl!newsfeed.kamp.net!newsfeed.kamp.net!newsfeed.freenet.de!newsfeed2.scan-plus.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Newsgroups: comp.lang.ada
Subject: Re: GNAT for MS Visual Studio
From: Georg Bauhaus <rm.tsoh+bauhaus@maps.futureapps.de>
In-Reply-To: <m2lkae95uz.fsf@mac.com>
References: <13duou81kg3sd1c@corp.supernews.com>
	 <fd1so0$lmu$1@jacob-sparre.dk>
	 <QISdna5WdIMntGjbnZ2dnUVZ_rCtnZ2d@comcast.com>
	 <rkr7df.7mp.ln@hunter.axlog.fr>
	 <soednbei8rlx-mXbnZ2dnUVZ_rignZ2d@comcast.com>
	 <xwir5zj8j2.fsf@hod.lan.m-e-leypold.de>
	 <wvbrabr9hq0t.fsf@astra06.norway.sun.com>
	 <ePWdnf5PGZFiwmfbnZ2dnUVZ_jidnZ2d@comcast.com>
	 <ltfy11y10v.fsf@hod.lan.m-e-leypold.de>
	 <TJSdncwgUrlA-2HbnZ2dnUVZ_ramnZ2d@comcast.com>
	 <4xsl4zw3bp.fsf@hod.lan.m-e-leypold.de>
	 <YcCdnaCp_dEWKmLbnZ2dnUVZ_qqgnZ2d@comcast.com>
	 <fdsf0r$q0t$1@jacob-sparre.dk>
	 <1191357491.860178.230380@22g2000hsm.googlegroups.com>
	 <4702ADCC.7080209@obry.net>
	 <1191439439.120567.172630@g4g2000hsf.googlegroups.com>
	 <4703F02D.3030207@obry.net>
	 <1191682021.844225.236870@g4g2000hsf.googlegroups.com>
	 <4707A3D0.3070702@obry.net> <fe9j33$968$1@jacob-sparre.dk>
	 <47088904.1090201@obry.net>  <m2lkae95uz.fsf@mac.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1191837141.7362.18.camel@kartoffel>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Date: Mon, 08 Oct 2007 11:52:21 +0200
Organization: Arcor
NNTP-Posting-Date: 08 Oct 2007 11:52:23 CEST
NNTP-Posting-Host: c4da7d45.newsspool4.arcor-online.net
X-Trace: 
 DXC=7kR2c=>=_e`PKPPVf;4hUj4IUK<Cl32<a4Fo<]lROoRa^YC2XCjHcbiZiH0\Z4`55lN[W<lHX`=Bd\6BhD5G6\il9g@CTEThM<a
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:2344
Date: 2007-10-08T11:52:23+02:00
List-Id: <comp.lang.ada>

On Sun, 2007-10-07 at 18:44 +0100, Simon Wright wrote:
> Pascal Obry <pascal@obry.net> writes:
> 
> > Look it is not that unusual to have a container populated for a
> > simulation that after initialization point does not need to be
> > updated but only *read*. I have many concurrent simulations like
> > this. I would have expected to be able to use the containers in this
> > case.
> 
> I suppose you could just copy the initialized container! (depends
> rather on the size, of course).

Or even copy the container's elements to the most
efficient data structure we have for read only data.
Matt has explained many times that generic algorithms for
containers work with arrays, too.

What are typical use cases for containers? Do we have a
collection of use cases?
Are there others than the simulation Pascal has been mentioning?
(I guess theses are larger data sets and a few updates every
now and then?)

More use cases will warrant writing one of the alternative
container implementations that the Ada docs are suggesting.

(And BTW, how many caches of what sizes can we expect to be
present in upcoming releases of multicore CPU systems? Will this
be enough justification for requiring unlocked concurrent reads,
or shared single memory tricks in standard containers?
What about the likely properties of multiprocessor Sparc
systems? How will cell processors evolve and what does this mean
for Ada's standard containers?)