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: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Teaching C/C++ from Ada perspective?
Date: Fri, 06 Jul 2018 16:26:19 -0700
Organization: A noiseless patient Spider
Message-ID: <87h8lcuesk.fsf@nightsong.com>
References: <856189aa-fa00-4960-929e-174f352310ad@googlegroups.com>
	<3701bf07-89a5-4cb0-a704-5aebb589ca79@googlegroups.com>
	<2f5e4ce0-94e8-4b94-9da7-045ec90a9b22@googlegroups.com>
	<18554067-1382-4b43-a832-2d27aa5117d7@googlegroups.com>
	<8dc19505-b68a-403c-a164-f1de1864f3f1@googlegroups.com>
	<f7878185-925d-4752-9b3f-75506cce7deb@googlegroups.com>
	<da7000f7-7583-4119-b21e-87117b67b048@googlegroups.com>
	<d8ed2a68-b8f2-4d22-971c-1ddf8e387768@googlegroups.com>
	<559657f8-bbf4-4a70-9449-f85bc98d6c6b@googlegroups.com>
	<lyva9v84yb.fsf@pushface.org>
	<590d4672-4aef-42a5-823c-57ccd291115a@googlegroups.com>
	<phiqfe$1mte$1@gioia.aioe.org>
	<8de6b5ba-25ab-4d46-b80c-1544f43a9b05@googlegroups.com>
	<phjd1e$ofn$1@gioia.aioe.org>
	<c91c4183-a8fe-4b7a-858e-616728fbe844@googlegroups.com>
	<phlpfa$nkd$1@franka.jacob-sparre.dk>
	<670baa25-a987-45a0-991f-ec3aa2878233@googlegroups.com>
	<phodnf$tf1$1@franka.jacob-sparre.dk>
	<6acaa855-2508-49cc-a03f-16c6e00c91da@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="76942e9cfd50483a65178a8087ca23dd";
	logging-data="21455"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19Sth5mWRW64VuWyNRzLQTl"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Cancel-Lock: sha1:d5WGpOOXlmPItCd8eu+Fs+zYRPo=
	sha1:qiqDGHb5MPRpnQo1YmGQzKS3f2Q=
Xref: reader02.eternal-september.org comp.lang.ada:53710
Date: 2018-07-06T16:26:19-07:00
List-Id: <comp.lang.ada>

Maciej Sobczak <see.my.homepage@gmail.com> writes:
> What is interesting in this area, however, is that in large projects I
> can actually expect that the privacy policies will be intentionally
> (!) reduced, for example with unit testing and run-time inspection in
> mind. Yes, it is possible to avoid this, but it is costly and the
> cheaper option wins. This observation applies to all static languages.

C++ can mitigate that somewhat with friend declarations: does Ada have
anything like that?  It means exporting a symbol from one package to a
specific other package, rather than choosing between keeping it private
or exporting it to the whole world.

I know Java is quite extreme about privacy since it's designed to
support sandboxing.  That is, private methods and variables are treated
as security feature.  You are supposed to be able to pass instances of
your class to actual malicious code written by attackers, letting the
attacker code access your public methods but preventing it from reaching
the private ones.

Of course Java's sandbox model has experienced many security failures
over the years, but I don't think Ada even attempted anything like that.
C++ would be completely hopeless at it, because of uncontrolled pointers.