Re: data types & efficiency

["Robert I. Eachus" <rieachus@comcast.net>]

Vinzent 'Gadget' Hoefler wrote:

> No, it can't (at least I think so). It can do this if you derive a
> "new" type from it, but not for a subtype. A subtype always has the
> same representation as its base type.
> 
> Hmm, at least that's *my* interpretation of the RM, so it can be
> totally wrong. :)

Correct, your interpretation is totally wrong. ;-)  You can specify 
different sizes for both objects RM 13.3(39..43) and subtypes RM 
13.3(44..56).  But notice the note at RM 13.3(58): "A component_clause 
or Component_Size clause can override a specified Size. A pragma Pack 
cannot."

In other words, a 'Size clause for a subtype can be overridden.

> So, yes, for the subtype it "optimizes" the size (it simply spits out
> the minimum size needed to represent the specified range) ->
> Smaller_Int'Size gives 6 here.

Correct, RM 13.3(55) recommends that if the size of the subtype is NOT 
specified, S'Size should return the minimum size required for an 
unbiased representation.  Note that an implementation will often use a 
larger size for objects of the subtype whose size is unspecified, and 
may allow a smaller size to be used in records (fierce packing).

I think GNAT has another attribute that returns the size that will be 
used for standalone object of the type.

> But for an actual object of that subtype it uses that of the base
> type, of course (y'Size gives 32, too) - unless you specify a
> different size for the object itself (z'Size gives 8).
> 
> To be honest, my understanding of RM 13.3(39-57) is not very good. So
> it is perhaps better to delegate this question to the real language
> lawyers here in c.l.a. :)

This is/was not a good time for that, there was an ARG meeting this weekend.

> Well, it seems you can't define a representation for a subtype, only
> for an object of that subtype.

No, see above.

> Given that, your "requirements" don't make much sense too me, because
> even if you define a representation for each of the "redefined" types,
> you still can change for each object declared, if you need to do so.
> 
> And BTW, "independence from the compiler in terms of internal
> representation" really sounds quite unportable to me. For instance, if
> you try to do that on a 24-bit DSP, there is no 32-bit representation
> available at all, simply because the target-architecture can't do that
> (it must be either 24 or 48 bits). But the possibility of defining an
> Integer that can represent 2**32 different values is still there.
> 
> So IMO doing such things would break more that it could possibly fix.

If what you want is for the compiler to reject programs when it can't 
implement the required sizes, well that is what you asked for.  If you 
want to force overflow when an intermediate value is out of bounds, this 
doesn't work.  What you need to do in that case is either specific 
assignments, or better, subtype conversions where you want to be sure 
that an intermediate is a value of the subtype.  Converting to a subtype 
does a range check, RM 4.6(51), that cannot be optimized away by RM 
11.6(5). (Explicit conversions are not operations...)

However, note that no check is performed for a subtype conversion of an 
out parameter RM 4.6(62).  This is to prevent the passing of an 
uninitiallized value as an out parameter from raising Constraint_Error. 
  (When you think about it, this should be a non-issue, the check is 
only omitted for values that can't be used anyway.  However, there are 
some cases in generics where the effect can be surprising.)

In practice what most people who are trying to write portable software 
do is to carefully specify (sub)types that are used for input or output, 
and let the compiler use the most efficient types internally.  And yes, 
this sometimes means that the (sub)types used for I/O are different from 
those used internally. This way, if there is a difficult or expensive 
conversion, it only occurs as part of the I/O.

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke