Re: Representation Clauses And Freezing

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Marin D. Condic" <mcondic-nospam@acm.com> writes:

> Stephen Leake wrote:
> > 
> > If you follow the compiler's advice, and change the size and alignment
> > clauses to:
> > 
> >    for Rec_Type'Size use 16 * System.Storage_Unit;
> >    for Rec_Type'Alignment use 4;
> > 
> > then it is "happy" again (well, except for all the spaces before the
> > semicolons, but not around elipses :).
> > 
> Making the compiler happy isn't really the issue. If I could accept
> whatever the compiler insisted on giving me, then I wouldn't need a
> representation clause, right?

But you can give a rep clause. It's just not the same one as you could
give if the type were public. So I don't understand what the problem is.
 
> My question is, if in fact this is some sort of required behavior
> because of freezing rules or other language issues, then *why* is it
> required? If it is *not* required behavior, then that just means I've
> got a compiler weakness and another compiler might actually make this
> work.

Compilers are free to choose the implementation for tagged types. This
compiler apparently has a representation for private tagged types that
is slightly different then for public tagged types. Your rep clause
does not completely specify the full tagged type. So again, what is
the problem?
 
> If it is legal to slam a representation clause on a tagged type and if
> tagged types exist to enable object oriented design (hence the "private"
> aspects), then one ought to be able to slam a representation clause on
> the tagged record in the private part of the spec and not have to put
> the record elements in the visible part of the spec. Otherwise, what's
> the point?

See above; it is legal to put a rep clause on a private tagged type.
GNAT says so.
 
> Why do I care? I'm often confronted with problems that require control
> of representation and I'd like to be in a position to say "Ada can do
> that!" In the case where tagged records and control of representation
> intersect, it appears that this is not the case - unless as suggested by
> Tucker Taft elsewhere in the thread, this is just a compiler weakness.

You have two very different issues. 

First, the rep clause you gave was rejected by the compiler, so you
need to find out why and/or fix the rep clause so it will be accepted.

Second, you want to know if rep clauses are legal on private tagged
types.

The answer to the first issue is given above; that rep clause is
accepted by GNAT. 

The answer to the second issue is "yes".
 
> > We've been around on this topic before; the general consensus has been
> > that it is better to define a non-tagged record type that has a rep
> > clause, and include that as a component in a tagged type.
> > 
> I find that answer to be unacceptable for a variety of reasons. Mostly
> because you have a hard time building class-wide operations that depend
> on representation and other attributes to get the job done that you want
> done. It also has efficiency concerns and other problems that may not be
> an issue for many systems, but they are for some of mine.

You'll have to be more specific. I don't see a significant difference:

Method 1:

type Specific_Rep_Type is record
    something      : integer_32;
    something_else : integer_32;
end record;
for Specific_Rep_Type use record
   something      at 0 range 0 .. 31;
   something_else at 4 range 0 .. 31;
end record;
for Specific_Rep_Type'size use 64;

type Object_Type is tagged record
   specific_stuff : Specific_rep_Type;
end record;


Method 2:

type Object_Type is tagged record
    something      : integer_32;
    something_else : integer_32;
end record;
for Specific_Rep_Type use record
   something      at <implementation_specific> range 0 .. 31;
   something_else at <implementation_specific> range 0 .. 31;
end record;
for Object_Type'size use 64 + <implementation_specific>;

Method 1 is guaranteed portable across compilers, and clearly
specifies the size and location of everything that is critical. The
rep clauses are the same whether the type is public or private.

Method 2 is not guaranteed portable, and is certainly less clear
about what is critically placed and what is not. As you have seen, the
rep clauses may have to change depending on whether the type is public
or private; that's included in the meaning of <implementation_specific>.

What advantage of Method 2 am I missing?

> At this stage, I'm more interested in establishing some reason for why
> such a restriction would exist - if it is not just a compiler bug. It is
> possible that what I want to do is perfectly legitimate and its just an
> obstinate implementation that won't give me what I want. Or its possible
> it is a language restriction - in which case maybe there needs to be a
> revision somewhere along the line to remove that restriction.

You don't have a "restriction", you have a "difference in
implementation specifics between public and private tagged types".
Perfectly legitimate according to the Ada 95 standard.

-- 
-- Stephe