Re: Ada 83 - avoiding unchecked conversions.

[Stephen Leake <Stephen.Leake@gsfc.nasa.gov>]

Chris Brand wrote:
> 
> Matthew Heaney wrote:
> >
> [cut]
> > But knowing the representation of the data is only important at the
> > hardware level, ie "the interface boundary."  Internal to the software
> > there's a lot going on that doesn't depend on representation of the data,
> > so we want to practice some information hiding by letting the compiler
> > choose the representation.
> >
> [cut]
> >
> > This confusion is also the reason why shops often say "Thou shalt not use
> > predefined types, because it's not portable."  This too is another silly
> > rule.
> >
> > It would be perfectly valid for such a rule at the interface layer, because
> > I have to know the representation of my types.  But internal to the
> > software system, I don't care, and using predefined types is just another
> > form of information hiding.
> >
> [examples cut]
> 
> I worked on a project where the rule was not to use predefined types.
> We had a package defining the "base types" to use, with all their
> representation clauses and everything and we had to base our types on
> these.
> The main type was an "Integer_16".
> 
> This was great while we were using a 286 target. It was only when we
> ported
> it to a 486 target (where 16-bit values need more work than 32-bit ones)
> that we noticed the disadvantage of such a rule. Left to itself, the
> compiler would have chosen a 16-bit value for most things on the 286 and
> a 32-bit value on the 486.
> 
> Of course, if you take these things away, people have to think about
> "what is a sensible upper bound for this type ?" :-)

Perhaps there should have been a type "Fast_Integer", with the
understanding that it was at least 16 bits (this is of course just
Standard.Integer). Then programmers can use Fast_Integer when they don't
really care about the size.


> 
> --
> Chris
> Stating my own opinions, not those of my company.

-- 
- Stephe