Questions about Unchecked_Conversion

Questions about Unchecked_Conversion

[MaryAnn Atkinson]

1. Could someone please explain a few things about Unchecked Conversion
   and what it really does for me? What if I dont have it there?

2. What is the difference (as far as unchecked_conversion is concerned)

   between the following?

   a. FUNCTION ABC(A, B);
   b. FUNCTION KLM IS NEW Unchecked_Conversion(A, B);

   Could the KLM function be defined the same as the ABC function
above, 
   but in the body of the KLM function be placed a WITH
Unchecked_Conversion;
   statement? Would this have the same effect?

3. What happens if we place the statement With Unchecked_Conversion; 
   somewhere in the top of our program? Does this mean that from then
   on, and for the whole pgm, no conversion exception is raised 
   anywhere?

MAA


__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

Re: Questions about Unchecked_Conversion

[Matthew Heaney]

In article <19991215201559.23735.qmail@web218.mail.yahoo.com> , MaryAnn 
Atkinson <maryann_30@yahoo.com>  wrote:

> 1. Could someone please explain a few things about Unchecked Conversion
>    and what it really does for me? What if I dont have it there?

Ada is a strongly-typed language, which basically means you can't mix
apples and oranges.

Unchecked_Conversion is the mechanism the language provides for
bypassing the type system, in effect allowing you to convert an apple
into an orange.


> 2. What is the difference (as far as unchecked_conversion is concerned)
>
>    between the following?
>
>    a. FUNCTION ABC(A, B);
>    b. FUNCTION KLM IS NEW Unchecked_Conversion(A, B);

What does function ABC do?  Without knowing that, it's impossible to
make a comparison.

In any case, the profile doesn't match anyway.  UC is a generic function
that takes a single argument (and returns a single value):

  function To_B_Type is
    new Unchecked_Conversion (Source => A_Type, Target => B_Type);

  B : constant B_Type := To_B_Type (A);


> Could the KLM function be defined the same as the ABC function above, but in
> the body of the KLM function be placed a WITH Unchecked_Conversion; statement?
> Would this have the same effect?

I'm not sure what you're asking here.  If you mean can you implement a
function using UC, the answer is yes:

package P is
  function To_B_Type (A : A_Type) return B_Type;
end;

with Unchecked_Conversion;
package body P is

  function UC_To_B_Type is
    new Unchecked_Conversion (A_Type, B_Type);

  function To_B_Type (A : A_Type) return B_Type renames
    UC_To_B_Type;

end;


> 3. What happens if we place the statement With Unchecked_Conversion;
>    somewhere in the top of our program?

Nothing, unless you instantiate the generic, and then call the
instantiation during an execution of your program.


> Does this mean that from then on, and for the whole pgm, no conversion
> exception is raised anywhere?

No.  If you're trying to suppress exceptions, there are other mechanisms
for doing that.


--
Yeah, well, no one was present when the dinosaurs lived, so I guess
their presence in the fossil record is "only a theory." No one was
present when the Grand Canyon was formed either, or the creation of the
solar system, or, or, or. Of course evolution is "only a theory." What
else would it be as a scientific concept?

Skeptic magazine publisher Micheal Shermer, commenting on the recent
decision by the Oklahoma board of education to include a disclaimer on
school science textbooks warning that evolution is "only a theory."

Skeptic web page: http://www.skeptic.com/

Re: Questions about Unchecked_Conversion

[reason67]

In article <19991215201559.23735.qmail@web218.mail.yahoo.com>,
  comp.lang.ada@ada.eu.org wrote:
> 1. Could someone please explain a few things about Unchecked
Conversion
>    and what it really does for me? What if I dont have it there?

NOTE: I am assuming Ada83 as you used Ada83 names.. If it is 95, my
explainations still apply but my examples could be written better.

Unchecked conversion is just as the name says. It converts data from one
type to another without doing any error checking. So if you had:

