Re: Interfaces.Shift_Left

["Randy Brukardt" <randy@rrsoftware.com>]

"awdorrin" <awdorrin@gmail.com> wrote in message 
news:5f989095-5c1c-4b23-a538-d70f4718b4b1@l19g2000yqc.googlegroups.com...
> The data being manipulated does start out as signed 32-bit integers -
> its the Logical Shift operations in the Interfaces package that are
> expecting Unsigned_32 types as input parameters.

It does not make sense to "shift" numbers: "shift" is not an operation of a 
number.

It does make sense to "shift" a bunch of bits. Ada allows treating an 
unsigned number as a "bunch of bits", thus modular types support "and", 
"or", and shifting. But Ada does not allow that for signed numbers.

C programmers sometimes use shifting as a shortcut for multiplying or 
dividing by a power of 2. But this is premature optimization: any remotely 
decent compiler will do this automatically, without confusing the reader of 
the code. (Ever Ada compiler that I've examined the output of does this 
optimization.) (And this has the advantage of still getting overflow checks 
for multiplies, so there is a protection against getting the wrong answers 
by accident.)

So, if the data is *really* numeric in nature, then the first choice is to 
write the operations in terms of multiply and divide.

OTOH, if the data is not numeric, then the shifting probably is just used to 
pack data into a word. That's better done in Ada using representation 
clauses -- but in the interests of getting your program converted fast, you 
probably should leave well-enough alone and stick with the shifts. But in 
that case, the data type should be unsigned (there is no "number" involved).

Anyway, I understand if you want to use Unchecked_Conversion as a 
quick-and-dirty hack -- those are often necessary in the real world. But you 
shouldn't think of that as the final solution; there is something 
fundementally wrong with needing to shift signed values, and it would be 
best to work out what the problem is an eliminate it.

                                   Randy.