Re: adasockets and adatypes

["David C. Hoos" <david.c.hoos.sr@ada95.com>]

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" <dennison@telepath.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: Tuesday, September 04, 2001 1:53 PM
Subject: Re: adasockets and adatypes


> In article <mailman.999618666.14306.comp.lang.ada@ada.eu.org>, David C.
Hoos
> says...
> >From: "Ted Dennison" <dennison@telepath.com>
> >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
>