Subtypes do not Statically Match

Subtypes do not Statically Match

[John Harbaugh]

Hi all -

Suppose I have a record with an unconstrained array component which is
constrained by the record discriminant.  Now I want to pass a record
pointer (oops! access value) to a function which will return a pointer
to the array component:


package Parent is

   type Object(Max : Positive) is tagged record
      Component : aliased String(1..Max);
   end record;
   
   type String_Ref is access all String;
 
   function The_Handle(Obj : access Object) return String_Ref;
end;

package body Parent is

   function The_Handle(Obj : access Object) return String_Ref is
   begin
      return Obj.Component'access;
      --Error: object subtype must statically match designated subtype
   end;
   
end;


Apparently, the problem is that the range constraint on the component
creates an anonymous subtype of string that is not subtype conferment
with type String.  In other circumstances, we would declare a
constrained subtype for the component and the return type.  In this case
we really do want variable sized string - some might be a few
characters, and others may be millions of characters.  Any suggestions
on how to write the function body?

BTW, this works if we pass in an object to the function rather than an
access value.  But if we want to process a heterogeneous list of objects
from the class, we need to use pointers.

Best regards,

	- John Harbaugh

Re: Subtypes do not Statically Match

[James S. Rogers]

John Harbaugh wrote in message <377A8C1A.6EFE0FF7@boeing.com>...
>Hi all -
>
>Suppose I have a record with an unconstrained array component which is
>constrained by the record discriminant.  Now I want to pass a record
>pointer (oops! access value) to a function which will return a pointer
>to the array component:
>
>
>package Parent is
>
>   type Object(Max : Positive) is tagged record
>      Component : aliased String(1..Max);
>   end record;
>
>   type String_Ref is access all String;
>
>   function The_Handle(Obj : access Object) return String_Ref;
>end;
>
>package body Parent is
>
>   function The_Handle(Obj : access Object) return String_Ref is
>   begin
>      return Obj.Component'access;
>      --Error: object subtype must statically match designated subtype
>   end;
>
>end;
>
>BTW, this works if we pass in an object to the function rather than an
>access value.  But if we want to process a heterogeneous list of objects
>from the class, we need to use pointers.


If you want to deal with a heterogeneous list of objects you need to change
your data definitions:

type String_Access is access String;

type Object is record
   Component : String_Access;
end record;

You will create the list by dynamically allocating the neccessary length
string,
and accessing it through a instance of Object.component.

I believe your function "TheHandle" will work with this design.
Note that Object can now access varying length strings. Your design
forces Object to contain homogeneous lenght strings.

Jim Rogers
Colorado Springs, Colorado

Re: Subtypes do not Statically Match

[John Harbaugh]

Thanks for the example solution.  Yes, it does work.  Interestingly,
using a constrained subtype of String cures the subtype mismatch in the
original post, but the problem then mutates into accessibility
violations.  I just wanted to know if there is a way to convert or
qualify the subtype so as to achieve a match.  From what I've read so
far, the answer is no.

Best regards,

	- John

James S. Rogers wrote:
> 
> John Harbaugh wrote in message <377A8C1A.6EFE0FF7@boeing.com>...
> >Hi all -
> >
> >Suppose I have a record with an unconstrained array component which is
> >constrained by the record discriminant.  Now I want to pass a record
> >pointer (oops! access value) to a function which will return a pointer
> >to the array component:
> >
> >
> >package Parent is
> >
> >   type Object(Max : Positive) is tagged record
> >      Component : aliased String(1..Max);
> >   end record;
> >
> >   type String_Ref is access all String;
> >
> >   function The_Handle(Obj : access Object) return String_Ref;
> >end;
> >
> >package body Parent is
> >
> >   function The_Handle(Obj : access Object) return String_Ref is
> >   begin
> >      return Obj.Component'access;
> >      --Error: object subtype must statically match designated subtype
> >   end;
> >
> >end;
> >
> >BTW, this works if we pass in an object to the function rather than an
> >access value.  But if we want to process a heterogeneous list of objects
> >from the class, we need to use pointers.
> 
> If you want to deal with a heterogeneous list of objects you need to change
> your data definitions:
> 
> type String_Access is access String;
> 
> type Object is record
>    Component : String_Access;
> end record;
> 
> You will create the list by dynamically allocating the neccessary length
> string,
> and accessing it through a instance of Object.component.
> 
> I believe your function "TheHandle" will work with this design.
> Note that Object can now access varying length strings. Your design
> forces Object to contain homogeneous lenght strings.
> 
> Jim Rogers
> Colorado Springs, Colorado

