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.9 required=5.0 tests=BAYES_00 autolearn=ham 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 10:58:27 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: calenday (was Re: IBM Acquires Rational Ada User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Wed, 18 Dec 2002 18:57:41 GMT Content-Type: text/plain; charset=us-ascii 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> "Marin David Condic" writes: > Rants? Well, perhaps I have a bad habbit of typing with a "shrill" accent. > :-) No offense intended. :-) > 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. That's the sort of thing I meant: you're interfacing to something (hardware or software protocols) that is "weird" from the point of view of the computer hardware you're running on. Sometimes the compiler supports bit fields that are "natural" for *this* computer, but your data is coming from a computer with a different word size, or different natural alignments, etc. >...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. Yeah, that's a pain. But so is doing all 100% the bit-twiddling way. Sigh. >...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. Hahah! So you *do* care about portability! (To newer versions of the same compiler, at least.) In any case, I think the RM should tell you which rep clauses are legal, rather than tripping over implementation-dependent compiler error messages. I think you agree with that... - Bob