type Traffic_Light_Type is (Red, Yellow, Green);
for Traffic_Light_Type use (Red => 15, Yellow => 45, Green => 60);
for Traffic_Light_Type'Size use 16;

type Word_Type is range 0 .. 65536;
for Word_Type'Size use 16;

function To_Traffic_Light_Type is new Unchecked_Conversion
   (Source => Word_Type,
    Target => Traffic_Light_Type);

Word          : Word_Type;
Traffic_Light : Traffic_Light_Type;
...
begin
...

   Traffic_Light := To_Traffic_Light_Type (Word);
...
end;

The conversion from Word to Traffic light is done unconditionally. If
Word does not equal 15, 45, or 60, the conversion still happens with no
error. Upon use of Traffic_Light, a Constraint_Error would be raised.

If you do not use Unchecked_Conversion, you have to do the conversion
manually. In my example, that is fairly easy. But if converting between
a 32 bit Float and an 4 byte array, that is far more complicated.
Conversions such as that can not be done through type casting.

> 2. What is the difference (as far as unchecked_conversion is
concerned)
>
>    between the following?
>
>    a. FUNCTION ABC(A, B);
>    b. FUNCTION KLM IS NEW Unchecked_Conversion(A, B);

ABC has a different spec then KLM. KLM only takes A as a parameter and
returns B.

>    Could the KLM function be defined the same as the ABC function
> above,
>    but in the body of the KLM function be placed a WITH
> Unchecked_Conversion;
>    statement? Would this have the same effect?

If the specs matched, yes. You could hide the use of Unchecked
conversion in the body without changing the functionality at all.

> 3. What happens if we place the statement With Unchecked_Conversion;
>    somewhere in the top of our program? Does this mean that from then
>    on, and for the whole pgm, no conversion exception is raised
>    anywhere?

If you placed the with of unchecked_conversion before the package, it is
visible thoughout the package. Withing in Unchecked_Conversions has
absolutely no effect other than giving you package visibility to
Unchecked_Conversion. Any type casting you do would still be subject to
Ada type checking. The only thing that would be exempt would be the
specific calls to instantiations of unchecked_conversion.
---
Jeffrey S. Blatt


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Questions about Unchecked_Conversion

[Charles H. Sampson]

MaryAnn Atkinson <maryann_30@yahoo.com> wrote:

> 1. Could someone please explain a few things about Unchecked Conversion
>    and what it really does for me? What if I dont have it there?

     The rest of your post makes it look like you're a bit hazy on ex-
actly what Unchecked_Conversion (hereafter referred to as UC) is, not 
surprising because the Ada terminology is a bit confusing.  It's called
a generic function, but it's not really a function.  Instead, it's a 
blueprint or a template used by the compiler to create real functions.

     The functions created, called instantiations, will take the bit 
pattern that represents a value of one type and treat it as a value of 
another type.  Notice that this means that there is no attempt to con-
vert the original value to a value of the new type.  Indeed, as the name
implies, no checking at all goes on that the bit pattern is proper as a
value of the new type.

     Notice also that this is highly hardware dependent.  Use with care.
However, don't avoid it because of this dependency when you really need
it.  (Programming standards that proscribe UC are unrealistic.  Fortu-
nately, there seem to be fewer of these now.)

     I don't understand your question "What if I dont have it there?".

> 2. What is the difference (as far as unchecked_conversion is concerned)

>    between the following?

>    a. FUNCTION ABC(A, B);
>    b. FUNCTION KLM IS NEW Unchecked_Conversion(A, B);

     If you were declare KLM without using UC, its specification would 
be something like

     FUNCTION KLM (Original_Bits : Type_of_A) RETURN Type_of_B;

Thus the two are not at all comparable.  Maybe this question needs clar-
ification too.

>    Could the KLM function be defined the same as the ABC function
> above, 
>    but in the body of the KLM function be placed a WITH
> Unchecked_Conversion;
>    statement? Would this have the same effect?

     Without clarification, KLM could not be defined the same as ABC.
