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,start X-Google-Attributes: gid103376,public From: Chris.Morgan@BAESEMA.CO.UK Subject: Ada95 Streams Question Date: 1996/06/17 Message-ID: <009A400CB5CAE623.78BE@smcsr3.smcs.se.baesema.co.uk>#1/1 X-Deja-AN: 160796554 sender: Ada programming language comments: To: report@gnat.com x-vms-to: SMTP%"info-ada@listserv.nodak.edu",SMTP%"report@gnat.com" newsgroups: comp.lang.ada Date: 1996-06-17T00:00:00+00:00 List-Id: I have a question about Ada95 stream implementations. I mentioned this work a little while back in response to a request for Ada95 success stories, but now I'm feeling a little unsettled by accusations of being a hacker! I'm principally aiming this at comp.lang.ada but cc:ing to report@gnat.com in case someone there who's given up on the newsgroup cares to comment. Background ========== I have connected an Ada95 executable to a C++ executable using streams. The Ada is the brains of the application, and the C++ is the Motif pretty face. On both sides I have defined a set of portable types which application types are converted to for transmission and converted from on receipt. On the C++ side I have specialised the iostream operators in our C++ GUI library for each low-level type (e.g. 1,2 and 4-byte signed integers, 4-byte float, 8-byte float and so on) so that binary reads are performed, not ASCII. This is simply a case of casting the object to a char* of the correct size before doing the read or write (>> or <<). On the Ada side I have declared types that correspond to these low-level types, deriving portable integer types from Interfaces.Integer_n and unsigned integers from Interfaces.Unsigned_n types. The only special thing I have done is the C++ library stil expects a linefeed after each object (it normally reads files) so I add that on after calling the 'write attribute for each object (character'write(ASCII.LF)). This is all working fine and I get good performance with a named pipe created in /tmp which is a form of shared memory. In fact I have quite a nice scheme going where I have defined a root tagged type which defines the header for any message to the C++, and then any real message is derived from the root. To write any particular derived type is simply matter of calling type'write(object) and away it goes. The only bit not tested yet is floats which aren't very important in this app. Question ======== How likely is it that the GNAT (or some other Ada95 compiler) implementation of Ada stream_io would arbitrarily break this arrangement in future? I am told that the in-stream representation is only recommended to conform to the in-memory, but what are the actual chances of some implementation not following this advice? Am I really relying entirely on a pure coincidence that the C++ and the Ada95 definitions can work together, or is it in fact the only sensible scheme? Some of my more senior colleagues think that Ada95 stream_io is broken for Ada/C++ interworking, but the fact that it works exactly as I expected in my setup is either a) pure coincidence or b) the result of Ada streams (at least with GNAT) being implemented precisely to allow this. I know which I suspect! Of course I am talking about the simple case where no tags are written (I'm not using any dispatching) and no doping information, so I am suggesting that two objects which are bitwise compatible in memory can naturally be passed forward and back down streams between Ada95 and C++ and I can't see why this should ever break. (Note : I'm using GNAT3.05 on Sun-SPARC-Solaris2.5. Previous versions of GNAT had a stream_io bug which held me up but which is now fixed. The C++ compiler is the SunSoft SPARCCompilerC++ from SunSoft Visual Workshop for C++. Naturally if the GUI worked with g++ I would have tried direct interworking.) Thoughts? Chris -- --chris.morgan@baesema.co.uk --Team Ada