Re: Unchecked_Conversion

[Ted Dennison<dennison@telepath.com>]

In article <9fnbtt$ild$1@e3k.asi.ansaldo.it>, Lele says...
>I should convert data types and record data types from one type to another,

Just to back up Marc here, you should almost *never* have to convert types. The
only times I ever have to do it are when interfacing with external routines that
expect to deal with untyped buffers of data (even then you can usually just pass
the routine the 'address and ('size + 7)/8 of your object). Just about any other
instance of a conversion represents a design failure on someone's part, which
should be rectified the right way: by comming up with a common type that works
for everyone and rewriting the code to work with it.

What exactly are you doing that you think you need to convert types for?

>not violate the assumptions of the rest of the program. Are there particular
>risks about using Unchecked_Conversion? Is it a better approach  the address
>attribute?

The main problem with Unchecked_Conversion is that its a function. That means
most of the time its used, a transfer of the data will occur. (The execption
being when its used as a parameter). For a large structure this could be a
problem. The way around it is to either only use it in parameters, or to
Unchecked_Convert access types instead of the actual types. 

Now there are some risks associated with Unchecked_Converson on access types.
Some access types are more that just simple addresses. For example, an access
type for an unconstrained array may also contain information about the array's
bounds so that constraint checks on array indexes can occur. So in some
situations two access types may not be safely convertable. You'd have to check
your compiler docs to find out what restrictions on Unchecked_Conversion exist.

That being said, I *always* perfer this technique over the "for use at" clause.
I think its much less dangerous for the *reader*. When pointers are involved,
you expect that there can be ailiasing of the accessed data. But when simple
variable names are used, you do not generally expect the possibility that there
could be ailiasing.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com