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=0.2 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00, XPRIO_SHORT_SUBJ autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,78b2880bc7e78e39 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-03-17 01:38:54 PST Path: nntp.stanford.edu!newsfeed.stanford.edu!news.tele.dk!193.251.151.101!opentransit.net!jussieu.fr!freenix!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: RISC Date: Fri, 16 Mar 2001 09:40:18 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <98t8la$rc$1@nh.pace.co.uk> References: <98qumf$5sf$1@nh.pace.co.uk> <98r4g1$7r1$1@nh.pace.co.uk> <3ab1d090$1@pull.gecm.com> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 984753642 876 136.170.200.133 (16 Mar 2001 14:40:42 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 16 Mar 2001 14:40:42 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: nntp.stanford.edu comp.lang.ada:91508 Date: 2001-03-16T14:40:42+00:00 List-Id: No, you are not alone. There have been a number of times that I and others have raised problems in this forum relating to representation clauses. I have had particular troubles with representation clauses on tagged records and private records. I know others have had similar experiences. Inevitably, there are work-arounds that will let you get the job done, but they are typically inefficient or inelegant or, more commonly, both. Resorting to some version of byte arrays & unchecked conversions or overlays is one way of dealing with it. However (while it is typically reasonably efficient) I find those solutions to be inelegant in that - if for no other reason - the compiler ought to know where record fields lie and ought to be able to keep track of that stuff better than I can - so why shouldn't it get the job of knowing where to divide up the bytes and bits? (I want to fight the problem, not the compiler or the language!) If you hide the movement of bytes-to-fields/fields-to-bytes down at some low level, at least you hide the information from the rest of the system and isolate your problems. It just frustrates me because I can see much nicer, much more elegant ways of doing this sort of thing and it is only slightly out of reach..... MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Martin Dowie" wrote in message news:3ab1d090$1@pull.gecm.com... > I gave up on record rep clauses a while back after similar frustrations. Am > I > alone in this? These days, for interface level stuff I work with byte arrays > and > do all the conversions explicitly myself (loads of modular arithmatic, which > I'd > have to admit finding quite fun getting what I want sometimes :-) > > Has anyone been down this path before and stopped any pitfalls I'm not > aware of? >