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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.66.102.8 with SMTP id fk8mr8992371pab.40.1449736708758;
        Thu, 10 Dec 2015 00:38:28 -0800 (PST)
X-Received: by 10.182.250.169 with SMTP id zd9mr157717obc.1.1449736708712;
 Thu, 10 Dec 2015 00:38:28 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!mv3no14141952igc.0!news-out.google.com!f6ni18620igq.0!nntp.google.com!mv3no14141945igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 10 Dec 2015 00:38:28 -0800 (PST)
In-Reply-To: <n4abvh$q8e$1@loke.gir.dk>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=94.107.233.114;
 posting-account=6m7axgkAAADBKh082FfZLdYsJ24CXYi5
NNTP-Posting-Host: 94.107.233.114
References: <8bc7fd76-f00a-4eea-9715-470af028fc84@googlegroups.com>
 <1krm4xun4e4ny.jmh9kvf6s0a9.dlg@40tude.net>
 <12dc7aea-933d-4271-95bd-10df808917e4@googlegroups.com>
 <5hfb2q9imjfu.zs3xp9gxw0d3.dlg@40tude.net>
 <5788b259-8886-4ee2-8c3d-7799abfd840e@googlegroups.com>
 <rt3n7ox7u8lf$.1me9jljeld3bs$.dlg@40tude.net>
 <14acd8b0-a5e9-40fd-b7cc-d319f914d507@googlegroups.com>
 <vjaapo5l3d0f.19ppdnxybx3i4.dlg@40tude.net>
 <112596d0-d4ee-46e9-a02d-8de837aff352@googlegroups.com>
 <feb10a24-79ba-4d04-be64-2e9faff19711@googlegroups.com>
 <n47n08$3tr$1@dont-email.me>
 <n4abvh$q8e$1@loke.gir.dk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <c7533283-04c4-49f6-abe8-4f47d70b86df@googlegroups.com>
Subject: Re: I'm facing an issue with: call to abstract procedure must be
 dispatching
From: Serge Robyns <serge.robyns@gmail.com>
Injection-Date: Thu, 10 Dec 2015 08:38:28 +0000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:28749
Date: 2015-12-10T00:38:28-08:00
List-Id: <comp.lang.ada>

On Thursday, 10 December 2015 00:03:15 UTC+1, Randy Brukardt  wrote:

> On top of which, it tends to limit how the client can use your package. I=
n=20
> particular, the client most likely couldn't put values of your object typ=
e=20
> into a container, because Ada puts very strict limits on getting an acces=
s=20
> value into a container. (Additionally, because of the extra runtime=20
> accessibility checking, the access version is slower. That effect is smal=
l=20
> enough that it shouldn't be a major determining factor in deciding which =
to=20
> use, but if all other things are equal, why would anyone want to use the=
=20
> slower version??)
>=20
>                                          Randy.

This is an interesting topic.  I've always been wondering when the compiler=
 is generating checks and when it does know he can skip them.  And what kin=
d of test is the compiler doing on an access value.  Especially coming from=
 the C world this is very "counter intuitive" :-P.

If the variable is as following:
  A_Reference : access not null T_something;  -- whereas T_Something is jus=
t a plain record type, i.e. not a tagged one.
and the procedure signature
  procedure Do_Something (Reference : not null access T_Something; ....);
What would happen with:
  Do_Something (A_Reference, ...);

My assumption is that the not null checks can be skipped during the call an=
d inside the procedure.  What other checks are performed inside Do_Somethin=
g for A_Reference?

Regards,
Serge