Re: Gripe about Ada, rep specs that won't.

[bobduff@world.std.com (Robert A Duff)]

In article <4iv0g6$6cs@news4.digex.net>,
Doug Rogers  <rogers@innocon.com> wrote:
>>Why do you believe otherwise?
>
>Because I've never had C_E raised when doing so.  

I guess it's time to send a bug report to your compiler vendor.

I can understand the temptation to learn the language by just noticing
what some compiler does -- it's easier than learning a zillion rules.
But then once in a while you'll get the wrong idea from some compiler
bug.

Admittedly, all the fancy checking Ada requires isn't much use if your
compiler doesn't do it right.

>>I imagine that if you and enough others paid ACT for a support contract,
>>they would implement it.  I agree, it would be nice to have this
>>support.  Not quite nice enough to require in the Standard, though.
>
>That's why I think Ada, despite its many advantages over other languages,
>won't prosper.  That's why embedded designers cringe.  We spend many
>man-months just overcoming these "little" obstacles.  It's only taxpayer
>money, though.  ;)

Well, maybe, but which other languages demand packed-arrays of
9-bit-components?  It doesn't make sense to switch from Ada to language
X because Ada doesn't have this feature, if language X doesn't have it
either.  E.g. in C, I think you'd end up doing all kinds of by-hand
stuff too, which is exactly what you're complaining about in Ada.

There are many cases where Ada rep clauses don't work.  (E.g., try to
specify the layout of the segmentation tables of the 80386.)  That
doesn't necessarily imply that rep clauses are useless, and it
*certainly* doesn't imply that Ada is inferior to a language that
doesn't have any kind of rep clauses at all.

>  -- And this won't work (under the 3 implementations I've tried):
>  pragma Pack (Item_Lists);

What do you mean by "this won't work"?  It should compile under all
compilers, but most compilers won't pack it as tightly as you want them
to.

By the way, if you're using Ada 95, you should be saying:

    for Item_List'Component_Size use 13;

Which means you want exactly 13 bits, and give me an error message if
you can't do that.  Pragma Pack just means pack it "reasonably" tightly,
but I don't care too much if there are a few wasted bits here and there.

But you're right -- either way, many Ada compilers will not support
tightly-packed arrays of 13-bit components.  To me, it seems reasonable
that this should be a market-driven thing -- if enough people want that
feature, vendors will do it.

>  -- Something like this is at the beginning of the file:
>  type Headers is record
>    List_Count : Nat16;
>    First      : Nat16;
>    Last       : Nat16;
>  end record;
>
>And, now, to make matters worse, I'd like to read this record, mixed
>in with Headers, from a binary file.

Perhaps the Streams stuff would help.  It is intended for reading and
writing heterogeneous streams of data like this.

>Sorry for the confusion.  I didn't mean that .File_IO was standard in
>any way.  I'm using it only as a means to compile my code completely,
>and even run it, under Linux without having to spend all day ftp-ing
>back and forth to an Alpha OpenVMS station.
>
>You're correct.  The body depends on it.  But (correct me again if I'm
>wrong again), there are generic procedures in the package, so the body
>of any package that uses my Seq_Mix_IO package will "use" the body
>of Seq_Mix_IO.  I get:
>
>gcc -c -gnat83 ephemerae.adb
>sequential_mixed_io.adb:20:06: (Ada 83) child units not allowed
>..for each instance of the generic Put/Get

This sounds like unfriendly behavior on the part of gnat.  There is no
semantic dependence on the body of a generic, but gnat introduces a
code-generation dependence on the generic body.  It seems to me that the
code generation dependence should not cause such a complaint.

Of course, -gnat83 is not a standard feature.  It won't kill you if you
simply omit it.

>Perhaps I should change the subject and list my (reduced) source.

OK.

- Bob