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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a1ce307c10055549 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-12-18 09:59:20 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn11feed!wn12feed!worldnet.att.net!207.217.77.102!newsfeed2.earthlink.net!newsfeed1.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: calenday (was Re: IBM Acquires Rational Ada Date: Wed, 18 Dec 2002 12:58:46 -0500 Organization: MindSpring Enterprises Message-ID: References: <3DF1615C.7AAAC86E@adaworks.com> <8db3d6c8.0212091445.12594821@posting.google.com> <3DF628C4.7090607@cogeco.ca> <3DF6653D.3030603@cogeco.ca> <8db3d6c8.0212101850.51506572@posting.google.com> <3DF8D33F.9020205@cogeco.ca> NNTP-Posting-Host: d1.56.b3.12 X-Server-Date: 18 Dec 2002 17:59:19 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:32036 Date: 2002-12-18T17:59:19+00:00 List-Id: Rants? Well, perhaps I have a bad habbit of typing with a "shrill" accent. :-) Actually, I don't really care about portability. In my business, we'd seldom have to port something that was this machine-dependent. I'll accept a totally vendor/processor specific answer - as is usually a requirement when you've got to dip into rep clauses anyway. And I wouldn't really characterize the need as relating to "weird" hardware. I've not usually found much problem, for example, getting a rep-clause to work to line up with some register word or other device. Usually, its a case of someone with a communication link packing things together as tightly as possible or from hardware substantially different from the thing doing the reading. You get odd-sized bit fields, things that span byte or word or longword boundaries, unusual numeric formats (1750a 48-bit float, for example?) and things of that nature. You try to create a record that will deal with the data and you discover your compiler is going to whine and snivel about being asked to span things across unusual boundaries. The instant the possibility exists that you aren't going to be able to make one message in your catalog work with the compiler in hand, you're likely to head for an overall solution that *will* work in all cases - id est twiddling the bits by hand in some manner. You don't usually want to implement 90% of the messages as records with rep-clauses and then the remaining 10% as a byte array & access routines. You'd end up building two totally different infrastructures and should one of your 90% ever change and the compiler refuse to help, you're rebuilding something dramatically. Hence (at least part of) my angst over the rep-clause. :-) MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jast.mil/ Send Replies To: m c o n d i c @ a c m . o r g "I'd trade it all for just a little more" -- Charles Montgomery Burns, [4F10] ====================================================================== Robert A Duff wrote in message news:wcc3cov1hlu.fsf@shell01.TheWorld.com... > > On the other hand, I agree with your rants about the non-portability of > rep clauses. If I were designing a language from scratch, I would try > to nail down the rules for rep clauses so that all compilers support > exactly the same ones. Or, at least, all compilers for the same machine > (where "same machine" can be interpreted to mean that the various values > in System, such as Storage_Unit and Word_Size are the same). I think I > would also require fairly "complete" support, in the sense of requiring > "weird" bit fields that are extremely inefficient to access. As you > say, it's very frustrating to use rep clauses for 90% of the cases, and > then be forced to use a completely different mechanism when you run > across "weird" hardware you need to interface to. > > - Bob