Re: Subtypes do not Statically Match

[Robert I. Eachus]

John Harbaugh wrote:
 
> Thanks for the example solution.  Yes, it does work.  Interestingly,
> using a constrained subtype of String cures the subtype mismatch in the
> original post, but the problem then mutates into accessibility
> violations.  I just wanted to know if there is a way to convert or
> qualify the subtype so as to achieve a match.  From what I've read so
> far, the answer is no.

   Correct, but so far no one has told you why it is no.  Normally in
Ada a string (for now assume a parameter S: String) is an object with
both bounds and a matching array of characters.  But you can have a
subtype Four_String is Sring(1..4);  In this case objects of the subtype
don't need to be stored with bounds, but if they are passed to a
procedure with a parameter of type String, the compiler must create an
object with included bounds to pass.

   Now for the compilication in your case.  The record component has a
subtype that depends on a discriminant.  The compiler has to compute
bounds for the  component from the discriminant, therefore the string
subcomponent may not be stored with bounds included, so there is no
object to point to that looks like a normal string.

   The best fix is to use unbounded strings from Annex A.  These will
meet your requirements and do what you want.  You can also write a
package like this, or like bounded_strings yourself, but why duplicate
effort?
-- 

                                        Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Subtypes do not Statically Match

[Robert A Duff]

John Harbaugh <john.s.harbaugh2@boeing.com> writes:

> Suppose I have a record with an unconstrained array component which is
> constrained by the record discriminant.  Now I want to pass a record
> pointer (oops! access value) to a function which will return a pointer
> to the array component: [...and make heterogeneous lists of strings of
different lengths]

You can't do exactly that (as you've discovered).  But why not make a
heterogeneous list of the record objects, using pointers to the record?
Why do you want to reach inside the record and make a pointer to the
string?

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: Subtypes do not Statically Match

[Gautier]

>    function The_Handle(Obj : access Object) return String_Ref is
                               ^
A detail: you don't need the access there ( C's * or Pascal's VAR ):
the "in" parameter will pass a reference for that object; an explicit
"access" might even cause slowdowns (pointer on pointer) in some cases!

>    begin
>       return Obj.Component'access;
>       --Error: object subtype must statically match designated subtype
>    end;

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Subtypes do not Statically Match

[John Harbaugh]

Quite true.  The access parameter was chosen because we want to pass a
pointer from a list (classwide pointers actually), rather than to force
passing by reference.  

Cheers,

	- John

Gautier wrote:
> 
> >    function The_Handle(Obj : access Object) return String_Ref is
>                                ^
> A detail: you don't need the access there ( C's * or Pascal's VAR ):
> the "in" parameter will pass a reference for that object; an explicit
> "access" might even cause slowdowns (pointer on pointer) in some cases!
> 
> >    begin
> >       return Obj.Component'access;
> >       --Error: object subtype must statically match designated subtype
> >    end;
> 
> --
> Gautier
> 
> --------
> http://members.xoom.com/gdemont/

Re: Subtypes do not Statically Match

[Ted Dennison]

In article <377A8C1A.6EFE0FF7@boeing.com>,
  John Harbaugh <john.s.harbaugh2@boeing.com> wrote:

>    type Object(Max : Positive) is tagged record
>       Component : aliased String(1..Max);
>    end record;
>
>    type String_Ref is access all String;
...
>    function The_Handle(Obj : access Object) return String_Ref is
>    begin
>       return Obj.Component'access;
>       --Error: object subtype must statically match designated subtype
>    end;

Why don't you just use the routines in Ada.Strings to perform this
function? I don't see anything you are doing that couldn't be done that
way, and you wouldn't have to debug the translation routines.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.