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,4e9860765413318c X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-24 10:15:02 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!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: Hi byte and Lo Byte Question Date: Fri, 24 Aug 2001 13:05:35 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9m61gv$b8s$1@nh.pace.co.uk> References: <9m0gn6$b6j$1@zeus.orl.lmco.com> <3B843C0C.9A3282B@raytheon.com> <9m34r7$6ka$1@nh.pace.co.uk> <3B860BD6.7A1A8EA3@eraseme.systems.saab.se> <3B867ECA.80502@home.com> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 998672735 11548 136.170.200.133 (24 Aug 2001 17:05:35 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 24 Aug 2001 17:05:35 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: archiver1.google.com comp.lang.ada:12389 Date: 2001-08-24T17:05:35+00:00 List-Id: "Warren W. Gay VE3WWG" wrote in message news:3B867ECA.80502@home.com... > > I see where you're going on the "efficiency" argument, but ignoring that > for a moment, what about a different approach.. > > Someone could craft an Ada subset (declaration) language, that is > compiled by a small compiler (like a CORBA IDL compiler), and > generates a resulting package body and spec, in existing Ada95 > terms to accomplish what you want. > > A better way might be to use ASIS with the necessary "code" added to > generate your packages (some commercial venture has probably already > done this at some point). > I'd really hate to have to be running some sort of preprocessor just to get automatic creation of all the Unchecked_Conversions I might want. This would be more painful than simply creating the Unchecked_Conversion or declaring an overlay of a Stream_Element_Array on top of all the types I might want to convert. You aren't really extending the language per se. You're just adding another type/object attribute, so syntactically it remains the same. I believe implementations might have some latitude to create attributes like this and not be in violation of the standard, so it could be an extension without a language update. > > Of course, the draw back to this approach is that you don't avoid the > data copying that would be required by the generated code. The advantage > however, would be to keep the language from growing in size. If you > look at: > > >>for X in My_Type'Raw_Data (My_Data)'Range loop > >> Some_Storage_Element := My_Type'Raw_Data (My_Data) (X) ; > >>end loop ; > > > there is some data copying on a Some_Storage_Element basis anyway. > But no motion of My_Data to some intermediate structure just to be able to treat it as bytes. The Some_Storage_Element part was just there to demonstrate something syntactically correct. The important part is the My_Type'Raw_Data (My_Data) (X) part. You can reference all the bytes of My_Data without having to do: Another_Block_Of_Data := My_Unchecked_Conversion (My_Data) ; which requires allocation of two objects instead of one *and* requires motion of the data from one place to the other (o.k. not if you pull stunts with pointers, but thats a side issue.) **and** requires an appropriate instantiation of Unchecked_Conversion ***AND*** has to be done for each and every data type that you want to turn into a stream. Gimme the raw bytes in an easy manner and I promise not to blame Ada when I shoot myself in the foot. > Unless Ada0Y were to gain endian representation features, I think > a certain amount of copying (internal or external) would be > necessary anyway. But I have to admit, that a representation > clause for endianess would be extremely convenient. Then at least > the compiler can do it in the most effective manner for the > platform it was compiled on. What's wrong with ARM 13.5.3 Bit Ordering and using "for X'Bit_Order use High_Order_First ;" and similar (Low_Order_First )? I'm pretty sure that should work and do what you want - never needed to mess with it myself - yet. (Day ain't over, yet!) 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/