Unchecked_Conversion

Unchecked_Conversion

[Lele]

Hi!
I'm a misterious reader...just because I've read for a month this NG without
take part.
I'm a beginner ADA programmer (what a wonderful language!) and I've a
problem...

I should convert data types and record data types from one type to another,
since now I've
used the address attribute to point the same memory space and so accede to
from one type
to another. Ada provides features for bypassing certain language
restrictions and these
features are unchecked; it is the programmer's responsibility to make sure
that they do
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?

Thanks!

Why not try Checked_Conversion?

[Petter Fryklund]

Ie if you have

subtype Num_T is Natural range 0 .. 3;

type Enum_T is (Not_Started, Started, Stopped, Gone);

function Checked_Conversion (Num : Num_T) return Enum_T is
begin
    case Num is
        when 0 => return Not_Started;
        when 1 => return Started;
        when 2 => return Stopped;
        when 3 => return Gone;
    end case;
end Checked_Conversion;

Lele wrote in message <9fnbtt$ild$1@e3k.asi.ansaldo.it>...
>Hi!
>I'm a misterious reader...just because I've read for a month this NG
without
>take part.
>I'm a beginner ADA programmer (what a wonderful language!) and I've a
>problem...
>
>I should convert data types and record data types from one type to another,
>since now I've
>used the address attribute to point the same memory space and so accede to
>from one type
>to another. Ada provides features for bypassing certain language
>restrictions and these
>features are unchecked; it is the programmer's responsibility to make sure
>that they do
>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?
>
>Thanks!
>
>

Re: Unchecked_Conversion

[Marc A. Criley]

Lele wrote:
> 
> Hi!
> I'm a misterious reader...just because I've read for a month this NG without
> take part.
> I'm a beginner ADA programmer (what a wonderful language!) and I've a
> problem...
> 
> I should convert data types and record data types from one type to another,
> since now I've
> used the address attribute to point the same memory space and so accede to
> from one type
> to another. Ada provides features for bypassing certain language
> restrictions and these
> features are unchecked; it is the programmer's responsibility to make sure
> that they do
> 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?
> 
> Thanks!

Unchecked_Conversion is almost always a better approach than using the
'Address attribute.  However, the need to do a significant amount of
converting from one type to another suggests that perhaps a second look
at the implementation approach is warranted.

Forcing conversions between types is usually appropriate only in certain
very specific domains, such as interfacing to operating system
functions.  The great majority of software written in Ada contains no
such conversions.

What kind of software are you writing?

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Unchecked_Conversion

[Ted Dennison]

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

Re: Unchecked_Conversion

[Robert B. Love]

In <LdLT6.2225$bA3.107918@www.newsranger.com> Ted Dennison wrote:
> 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

My experience runs counter to this.  My employer has chosen to use
typing for every conceivable measurement. So we have type Meters, 
Meters_Per_Second, Feet, Feet_Per_Second, Seconds, Watts, Volts, and so 
on.
The list is endless.

To avoid conversions I would have to have hundreds of overloaded 
operators.
And to make matters worse, we have generic vectors that can be 
instantiated
for the basic types above.  I would have to have overloaded operators for
all the vector combinations.

No, using Ada in my problem domain, you are constantly converting types.
And it can be a pain.

--
----------------------------------------------------------------
 Bob Love                                   
 rlove@neosoft.com                            
----------------------------------------------------------------

Re: Unchecked_Conversion

[Jeff Creem]

"Robert B. Love " <rlove@antispam.neosoft.com> wrote in message
news:41F37C284A6DE8C0.8A6A99719FF11B52.8149DC60E20677C9@lp.airnews.net...
> In <LdLT6.2225$bA3.107918@www.newsranger.com> Ted Dennison wrote:
> > 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
>
> My experience runs counter to this.  My employer has chosen to use
> typing for every conceivable measurement. So we have type Meters,
> Meters_Per_Second, Feet, Feet_Per_Second, Seconds, Watts, Volts, and so
> on.
> The list is endless.
>
> To avoid conversions I would have to have hundreds of overloaded
> operators.
> And to make matters worse, we have generic vectors that can be
> instantiated
> for the basic types above.  I would have to have overloaded operators for
> all the vector combinations.
>
> No, using Ada in my problem domain, you are constantly converting types.
> And it can be a pain.



Actually given the subject line I think the original poster was referring to
unchecked_conversion.
Certainly conversions are used. It is unchecked_conversion that is not
needed as often (typically).

As for your problem domain sounds like it is not Ada that is a pain but the
way you have
chosen to use it. I have gone back and forth for some time on the usefulness
of this
level of typing. The idea is that you can avoid certain classes of
programming errors by
having specific types for all of these physical units. The problem is of
course that people then
get so used to using type conversions in their daily programming that
conversions can then
be used to introduce the same bugs....Granted at least now it is more
explicit where each
possible error point is...

Re: Unchecked_Conversion

[Keith Thompson]

rlove@antispam.neosoft.com (Robert B. Love ) writes:
[...]
> My experience runs counter to this.  My employer has chosen to use
> typing for every conceivable measurement. So we have type Meters, 
> Meters_Per_Second, Feet, Feet_Per_Second, Seconds, Watts, Volts, and so 
> on.
> The list is endless.
> 
> To avoid conversions I would have to have hundreds of overloaded 
> operators.
> And to make matters worse, we have generic vectors that can be 
> instantiated
> for the basic types above.  I would have to have overloaded operators for
> all the vector combinations.

At some cost in efficiency, you could use a single type, say Quantity,
implemented as a record that includes the units and a numeric value.
Inconsistent unit errors would raise Constraint_Error rather than
failing at compilation time.