In any case, you can't put a WITH Unchecked_Conversion in the body of 
KLM.  A with_clause can only go in the context clause of a compila-
tion, before the stuff you want to compile.

> 3. What happens if we place the statement With Unchecked_Conversion; 
>    somewhere in the top of our program? Does this mean that from then
>    on, and for the whole pgm, no conversion exception is raised 
>    anywhere?

     At the top of the program is the right place for it, but it can't 
just go somewhere at the top.  It must come before the thing you're com-
piling, in the so-called context clause of the compilation:

               with Unchecked_Conversion;
               package body A_package is ...

(Intervening comments and white space are o. k.)

     Such a with statement does nothing about suppressing "conversion 
exceptions" at all.  It simply means that for this compilation unit you,
the programmer, are free to use UC.  Its effect is only on that compila-
tion, not the program as a whole.  (Technically there's no such thing as
a "conversion exception", but I think you mean, "an exception raised 
during a type conversion.")

                                        Charlie


-- 
     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.

Re: Questions about Unchecked_Conversion

[Matthew Heaney]

In article <1e2w3op.j44mmjevrxz4N%claveman@inetworld.net> , 
claveman@inetworld.net (Charles H. Sampson) wrote:

>      Notice also that this is highly hardware dependent.  Use with care.
> However, don't avoid it because of this dependency when you really need
> it.

No, UC is not "highly hardware dependent."  The semantics of UC are
well-defined, and the conditions under which these semantics are
guaranteed are listed in RM95 13.9 (5-11).

Re: Questions about Unchecked_Conversion

[reason67]

In article <38593212_2@news1.prserv.net>,
  "Matthew Heaney" <matthew_heaney@acm.org> wrote:
> In article <1e2w3op.j44mmjevrxz4N%claveman@inetworld.net> ,
> claveman@inetworld.net (Charles H. Sampson) wrote:
>
> >      Notice also that this is highly hardware dependent.  Use with
care.
> > However, don't avoid it because of this dependency when you really
need
> > it.
>
> No, UC is not "highly hardware dependent."  The semantics of UC are
> well-defined, and the conditions under which these semantics are
> guaranteed are listed in RM95 13.9 (5-11).

I think he meant the nature of the hardware dependant features make
the use of Unchecked_Conversion to lower your portability. For instance,
an Integer to byte array on a Big Endian Machine will produce different
results than on a Little Endian Machine.
---
Jeffrey S. Blatt



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Questions about Unchecked_Conversion

[Charles H. Sampson]

Matthew Heaney <matthew_heaney@acm.org> wrote:

> In article <1e2w3op.j44mmjevrxz4N%claveman@inetworld.net> , 
> claveman@inetworld.net (Charles H. Sampson) wrote:
> 
> >      Notice also that this is highly hardware dependent.  Use with care.
> > However, don't avoid it because of this dependency when you really need
> > it.
> 
> No, UC is not "highly hardware dependent."  The semantics of UC are
> well-defined, and the conditions under which these semantics are
> guaranteed are listed in RM95 13.9 (5-11).

     The paragraphs you cite have reduced the number of compiler depen-
dencies on this subject that were in Ada 83, but hardware dependencies 
remain.  As another respondent has already pointed out, endianess comes
immediately to mind.

     Another is 13.9 (6): S'Size = Target'Size.  While that's not as 
much of an issue right now as it was in the past, with most machines 
byte-oriented (and very few compiler implementors), if you try to port 
code using UC from one architecture to a wildly different one, you'll 
likely have problems on this point.

     Nonetheless, my point remains: Because of these dependencies, make
sure that you really do need it, that there's not some reasonably effi-
cient hardware-independent and compiler-independent means for obtaining
the effect you want.  If you do need it, use it.  That's what it's there
for.

                                Charlie

-- 
     To get my correct email address, replace the "claveman" by
"csampson" in my fake (anti-spam) address.