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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d17561d7e5eba62c
X-Google-Attributes: gid103376,public
From: "DuckE" <nospam_steved@pacifier.com>
Subject: Re: An alternative to Unchecked Conversion
Date: 1999/12/16
Message-ID: <38599f89.0@news.pacifier.com>#1/1
X-Deja-AN: 561781452
References: <OF2D01D779.211C774B-ON88256849.006FEEEF@ray.ca>
 <38596575_4@news1.prserv.net> <3859701a@rsl2.rslnet.net>
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-Trace: 16 Dec 1999 18:27:21 PST, 216.65.140.48
X-MSMail-Priority: Normal
Reply-To: "DuckE" <nospam_steved@pacifier.com>
Newsgroups: comp.lang.ada
Date: 1999-12-16T00:00:00+00:00
List-Id: <comp.lang.ada>


Tom Hargraves <tharg@vtcinet.com> wrote in message
news:3859701a@rsl2.rslnet.net...
> Oops. Excuse my English. I meant to express the opinion that
> Unchecked_Conversion _need_ rarely if ever be used, in 'normal'
programming
> practice. So I think we are in agreement here. Why disable one of the best
> features of Ada if you don't need to :-)
>
> I welcome comments re. the technical merits of address mapping vs.
> unchecked_conversion. For me address mapping worked fine, whereas
> unchecked_conversion did a lot of additional data copying. So that's why I
> didn't use it. What did I loose?

Using the address mapping does work fine... when you get it right.

In my experience code lives and is maintained for years.  Over the years it
is common for type definitions to change.

If you have overlaid a variable declartion using:

  firstView : firstBigRecord;
  secondView : secondBigRecord;
  for secondView'Address use firstView'Address;

Everything works fine... if and only if the two record sizes are the same.
If secondBigRecord is smaller than firstBigRecord, no problem.  If
secondBigRecord is larger than firstBigRecord, then accessing values at the
end of secondView are accessing memory that has not been allocated.  This is
similar to indexing beyond the end of an array in C.

In a large code base the definition of "firstBigRecord" and
"secondBigRecord" may live in separate subsystems.  A maintenance programmer
could change the structure of one of these records and be in for a surprise.

I'd add this to your disadvantages list.

SteveD
>
> Yours curiously,
> Tom H.