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=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,8f01d35116e753b6 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.204.150.90 with SMTP id x26mr3172567bkv.6.1332971353627; Wed, 28 Mar 2012 14:49:13 -0700 (PDT) Path: h15ni60314bkw.0!nntp.google.com!news1.google.com!goblin3!goblin1!goblin.stu.neva.ru!newsreader4.netcologne.de!news.netcologne.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 28 Mar 2012 23:48:35 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: xor References: <4f72393e$0$6643$9b4e6d93@newsspool2.arcor-online.net> <1j5gw4kcp8q34$.4tabwm0d7yh6.dlg@40tude.net> In-Reply-To: Message-ID: <4f738733$0$6637$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 28 Mar 2012 23:48:35 CEST NNTP-Posting-Host: adc03196.newsspool2.arcor-online.net X-Trace: DXC=W2N^nUi3Vfg016@cHD@m;jA9EHlD;3Ycb4Fo<]lROoRa8kFejVhKlci=\H3BPgA>7^1bR@6fg X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-03-28T23:48:35+02:00 List-Id: On 28.03.12 22:49, Dennis Lee Bieber wrote: > On Wed, 28 Mar 2012 18:36:28 +0100, Michael Moeller > declaimed the following in comp.lang.ada: > > >> I see. Alas, none of my books or manuals even mentions binary file I/O. > > Maybe because anything that is NOT derived from Text_IO is > considered to be Binary. (Or, maybe, because prior to Unix, the somewhat simplistic distinction "r"/"b" wasn't that popular? Structured files being offered by the operating systems, IINM.) In any case, traditional Ada I/O (other than Text_IO) is focusing on types: Let an object be of some type T. If you want that object to be input or output, instantiate an I/O module for type T, and there you go, inputting and outputting objects of type T using subprograms from the instance. For I/O of a mix of types ("binary" I/O), streams come in handy. Again, the mechanism focuses on types: every type is associated with two pairs of functions: T'Read T'Write T'Input T'Output Roughly speaking, the first pair writes bare data (representations), the second pair adds more "administrative" information about the type T. There is a guarantee about what they do. When a program outputs an object of type T using one function, then the corresponding function can input the object of type T, and vice versa. (I guess that this is some form of idempotence, however, I should leave this to the mathematicians.) The above functions' profiles consist of a pointer to an object of some stream type, and an object of type T, to be read, or written. Somewhat internally, every stream type has two (primitive) subprograms again called Read and Write. These can implement the data transmission layer of the streaming functions mentioned above; they operate in terms of Storage_Element_Array. That's the binary layer, so to speak. They are similar to Unix's read(2) and write(2) calls. Subprograms taking Storage_Element_Array parameters operate at the same level as subprograms related to "sequence of bytes" in the C sense (I would say so). You can use these when implementing your own streaming functions, or when you have data suitable for a "cast", so that the bits are re-interpreted as Storage_Element_Array (through an instance of Ada.Unchecked_Conversion). If it interests you, there is http://www.adaic.org/learn/materials/ Ada 95 material is fine, too, insofar as recent changes to the language are mostly non-destructive.