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,9fb64e4c58f1fe
X-Google-Attributes: gid103376,public
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: overload ":=" ???
Date: 1996/07/23
Message-ID: <Dv0991.6yB@world.std.com>#1/1
X-Deja-AN: 169709307
references: <dewar.837740729@schonberg> <31F40F0C.3FDACA19@jinx.sckans.edu>
 <ws97mrvsot6.fsf@schonberg.cs.nyu.edu> <TARJEIJ.96Jul23153224@ulrik.uio.no>
organization: The World Public Access UNIX, Brookline, MA
newsgroups: comp.lang.ada
Date: 1996-07-23T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <TARJEIJ.96Jul23153224@ulrik.uio.no>,
Tarjei Jensen <tarjeij@ulrik.uio.no> wrote: The problem with bounded
>string is that it assigns a global maximum string size instead of
>letting each string have its own maximum size.

True.  But it's not particularly a problem with the bounded strings
package.  The problem is that discriminant constraints are checked for
equal-discrims on assignment.

>... The former is not
>particularly flexible while the latter really require a user defined
>":=".

Or a user-define "implicit conversion" operation.  An earlier version of
Ada 9X solved this problem.

>Not the least because the maximum length of the strings might be different.
>
>e.g:
>
>  a : counted_string(4) := "1234";
>  b : counted_string(5) := "1234";  -- four characters and space for five
>
>  a := b;  -- Will not work with current version of Ada

True.  The expectation is that you'll instantiate the generic
approximately once per program (or subsystem) with a "reasonable" max
such as 80, or 200, or whatever.

Note that typical implementations of Pascal that support a similar thing
usually choose the max for you (often 255).

Note also that bounded strings are for applications that want to avoid
the overhead and unpredictability of heap-allocated strings -- e.g.
many real-time/embedded applications.  If you want flexibility, use
unbounded strings, and pay for heap allocation.

Anyway, I agree that what you're asking for would be nice.  Not quite
nice enough to warrant changing rules about discriminant constraints,
apparently, though.

>While I am in wishing mode I would very much like a third alternative
>to the values of S'Bit_Order. I would very much like to have
>Most_Significant_Byte_First as a choice (Network order for those who
>are curious).

Shouldn't that be S'Byte_Order?  Ask you favorite compiler vendor for an
implementation-defined attribute.

- Bob