Access to strings and string subtypes?

Access to strings and string subtypes?

[Steve Folly]

Could someone explain why this code doesn't work.
I know the LRM reference that prevents it, but, in laymans terms, please explain
*why* :-)

package Test is

   type Ref is access all String;

   subtype Name is String(1..10);
   type Name_Ref is access all Name;

   A : aliased Name;
   C : aliased String (1..10);

   D : Name_Ref := A'Access; -- OK
   E : Ref := A'Access; -- Does not statically match designated subtype ???
   F : Ref := C'Access; -- Does not statically match designated subtype ???

   G : Ref := new String'("THIS WORKS"); -- OK!

end Test;


I would have expected a Ref type to be able to point to any constrained string
type. Why are subtypes not allowed?

We have various classes defined with strings of different sizes, but would like
a single function to be able to take any one of these strings and manipulate it,
possibly changing it's contents.


Thanks.

Steve Folly.

Re: Access to strings and string subtypes?

[Ehud Lamm]

What don't you link with the GNAT error message in this case?

This is one of those times where the error message and warnings that GNAT
issues seem very informative.

Ehud Lamm mslamm@mscc.huji.ac.il
Unsuccessful software projects all fail in their own unique ways,
but all successful projects are alike in many ways. -- Grady Booch

Re: Access to strings and string subtypes?

[Steve Folly]

On Thu, 16 Mar 2000 19:28:15 +0200, Ehud Lamm <mslamm@mscc.huji.ac.il> did
clatter that keyboard and type:

>What don't you link with the GNAT error message in this case?
>
>This is one of those times where the error message and warnings that GNAT
>issues seem very informative.
>
>Ehud Lamm mslamm@mscc.huji.ac.il
>Unsuccessful software projects all fail in their own unique ways,
>but all successful projects are alike in many ways. -- Grady Booch
>

Sorry, I probably should have said I'm using the Rational Apex compiler.

Steve.

Re: Access to strings and string subtypes?

[Larry Kilgallen]

In article <Pine.A41.3.96-heb-2.07.1000317054439.123892A-100000@pluto.mscc.huji.ac.il>, Ehud Lamm <mslamm@mscc.huji.ac.il> writes:

> I had a feeling your answer is going to be something like this! I say -
> always keep GNAT arround, so you can take advantage of it good error
> messages, warnings etc. (It doesn't cost you, you know...)

An additional piece of software _always_ costs, in terms
of administration, familiarization, etc.  Perhaps it is worth
that cost because of GNAT's superior error messages -- that
will depend on the degree of trouble the original problem
caused.

Re: Access to strings and string subtypes?

[Robert Dewar]

In article <2000Mar17.070235.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

No one has answered the original question of WHY this annoying
limitation is in Ada95. It is a (misguided in my opinion)
worry about efficiency. It allows implementations to omit
templates on objects with explicit bounds to save a little
bit of space.

I never liked this nasty restriction, because it means that

 x : aliased string := "hello";
 x : aliased string (1 .. 5) := "hello";

are very different. And as a result you get into a Fortran
like situation of having to count the length of your strings.
The idea in Ada 83 was simply to allow you to omit the bounds
where they are clearly unnecessary, but in Ada 95, the aliased
glitch means that the omission of bounds has far more subtle
effects.

This is indeed a common confusion, which is why we went to the
trouble of giving explicit advisory warnings here.

Robert Dewar
Ada Core Technologies

P.S. if you can't use unauthorized software (which seems a
reasonable rule, we have the same rule at ACT), then perhaps
you should get an authorized copy of GNAT (we will be happy
to tell you how at sales@gnat.com :-)


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access to strings and string subtypes?

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> No one has answered the original question of WHY this annoying
> limitation is in Ada95. It is a (misguided in my opinion)
> worry about efficiency. It allows implementations to omit
> templates on objects with explicit bounds to save a little
> bit of space.

I don't think it was purely an efficiency issue.  I think we were
concerned that existing Ada 83 implementations were already doing that
optimization, and would have difficulty changing the way they represent
arrays.  So we might have decided differently if we were designing a new
language from scratch -- I'm not sure.

I agree that the restriction is somewhat annoying.

I also don't like rules that make arrays and discriminated types
gratuitously different -- in my opinion, bounds and discriminants are
(or at least *should* be) essentially the same thing.

- Bob

Re: Access to strings and string subtypes?

[Ehud Lamm]

On Thu, 16 Mar 2000, Steve Folly wrote:

|On Thu, 16 Mar 2000 19:28:15 +0200, Ehud Lamm <mslamm@mscc.huji.ac.il> did
|clatter that keyboard and type:
|
|>What don't you link with the GNAT error message in this case?
|>
|
|Sorry, I probably should have said I'm usingthe Rational Apex compiler.
|

I had a feeling your answer is going to be something like this! I say -
always keep GNAT arround, so you can take advantage of it good error
messages, warnings etc. (It doesn't cost you, you know...)

Ehud Lamm mslamm@mscc.huji.ac.il
Unsuccessful software projects all fail in their own unique ways,
but all successful projects are alike in many ways. -- Grady Booch

Re: Access to strings and string subtypes?

[Steve Folly]

On Fri, 17 Mar 2000 05:46:14 +0200, Ehud Lamm <mslamm@mscc.huji.ac.il> did
clatter that keyboard and type:

>On Thu, 16 Mar 2000, Steve Folly wrote:
>
>|On Thu, 16 Mar 2000 19:28:15 +0200, Ehud Lamm <mslamm@mscc.huji.ac.il> did
>|clatter that keyboard and type:
>|
>|>What don't you link with the GNAT error message in this case?
>|>
>|
>|Sorry, I probably should have said I'm usingthe Rational Apex compiler.
>|
>
>I had a feeling your answer is going to be something like this! I say -
>always keep GNAT arround, so you can take advantage of it good error
>messages, warnings etc. (It doesn't cost you, you know...)
>
>Ehud Lamm mslamm@mscc.huji.ac.il
>Unsuccessful software projects all fail in their own unique ways,
>but all successful projects are alike in many ways. -- Grady Booch
>
>

As I haven't got a copy of Gnat then, (out firewall prevents us downloading
unauthorised software), and you have, could you possibly tell me what Gnat
thought of the particular piece of code I posted?

And a solution to the problem?


Cheers.
Steve Folly.

Re: Access to strings and string subtypes?

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1347 bytes --]


