Re: Newbee question

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

Marin David Condic wrote in message ...

>Yes, but when the compiler rejects valid representation clauses simply
>because it doesn't want to do it that way, you're back to picking the
bits
>apart out of a byte array just like you would with C or C++.

If Ada compilers had to support every possible representation clause, I
think it is likely that there wouldn't be any Ada compilers. It is
probably possible to handle every possible bit alignment of every
possible object, but the resulting compiler would be very complex (with
that many more bugs) and/or the results code would be very inefficient.
You can't have everything.

>Or if the language doesn't give you a means of expressing a
representation for some of
>the features (How do you control where the tag goes in a tagged record
so
>you can effectively control the placement of everything else?) you're
stuck once again.


You don't NEED to control where the tag goes. You simply need to be able
to control where everything else goes. Admittedly, some compilers don't
allow moving the tag, but I know that Janus/Ada does and I believe that
Rational Apex does as well. (In practice, it doesn't help much, because
virtually all useful O-O types are controlled, meaning all user types
are extensions, and you can only change the representation of the
extension part of an extension. Without this rule, you can't have
classwide dispatching -- obviously the tag has to be in the same place
in any possible object.)

>Ada has some really nice syntax for controlling representation - but
all of
>that is totally useless the instant the compiler starts rejecting it
for even *some* of the cases.

I strongly disagree. Janus/Ada has rather restrictive limits on
alignment of composite objects (more than GNAT's), yet we were able to
use rep. clauses on virtually all of the types imported from Windows in
Claw. In the few cases where we weren't able to use them directly, we
used solutions like the ones proposed as solutions to the original
poster's question. And, I certainly fail to see how anyone is worse off
with these solutions available than they would be in C. So, people are
usually better off than C/C++ for controlling representation, and
occassionally have the same amount of pain.

            Randy Brukardt.