If you write the code carefully enough, you might even be able to
replace the package that defines type Quantity with a more efficient
one that doesn't do the checks (type Quantity is new Long_Float or
whatever).  Use the checking version during development to catch
errors, and use the more efficient version (with thorough testing, of
course) for the released product -- unless the checking version
happens to be fast enough.

Just a thought.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Cxiuj via bazo apartenas ni.

Re: Unchecked_Conversion

[Ted Dennison]

In article <41F37C284A6DE8C0.8A6A99719FF11B52.8149DC60E20677C9@lp.airnews.net>,
Robert B. Love  says...
>
>In <LdLT6.2225$bA3.107918@www.newsranger.com> Ted Dennison wrote:
>> 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
>
>My experience runs counter to this.  My employer has chosen to use
>typing for every conceivable measurement. So we have type Meters, 
>Meters_Per_Second, Feet, Feet_Per_Second, Seconds, Watts, Volts, and so 
>on.
>The list is endless.


I'm sorry. There was an implied "with unchecked_conversion" in there. I often
perform type conversions between numeric types or derived types.

As for the particular (quite different) issue you are talking about: I've worked
with various groups that had to deal with engineering units, and they all tend
towards the same conclusion. You can either use "integer" and "float" for
everything, or you can make a separate type for each and every unit and
intermediate unit you will ever need, along with your own overloaded operators
for every operation that you will ever perform on any combination of them. Any
wishy-washyness in the middle just causes headaches of the kind you have
described.

As the "separate type for everything" route is almost always prohibitive,
usually folks opt for the minimalist route. Of course it can still be a good
idea to use constrained subtypes, esp. for routine interfaces. There can also be
a case for making separate types in certain cases where you want something
special done and don't mind rewriting all the operators to work with integer or
float to achieve that goal (eg: a Degrees type that automaticly does a "mod 360"
on any operator result).

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

Re: Unchecked_Conversion

[Marin David Condic]

This sounds like someone got sent to an Ada class that talked about the
goodness of data types and then they got all excited and started making
*everything* a type - only to discover that you *can* have too much of a
good thing. Types can be good for constraint validation and avoiding the
mixing of things that shouldn't be mixed. However, if every data item you
have is a distinct type, that is rather implying that you never mix them -
and this starts making life miserable. Meters and Seconds are often combined
to produce Meters/Second. Are you gaining some benefit by forcing each to a
different type? (maybe. maybe not.) (BTW: It would be a mistake to think
that Ada *forces* this on you. Just like in C or other languages, you could
do everything as type Integer or Float. Whether or not you should, is an
open question & dependent on your application.)

IMHO, there isn't anything inherently wrong within an application with
saying "Meters and Seconds will never exceed the type Float_64, so they will
both be stored as such" (or possibly as subtypes of Float_64.) This may be
because in your app, you are frequently measuring both and mixing them
mathematically. Where I think strong types make a lot more sense is when you
have to control representation or enforce constraints or you are creating
operations specific to some class of objects. ("Seconds" would want to be a
separate type if I had various time-related functions taking seconds as
parameters & I never wanted those subprograms to accept Meters.) Just
because I'm reading in two values that represent measurements in two
different units does not in and of itself, in my mind, justify creation of
two different types.

There is a bit of "Art" in the construction of good quality code, so you
can't write absolute rules such as "Everything must have its own type!" and
expect goodness to flow out of it. Perhaps there are some books or research
papers that might lead to some Programming Proverbs in this area?

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Robert B. Love " <rlove@antispam.neosoft.com> wrote in message
news:41F37C284A6DE8C0.8A6A99719FF11B52.8149DC60E20677C9@lp.airnews.net...
> My experience runs counter to this.  My employer has chosen to use
> typing for every conceivable measurement. So we have type Meters,
> Meters_Per_Second, Feet, Feet_Per_Second, Seconds, Watts, Volts, and so
> on.
> The list is endless.
>
> To avoid conversions I would have to have hundreds of overloaded
> operators.
> And to make matters worse, we have generic vectors that can be
> instantiated
> for the basic types above.  I would have to have overloaded operators for
> all the vector combinations.
>
> No, using Ada in my problem domain, you are constantly converting types.
> And it can be a pain.
>

Re: Unchecked_Conversion

[Jacob Sparre Andersen]

Lele:

The reason both features (Unchecked_Conversion and colocated
variables) exist is that they both can be the right way to
solve a problem.

> Are there particular risks about using Unchecked_Conversion?

Yes. If the size of the two types isn't the same, the result
of an Unchecked_Conversion is undefined (IIRC).

> Is it a better approach the address attribute?

It has the same problem, but in a slightly different form.

Show us an example we can comment on.

Jacob
-- 
"Any, sufficiently complicated, experiment is indistinguishable from magic."

Re: Unchecked_Conversion

[tmoran]

>risks about using Unchecked_Conversion? Is it a better approach  the address
>attribute?
   Unchecked_Conversion shows in the code everywhere you do a conversion,
while 'address allocation only shows up at the declaration.
   Unchecked_Conversion lets the compiler at least warn you if the two
representations are of different size, while 'address leaves you strictly
on your own.
   'address in some cases may surprise you with initialization code.

>I'm a beginner ADA programmer (what a wonderful language!) and I've a
  As others have pointed out, it's relatively rare in Ada to do this
sort of thing.  As a beginning Ada programmer, are you perhaps just
using a pre-Ada technique?  There may be a better "Ada way" to do what
you need.

Re: Unchecked_Conversion

[Robert A Duff]

tmoran@acm.org writes:

>    'address in some cases may surprise you with initialization code.

Use pragma Import(Ada) to turn off default inits.

- Bob