From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,65f09e2d2d4dad56 X-Google-Attributes: gid103376,public From: "Marin D. Condic" Subject: Re: Representation Clauses And Freezing Date: 2000/07/20 Message-ID: <397707E2.CCDB7C44@acm.com>#1/1 X-Deja-AN: 648615433 Content-Transfer-Encoding: 7bit References: <3973192E.E7337814@acm.com> Organization: Quadrus Corporation X-Sender: "Marin D. Condic" (Unverified) X-Server-Date: 20 Jul 2000 14:08:46 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-07-20T14:08:46+00:00 List-Id: 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? 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. > I have no explanation for why the record size and alignment changes > when it is a private type. But why do you care? > 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? 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. > 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. 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. MDC -- ====================================================================== Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/ Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity." -- Martin Luther King, Jr ======================================================================