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=unavailable autolearn_force=no version=3.4.4
Path: 
 border2.nntp.dca.giganews.com!nntp.giganews.com!newspeer1.nac.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 07 May 2014 13:25:21 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
References: <slrnlm6mkg.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <lk41jr$1vl$1@dont-email.me>
 <slrnlmbs1n.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com>
 <slrnlmcoqd.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <waw9v.109142$f85.65293@fx19.iad> <scy9v.1071029$2N5.142769@fx05.iad>
 <kxy9v.109149$f85.89664@fx19.iad> <lyzjiw7h6c.fsf@pushface.org>
 <fRN9v.204655$Ng5.180587@fx17.iad>
 <t7a0jcl05g1h.11jb75b2jg1l7.dlg@40tude.net> <eT_9v.574$dr.264@fx27.iad>
 <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net>
 <97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com>
 <5368b00d$0$6703$9b4e6d93@newsspool3.arcor-online.net>
 <lqsx31h1st5k.oag3lhs8dn2i$.dlg@40tude.net>
 <5368dc70$0$6708$9b4e6d93@newsspool3.arcor-online.net>
 <ye80u8yjop49.zttq1d7bi98f$.dlg@40tude.net>
 <53690cb8$0$6602$9b4e6d93@newsspool4.arcor-online.net>
 <63k39u59mmk8.eeonyygr5rjc$.dlg@40tude.net>
 <5369d765$0$6608$9b4e6d93@newsspool4.arcor-online.net>
 <1ujfeb1baw6ri.1iprdov55030o$.dlg@40tude.net>
In-Reply-To: <1ujfeb1baw6ri.1iprdov55030o$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <536a1821$0$6706$9b4e6d93@newsspool2.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 07 May 2014 13:25:21 CEST
NNTP-Posting-Host: 781980c7.newsspool2.arcor-online.net
X-Trace: DXC=HWX?06UiiSO^B]`=U:WelBA9EHlD;
 3YcB4Fo<]lROoRA8kF<OcfhCOKC=LIOMLmjO@nc\616M64>JLh>_cHTX3jMiU8lk6aBJDN
X-Complaints-To: usenet-abuse@arcor.de
Xref: number.nntp.dca.giganews.com comp.lang.ada:186283
Date: 2014-05-07T13:25:21+02:00
List-Id: <comp.lang.ada>

On 07.05.14 09:40, Dmitry A. Kazakov wrote:

> They can even use C. What is the point?

The point is that

IF programmers want task-safety, and
IF programmers need to respect timing,
-----------
THEN programmers may need to build safe solutions
without "protected new".

The point is that, with "protected new", they cannot get
their job done, in this case.

>> If the programmer can request a "protected new" object,
>
> The choice is between requesting and not requesting this.

The choice is between safety or not, assessing whether or
not things will break, as you claimed they would. Some kinds
of safety nets ("protected new") are so simple and heavy that
this quality may render them inapplicable to some valid
programming problems.

Of which the original problem (reading from a container) is
an example, one that is not resolved by "protected new", it
seems. The "sequential checks" that handle tampering already
add to Ada containers being slow in comparison.