> > Could you elaborate on where you think 'object_size is required? And could
> > you also elaborate on what you think the spec is for 'object_size (I'd like
> > to consider asking for this to be added to Apex, if there is truly a need).
> Your phrasing seems to imply that 'Object_Size is not really necessary,
> but the GNAT people would not have invented it if this were true :-)
> Anyway, here is a piece of code where I need it. This generic is used to
> send any type over a socket (on the same machine, so I don't need to
> care about endianity issues, and I need it to be as fast as possible).
> It must work with indefinite types (e.g. String, and records with
> discriminants that have defaults).
> I suppose I could replace T'Object_Size with some formula involving
> T'Size and T'Alignment, but T'Object_Size is really easier.
> I know, I am supposed to use the streams stuff for this kind of thing,
> but this is old code that works and I am not going to rewrite it.
> Besides, I cannot afford the overhead that I assume this would add (I
> haven't done any tests, though).
This is similar to our situation. I don't believe the CPU overhead of
streams will be significant, but the coding overhead of converting is
unacceptable for the short term.
A bigger problem IMHO with Apex is their definition of "representation"
as used (but not defined) in RM95 13.3(40). If
type Demo is range 0 .. 12;
X : Demo := 11;
then for Apex 2.4.1 Ada 83 model, X'Size is 32, but for Apex 3.0.0 Ada 95
model, X'Size is 4. What causes us grief is that the actual handling of
the object in memory has not changed! If X'Address is "A", then examining
the byte at A shows all zeroes, while examining the byte at A+3 shows 11
in both versions!
Since the RM95 language is not clear (the AARM didn't help), you could
argue that the representation is indeed four bits, but that the "storage
allocated" is indeed 32. I think (1) this is avoiding the issue that the
behavior is counterproductive, and (2) the AARM does NOT suggest the
meaning of 'Size has changed that much.