Steve Folly <steve.folly@rdel.co.uk> a �crit dans le message :
38d20611.156204380@news.rrds.co.uk...

> As I haven't got a copy of Gnat then, (out firewall prevents us
downloading
> unauthorised software), and you have, could you possibly tell me what Gnat
> thought of the particular piece of code I posted?

Compiling: test.ads (source file time stamp: 2000-03-17 11:18:34)

     8.    A : aliased Name;
           |
        >>> warning: aliased object has explicit bounds
        >>> warning: declare without bounds (and with explicit
initialization)
        >>> warning: for use with unconstrained access

     9.    C : aliased String (1..10);
           |
        >>> warning: aliased object has explicit bounds
        >>> warning: declare without bounds (and with explicit
initialization)
        >>> warning: for use with unconstrained access

    12.    E : Ref := A'Access; -- Does not statically match designated
subtype ???
                      |
        >>> object subtype must statically match designated subtype

    13.    F : Ref := C'Access; -- Does not statically match designated
subtype ???
                      |
        >>> object subtype must statically match designated subtype

 17 lines: 2 errors, 6 warnings
gnatmake: "test.ads" compilation error


> And a solution to the problem?
>

See above :)

Pascal.

Re: Access to strings and string subtypes?

[Christoph Grein]

package Test is

   type Ref is access all String;     <-- unconstrained

   subtype Name is String(1..10);     <-- constrained
   type Name_Ref is access all Name;

   A : aliased Name;                  <-- constrained
   C : aliased String (1..10);        <-- constrained

   D : Name_Ref := A'Access; -- OK
   E : Ref := A'Access; -- Does not statically match designated subtype ???
   F : Ref := C'Access; -- Does not statically match designated subtype ???

   G : Ref := new String'("THIS WORKS"); -- OK!

end Test;

The compiler message ("Does not statically match designated subtype") says
exactly what is wrong:

A pointer to an unconstrained string has to take care of the actual object's 
ranges, a pointer to a constrained string need not.

Thus A'Access and C'Access do not provide range information whereas
   new String'("THIS WORKS")
does.

Re: Access to strings and string subtypes?

[Robert Dewar]

In article <wcczorx1tkq.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> I don't think it was purely an efficiency issue.

I really think you are wrong here. I remember these discussions
very well, since I was opposed to this kludge.

> I think we were
> concerned that existing Ada 83 implementations were already
> doing that optimization, and would have difficulty changing
> the way they represent arrays.

If anyone was concerned about this, they never voiced this
concern at any meeting I was at. Perhaps I have forgotten,
but my memory was that this PURELY an efficiency concern.

Really I can't imagine any Ada 83 compiler making this
distinction (the ones that I am familiar with certainly
did not). You should at least be able to come up with one
example to back up your conjecture :-)

Part of the reason I remember is that there were VERY few cases
where we compromised the language for the benefit of existing
implementations in very specific terms (we did have some general
concerns about scope of change).

Really the only case I know of was the infamous "funarg"
decision, designed to favor the existing implementations
(notably from Alsys) of display based stack handling.



Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Access to strings and string subtypes?

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <wcczorx1tkq.fsf@world.std.com>,
>   Robert A Duff <bobduff@world.std.com> wrote:
> 
> > I don't think it was purely an efficiency issue.
> 
> I really think you are wrong here. I remember these discussions
> very well, since I was opposed to this kludge.
> 
> > I think we were
> > concerned that existing Ada 83 implementations were already
> > doing that optimization, and would have difficulty changing
> > the way they represent arrays.
> 
> If anyone was concerned about this, they never voiced this
> concern at any meeting I was at. Perhaps I have forgotten,
> but my memory was that this PURELY an efficiency concern.
> 
> Really I can't imagine any Ada 83 compiler making this
> distinction (the ones that I am familiar with certainly
> did not). You should at least be able to come up with one
> example to back up your conjecture :-)

The problem was not so much with the objects as it was with
the access values.  For many compilers, access-to-unconstrained
expects the object to have dope contiguous with the object,
whereas with access-to-constrained, there is no dope associated
with the object.  If the same type of access value could point
to either, then both would require contiguous dope.  This is
not much of a hardship for stand-alone objects.  However, for
record or array components, adding dope as a side effect of
adding the word "aliased" to the component seemed undesirable at the
time (at least to some of us).  So it was a space efficiency
issue primarily.  In retrospect, I guess having "aliased" cause
the addition of contiguous dope might have been the better approach,
but as usual, hindsight is 20-20 (or wears rose-colored glasses,
or something like that ;-).

These concerns all presume the "thin pointer" representation 
for access-to-unconstrained types.  For the "fat pointer" representation, 
where there is a separate pointer to the dope, this problem disappears.  
But of course that interacts in tricky ways with 
access-to-deferred-incomplete, etc.

> Part of the reason I remember is that there were VERY few cases
> where we compromised the language for the benefit of existing
> implementations in very specific terms (we did have some general
> concerns about scope of change).

As indicated above, it wasn't so much about difficulty of implementation,
as about space overhead.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA