Re: Ada.Streams examples

[dennison@telepath.com]

In article <36e6cd2c.3377267@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
>   I'll take a look at Cohen (my son took my copy away to college).

Cool! You must be very proud of him. :-)

>   I want to do an S'Read routine for a large array.  I really don't
> want to iteratively call Element'Read for each element.  Is there an
> alternative to the usual Unchecked_Conversion, overlaying, etc to get
> the data into my array?  If the array were in a Sequential_IO file I

Not that I've discovered. But in this context I don't see anything wrong with
Unchecked_Conversion. Converting types is what its there for.

>   The RM implies that an object's stream representation should be
> similar to its in-memory representation (a generalization from
> 13.13.2(17)).  If I have an object which has a standard external

Not only is that just implementation advice, but it also starts with the word
"If".

> representation (a Windows bmp bitmap, for instance) but a slightly
> different Ada representation in my program (discriminants, say), is it
> better to convert the object on Write to the "standard" external form,
> or to write it out as an Ada object as close as possible to its
> internal, Ada, memory form?  This is not addressed in AQS - anybody
> have any experience with these choices?

It depends on what you want to do. If you want to be able to write a bmp to
any stream, not just a file, then you should probably put the conversion in
the 'Write. If you will always write bmp's to the same type of stream, and
never want to put other non-bmp information in those same stream objects,
then it might make sense to create your own "bmp stream". If neither really
holds, I'd go with the one that seems the better abstraction in your
environment.

Now lets say you have a screen bitmap stored memory. You want to write this to
disk as a BMP file. I see three options:

  o  Create a 'Write procedure for that bitmap type which converts the bitmap
to a bmp and does one massive Write call for the stream. The problem with
this approach is that if anyone ever wants to do a 'Write on a bitmap for any
reason, the'll get a BMP. You can't overload it to get a JPG or GIF or a
straight memory dump (which is what they might be expecting).

  o  Create a new stream that converts Write data into GIF format, and saves
it to a file. The problem here is that the input data *must* be a bitmap of
our specified format, or this stream will produce garbage. There's no real
way in the language to enforce this. Also, we can't count on getting all the
data in one big Write call. This may be OK for BMP, but for a compressing
scheme like GIF it complicates matters.

  o  Create a Write_BMP and Read_BMP routine that take in files and bitmaps as
parameters, and forget about streams. Random objects cannot now be placed an a
"BMP" file.

The strength of streams IMHO is the ability to do I/O on hetrogenious data.
In our example I don't think that's a loss, so the last option is probably
the way to go.

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own