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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ac2397ce800de518 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-04 13:43:56 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!opentransit.net!jussieu.fr!enst!enst.fr!not-for-mail From: "David C. Hoos" Newsgroups: comp.lang.ada Subject: Re: adasockets and adatypes Date: Tue, 4 Sep 2001 15:44:55 -0500 Organization: ENST, France Sender: comp.lang.ada-admin@ada.eu.org Message-ID: References: <20010904115244.24236db3.tonygair@blueyonder.co.uk> <1v6l7.3307$4z.6132@www.newsranger.com> Reply-To: comp.lang.ada@ada.eu.org NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: avanie.enst.fr 999636235 1469 137.194.161.2 (4 Sep 2001 20:43:55 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Tue, 4 Sep 2001 20:43:55 +0000 (UTC) To: Return-Path: X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.0.4 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: comp.lang.ada mail<->news gateway List-Unsubscribe: , List-Archive: Errors-To: comp.lang.ada-admin@ada.eu.org X-BeenThere: comp.lang.ada@ada.eu.org Xref: archiver1.google.com comp.lang.ada:12721 Date: 2001-09-04T15:44:55-05:00 First of all, one doesn't redefine 'Output or 'Input -- just 'Read and 'Write. For example, when you have a spec that defines the network format, the only practical way to insure that the representation of the components is what is specified is to "bite the bullet" and do the work. One only needs to do this for simple types and for some cases of simple records where the components either do not fully occupy their bytes. Since you have an incorrect opinion about 'Class'Output, perhaps it would be better to give an example of something that can't easily be redefined, and demonstrate with working code how _you_ would do it. All non-trivial systems require a *lot* of work on many fronts, so this is nothing new. There are only two IO attributes to be defined for every type, and many of them can be done with instantiations of generic procedures. One of the most frequent things that has to be re-done when porting Ada code to new platforms and/or new compilers is to define types of the correct size and representation, where the original developers used language-defined types which just happened to be of the correct size for the original platform and compiler. I know whereof I speak, because I personally have ported over a million lines of code with problems like this. One case I remember was when the VADS compiler changed the definition of the type Float from one version of the compiler to the next. In one case Float was defined as equivalent to Long_Float, in one version, and as equivalent to Short_Float in the other. ----- Original Message ----- From: "Ted Dennison" Newsgroups: comp.lang.ada To: Sent: Tuesday, September 04, 2001 1:53 PM Subject: Re: adasockets and adatypes > In article , David C. Hoos > says... > >From: "Ted Dennison" > >One can't. That's why when stream format is important, one should define > >his own types -- although I've never found a reason not to use the language- > > For a single-developer app that might be a good way to handle it. But in many > situations this is just not a feasible solution. For a non-trivial systems its a > *lot* of work to redefine every IO attribute for every type. Some *can't* easily > be redefined (I think 'Class'Output is like this). Let's also not forget that > we've now distributed responsibility for the I/O working properly out to every > single author and maintainer of every single type in the system. > > >> If you only have 2 implementations to get talking, it is fairly easy to > >> massage one end until it talks like the other. That isn't the same thing as > >> true portability. > >I agree. one should define what the stream should look like from the > >beginning. > >For example, for Annex E, GNAT uses the XDR format defined by Sun. > > Ahhh. That's a very good example, in that they shared a small part of this > problem. They still don't have to worry about differing vendor implementations, > but they at least had to worry about different platforms. They solved this > smaller problem by creating a special package that contains all the routines > that will be used by the base type's IO attributes to construct their stream > representations. Users can then override this package with one of their own > devising (including the XDR-based one that comes with GLADE). > > Its cool that they did this, but this kind of hook into the inner workings of > the compiler is most definitely *not* part of the Ada standard. It should go > without saying that it won't come close to working with any other compiler. > Perhaps that issue should be addressed for a future language revision. However, > for now there is clearly no good way to accomplish general stream data > portability within Ada. Your only alternatives today are to subset the problem > into one of: > > o - portability when only using Gnat with the XDR version of > System.Stream_Attributes installed > o - portability when only using a certian subset of types > o - portability between n specific compilers/platforms (n > 2 only for > masochists) > > --- > T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html > home email - mailto:dennison@telepath.com > _______________________________________________ > comp.lang.ada mailing list > comp.lang.ada@ada.eu.org > http://ada.eu.org/mailman/listinfo/comp.lang.ada >