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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,3db17e1869f3a33d X-Google-Attributes: gid103376,public From: Samuel Tardieu Subject: Re: Ada95 Streams Question Date: 1996/06/19 Message-ID: #1/1 X-Deja-AN: 160999821 sender: tardieu@gargantua.enst.fr references: <009A400CB5CAE623.78BE@smcsr3.smcs.se.baesema.co.uk> to: Chris.Morgan@BAESEMA.CO.UK content-type: text/plain; charset=iso-8859-1 organization: TELECOM Paris mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-06-19T00:00:00+00:00 List-Id: >>>>> "Chris" == Chris Morgan writes: Chris> How likely is it that the GNAT (or some other Ada95 compiler) Chris> implementation of Ada stream_io would arbitrarily break this Chris> arrangement in future? I am told that the in-stream Chris> representation is only recommended to conform to the in-memory, Chris> but what are the actual chances of some implementation not Chris> following this advice? To be general, Ada compilers are free to use any representation of streams. One may well choose raw conversions (as GNAT does) while another one will adopt XDR encoding. Chris> Am I really relying entirely on a pure coincidence that the C++ Chris> and the Ada95 definitions can work together, or is it in fact Chris> the only sensible scheme? Streams are not portable between Ada and another language. Of course, an implementation is free to document how it will encode data so you can get it from another language (and vice-versa). Chris> Of course I am talking about the simple case where no tags are Chris> written (I'm not using any dispatching) and no doping Chris> information, so I am suggesting that two objects which are Chris> bitwise compatible in memory can naturally be passed forward Chris> and back down streams between Ada95 and C++ and I can't see why Chris> this should ever break. See above. Sam -- Samuel Tardieu -- sam@ada.eu.org