C-style 'union' in Ada?

C-style 'union' in Ada?

[Brian Catlin]

I'm still trying to get both lobes around the Ada paradigm.  I have a record that I want to hold a pointer to a buffer which is
either a String or Wide_String, but I don't want to statically declare which, so using a variant record won't work (at least given
my understanding).  Likewise, I don't want to have two record definitions, one for String, and one for Wide_String.  In the package
I'm designing, I don't care whether it is a String or Wide_String, I will just pass it to the file I/O packages (stream, in this
case).  In C, I would:

struct
    {
    ULONG    length;

    union
        {
        STRING_DESC                *ansi_string;
        WIDE_STRING_DESC    *wide_string;
        } strings;
    } string_desc;

and then:

struct
    {
    ...
    string_desc    file_name;
    ...
    } some_struct;

What is the idiom or method to use in Ada?

 -Brian

Re: C-style 'union' in Ada?

[tmoran]

>record that I want to hold a pointer to a buffer which is either a String
>or Wide_String, ...
>...  In the package I'm designing, I don't care whether it is a
>String or Wide_String, I will just pass it to the file I/O packages
>(stream, in this case).  In C, I would:
  How *do* you tell which it is?  Or do you really truly neither know
nor care?  If so, then the pointer itself is the abstraction
level - it's a black box of bits.  It could just as well be an
integer, or an array of bytes, whatever.
  If you do have a way to tell, can you incorporate that as a
discriminant in a variant record?  eg.

  type string_desc(Is_Wide : Boolean) is record
    length : Interfaces.C.Unsigned_Long;
    case Is_Wide is
      when True =>
        ansi_string : String_Desc;
      when False =>
        wide_string : Wide_String_Desc;
    end case;
  end record;

of course
struct
    {
    ...
    string_desc    file_name;
    ...
    } some_struct;
will in turn need a discriminant to pass along:
  type some_struct(Uses_Wide_String : Boolean) is record
    ...
    file_name : string_desc(Is_Wide => Uses_Wide_String);
    ...
  end record;

It's possible that tagged types would be appropriate.  An abstract
parent type with primitive procedures declared for those operations
that treat an object of the type as a black box, and abstract
primitives for those operations that *must* be declared separately
depending on the child type being ansi_string or wide_string.

Re: C-style 'union' in Ada?

[DuckE]

Here is a comparable definition (I put it in a small program to make sure it
compiled :-)
I didn't include a separate length field since you don't really need it with
Ada.  The length of the string may be found using
"str.ansi_string.all'length" or "str.wide_string.all'length".

Note that a default descriminant is used for the record such that the type
of the record may be changed dynamically at run time (by assigning the whole
record).


with Ada.Strings.Unbounded;  -- Defines String_Access and Free
 use Ada.Strings.Unbounded;
with Ada.Strings.Wide_Unbounded; -- Defines Wide_String_Access and Free
 use Ada.Strings.Wide_Unbounded;

procedure string_demo is

  type str_type is ( ansi, wide );

  type string_desc( str_select : str_type := ansi ) is
    record
      case str_select is
        when ansi =>
          ansi_string : String_Access;
        when wide =>
          wide_string : Wide_String_Access;
      end case;
    end record;

begin
  declare
    str : string_desc;
  begin
    str := ( str_select => ansi, ansi_string => new String'( "Hello" ) );
    Free( str.ansi_string );
    str := ( str_select => wide, wide_string => new Wide_String'(
"There" ) );
    Free( str.wide_string );
  end;
end string_demo;


I hope this helps,
SteveD


"Brian Catlin" <briancatlin@mindspring.com> wrote in message
news:9l7qon$d78$1@nntp9.atl.mindspring.net...
> I'm still trying to get both lobes around the Ada paradigm.  I have a
record that I want to hold a pointer to a buffer which is
> either a String or Wide_String, but I don't want to statically declare
which, so using a variant record won't work (at least given
> my understanding).  Likewise, I don't want to have two record definitions,
one for String, and one for Wide_String.  In the package
> I'm designing, I don't care whether it is a String or Wide_String, I will
just pass it to the file I/O packages (stream, in this
> case).  In C, I would:
>
> struct
>     {
>     ULONG    length;
>
>     union
>         {
>         STRING_DESC                *ansi_string;
>         WIDE_STRING_DESC    *wide_string;
>         } strings;
>     } string_desc;
>
> and then:
>
> struct
>     {
>     ...
>     string_desc    file_name;
>     ...
>     } some_struct;
>
> What is the idiom or method to use in Ada?
>
>  -Brian
>
>
>

Re: C-style 'union' in Ada?

[Brian Catlin]

I didn't know that a discriminant could be assigned at run time.  This is close to what I want to do.

Thanks!
 -Brian

"DuckE" <nospam_steved94@home.com> wrote in message news:7E0e7.12187$vW2.6599957@news1.sttln1.wa.home.com...
> Here is a comparable definition (I put it in a small program to make sure it
> compiled :-)
> I didn't include a separate length field since you don't really need it with
> Ada.  The length of the string may be found using
> "str.ansi_string.all'length" or "str.wide_string.all'length".
>
> Note that a default descriminant is used for the record such that the type
> of the record may be changed dynamically at run time (by assigning the whole
> record).
>
>
> with Ada.Strings.Unbounded;  -- Defines String_Access and Free
>  use Ada.Strings.Unbounded;
> with Ada.Strings.Wide_Unbounded; -- Defines Wide_String_Access and Free
>  use Ada.Strings.Wide_Unbounded;
>
> procedure string_demo is
>
>   type str_type is ( ansi, wide );
>
>   type string_desc( str_select : str_type := ansi ) is
>     record
>       case str_select is
>         when ansi =>
>           ansi_string : String_Access;
>         when wide =>
>           wide_string : Wide_String_Access;
>       end case;
>     end record;
>
> begin
>   declare
>     str : string_desc;
>   begin
>     str := ( str_select => ansi, ansi_string => new String'( "Hello" ) );
>     Free( str.ansi_string );
>     str := ( str_select => wide, wide_string => new Wide_String'(
> "There" ) );
>     Free( str.wide_string );
>   end;
> end string_demo;
>
>
> I hope this helps,
> SteveD

Re: C-style 'union' in Ada?

[Martin Dowie]

The trick (if you could call it that!) is to include a default value
for the discriminant in the type definition. You can then change its
value at will. If you don't have a default then you have to contraint
the object when you declare it - which then fixes it to that value.

Brian Catlin <briancatlin@mindspring.com> wrote in message
news:9la73h$vvs$1@slb6.atl.mindspring.net...
> I didn't know that a discriminant could be assigned at run time.  This is
close to what I want to do.
>
> Thanks!
>  -Brian
>
> "DuckE" <nospam_steved94@home.com> wrote in message
news:7E0e7.12187$vW2.6599957@news1.sttln1.wa.home.com...
[snip]
> > procedure string_demo is
> >
> >   type str_type is ( ansi, wide );
> >
> >   type string_desc( str_select : str_type := ansi ) is
> >     record
> >       case str_select is
> >         when ansi =>
> >           ansi_string : String_Access;
> >         when wide =>
> >           wide_string : Wide_String_Access;
> >       end case;
> >     end record;
> >
> > begin
> >   declare
> >     str : string_desc;
> >   begin
> >     str := ( str_select => ansi, ansi_string => new
String'( "Hello" ) );
> >     Free( str.ansi_string );
> >     str := ( str_select => wide, wide_string => new Wide_String'(
> > "There" ) );
> >     Free( str.wide_string );
> >   end;
> > end string_demo;
>

Re: C-style 'union' in Ada?

[Ole-Hjalmar Kristensen]

"Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:

> The trick (if you could call it that!) is to include a default value
> for the discriminant in the type definition. You can then change its
> value at will. If you don't have a default then you have to contraint
> the object when you declare it - which then fixes it to that value.

Yes, but you can only change it with a whole record assignment.

> 
> Brian Catlin <briancatlin@mindspring.com> wrote in message
> news:9la73h$vvs$1@slb6.atl.mindspring.net...
> > I didn't know that a discriminant could be assigned at run time.  This is
> close to what I want to do.
> >
> > Thanks!
> >  -Brian
> >
> > "DuckE" <nospam_steved94@home.com> wrote in message
> news:7E0e7.12187$vW2.6599957@news1.sttln1.wa.home.com...
> [snip]
> > > procedure string_demo is
> > >
> > >   type str_type is ( ansi, wide );
> > >
> > >   type string_desc( str_select : str_type := ansi ) is
> > >     record
> > >       case str_select is
> > >         when ansi =>
> > >           ansi_string : String_Access;
> > >         when wide =>
> > >           wide_string : Wide_String_Access;
> > >       end case;
> > >     end record;
> > >
> > > begin
> > >   declare
> > >     str : string_desc;
> > >   begin
> > >     str := ( str_select => ansi, ansi_string => new
> String'( "Hello" ) );
> > >     Free( str.ansi_string );
> > >     str := ( str_select => wide, wide_string => new Wide_String'(
> > > "There" ) );
> > >     Free( str.wide_string );
> > >   end;
> > > end string_demo;
> >
> 
> 

-- 
Kabelsalat ist gesund.

Ole-Hj. Kristensen

Re: C-style 'union' in Ada?

[Martin Dowie]

Ole-Hjalmar Kristensen <ohk@clustra.com> wrote in message
news:umqsnev3rqb.fsf@maestro.clustra.com...
> "Martin Dowie" <martin.dowie@nospam.baesystems.com> writes:
>
> > The trick (if you could call it that!) is to include a default value
> > for the discriminant in the type definition. You can then change its
> > value at will. If you don't have a default then you have to contraint
> > the object when you declare it - which then fixes it to that value.
>
> Yes, but you can only change it with a whole record assignment.

of course - and I think this is what the OP wanted

Re: C-style 'union' in Ada?

[Ted Dennison]

In article <9l7qon$d78$1@nntp9.atl.mindspring.net>, Brian Catlin says...
>
>I'm still trying to get both lobes around the Ada paradigm.  I have a record 
>that I want to hold a pointer to a buffer which is either a String or 
>Wide_String, but I don't want to statically declare which, so using a variant 
>record won't work (at least given my understanding).  Likewise, I don't want 
>to have two record definitions, one for String, and one for Wide_String.  In 
>the package I'm designing, I don't care whether it is a String or Wide_String, 
>I will just pass it to the file I/O packages (stream, in this case).  In C, I 
>would:

First off, its wrong that you have to staticly declare which one you are using
for a variant record. If you define the record to have a default value for the
variant, then you can change it at runtime. The catch is that you have to change
*all* the record fields along with the variant when you do it.

Secondly, I don't ever end up with structures like this in my Ada code (unless
I'm interfacing to some OS routine that uses them). I'm not saying that its
impossible that you actually need this, just that its highly unlikely. Its even
more unlikely that you really need a pointer to it. So you really ought to tell
us *why* you feel like you need this structure.

Thirdly, if I *did* have to have something like this for some reason (which
right now I cannot fathom), I'd probably define two structures (no more or less
work than defining one structure with both of them in it), and use pointer-based
unchecked_conversion to change my view of the buffer between them. But its more
likely I'd find a way to structurally arrange things so that I didn't need to do
that...

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: C-style 'union' in Ada?

[David Brown]

Ted Dennison <dennison@telepath.com> wrote:
> In article <9l7qon$d78$1@nntp9.atl.mindspring.net>, Brian Catlin says...
>>
>>I'm still trying to get both lobes around the Ada paradigm.  I have a
>>record that I want to hold a pointer to a buffer which is either a String
>>or Wide_String, but I don't want to statically declare which, so using a
>>variant record won't work (at least given my understanding).  Likewise, I
>>don't want to have two record definitions, one for String, and one for
>>Wide_String.  In the package I'm designing, I don't care whether it is a
>>String or Wide_String, I will just pass it to the file I/O packages
>>(stream, in this case).  In C, I would:

> Thirdly, if I *did* have to have something like this for some reason
> (which right now I cannot fathom), I'd probably define two structures (no
> more or less work than defining one structure with both of them in it),
> and use pointer-based unchecked_conversion to change my view of the
> buffer between them. But its more likely I'd find a way to structurally
> arrange things so that I didn't need to do that...

I have recently encountered a concrete example of the need for something
like this.  The application is storing variable sized data fields in fixed
length records (say disk sectors).  The block is defined as a large string.
The beginning of the block contains lengths for each of the variable sized
fields.  The data items start at the end of the record and work their way
backward.

Basically, there are two different views of the block and the boundary
between them depends on the sizes of the data items.

Unchecked conversions of access values seems to be the easiest way to deal
with this.

Dave Brown

Re: C-style 'union' in Ada?

[Brian Catlin]

"David Brown" <davidb@davidb.org> wrote in message news:WUXe7.15629$ZM2.1376965@newsread2.prod.itd.earthlink.net...
> Ted Dennison <dennison@telepath.com> wrote:
> > In article <9l7qon$d78$1@nntp9.atl.mindspring.net>, Brian Catlin says...
> >>
> >>I'm still trying to get both lobes around the Ada paradigm.  I have a
> >>record that I want to hold a pointer to a buffer which is either a String
> >>or Wide_String, but I don't want to statically declare which, so using a
> >>variant record won't work (at least given my understanding).  Likewise, I
> >>don't want to have two record definitions, one for String, and one for
> >>Wide_String.  In the package I'm designing, I don't care whether it is a
> >>String or Wide_String, I will just pass it to the file I/O packages
> >>(stream, in this case).  In C, I would:
>
[...snip...]
>
> I have recently encountered a concrete example of the need for something
> like this.  The application is storing variable sized data fields in fixed
> length records (say disk sectors).  The block is defined as a large string.
> The beginning of the block contains lengths for each of the variable sized
> fields.  The data items start at the end of the record and work their way
> backward.
>
> Basically, there are two different views of the block and the boundary
> between them depends on the sizes of the data items.
>
> Unchecked conversions of access values seems to be the easiest way to deal
> with this.

This is very similar to what I'm doing.  I was trying to avoid unchecked conversion.  I had assumed that there would be a better
way.

 -Brian

Re: C-style 'union' in Ada?

[Ted Dennison]

In article <9li279$mhm$1@slb2.atl.mindspring.net>, Brian Catlin says...
>
>This is very similar to what I'm doing.  I was trying to avoid unchecked 
>conversion.  I had assumed that there would be a better way.

Well, converting between types is pretty much what Unchecked_Conversion is in
the language for. It may look a bit ugly and scary, but that's because the
activity you are doing is *also* a bit ugly and scary (if sometimes nessecary).
Consider it truth in advertising. :-)

Note that since Unchecked_Conversion is a function, an assignment of the value
will occur. That's why we usually perform it on pointers when the target data is
large buffers.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: C-style 'union' in Ada?

[Jeffrey Carter]

Ted Dennison wrote:
> 
> Note that since Unchecked_Conversion is a function, an assignment of the value
> will occur. That's why we usually perform it on pointers when the target data is
> large buffers.

Unchecked_Conversion is allowed to return its result "by reference".
This allows a good compiler to avoid assignment when possible.

-- 
Jeffrey Carter

Re: C-style 'union' in Ada?

[Ted Dennison]

In article <3B7D4894.C342A35C@boeing.com>, Jeffrey Carter says...
>
>Unchecked_Conversion is allowed to return its result "by reference".
>This allows a good compiler to avoid assignment when possible.

Really? I wouldn't think that's possible, since the source and target are going
to be distinct objects with discinct storage addresses. Clearly the data isn't
getting from one to the other without a copy happening somewhere.

If you are talking about doing something like accessing a field after an
unchecked_conversion, eg. doing a: 
if Convert_To_String (Big_Hairy_Record)(1) = 'a' then ...

then I could see it. However, I know the one time I checked into it (on the DEC
Ada83 compiler), it would put a full copy on the stack even in this instance.
Does anyone know what some of the modern compilers do?

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: C-style 'union' in Ada?

[Samuel T. Harris]

Ted Dennison wrote:
> 
> In article <9li279$mhm$1@slb2.atl.mindspring.net>, Brian Catlin says...
> >
> >This is very similar to what I'm doing.  I was trying to avoid unchecked
> >conversion.  I had assumed that there would be a better way.
> 
> Well, converting between types is pretty much what Unchecked_Conversion is in
> the language for. It may look a bit ugly and scary, but that's because the
> activity you are doing is *also* a bit ugly and scary (if sometimes nessecary).
> Consider it truth in advertising. :-)
> 
> Note that since Unchecked_Conversion is a function, an assignment of the value
> will occur. That's why we usually perform it on pointers when the target data is
> large buffers.
> 

Of course, using unchecked_conversion on pointers has its own
brand of pitfalls.

Consider the Rational R1000 machines where each access type
involved very own storage pool and a pointer was actually
an offset from the base address of that storage pool.
In this environment it is meaningless to convert an access
to an 8-bit integer to an access to an 8-bit character
since the pointer of the character will dereference to a
completely different memory location.

In Ada 83, if one was assured that access types were compatible
with system.address, then access types usually used a more
conventional heap allocation and all was good with the code.

However, in Ada 95, where I can create my own storage pools,
then I may experience other problems using conversions between
pointers. The "address" of the converted pointer may resolve
to the same memory location, but is my storage pool is being
used for access to controlled types and I convert it to some access
to an non-controlled type, then my carefully construct, reference
counting, garbage collection, storage pool mechanism is inviolated.
I suppose converting a access to a non-controlled type into an
access to a controlled type involving a storage pool would be
even worse. That carefully constructed mechanism can quickly
become insane from all the "false" dereferences.

-- 
Samuel T. Harris, Senior Software Engineer II
Raytheon, Aerospace Engineering Services
"If you can make it, We can fake it!"

Variable sizes for record fields (was: C-style 'union' in Ada)

[Larry Kilgallen]

In article <WUXe7.15629$ZM2.1376965@newsread2.prod.itd.earthlink.net>, David Brown <davidb@davidb.org> writes:
> Ted Dennison <dennison@telepath.com> wrote:
>> In article <9l7qon$d78$1@nntp9.atl.mindspring.net>, Brian Catlin says...
>>>
>>>I'm still trying to get both lobes around the Ada paradigm.  I have a
>>>record that I want to hold a pointer to a buffer which is either a String
>>>or Wide_String, but I don't want to statically declare which, so using a
>>>variant record won't work (at least given my understanding).  Likewise, I
>>>don't want to have two record definitions, one for String, and one for
>>>Wide_String.  In the package I'm designing, I don't care whether it is a
>>>String or Wide_String, I will just pass it to the file I/O packages
>>>(stream, in this case).  In C, I would:
> 
>> Thirdly, if I *did* have to have something like this for some reason
>> (which right now I cannot fathom), I'd probably define two structures (no
>> more or less work than defining one structure with both of them in it),
>> and use pointer-based unchecked_conversion to change my view of the
>> buffer between them. But its more likely I'd find a way to structurally
>> arrange things so that I didn't need to do that...
> 
> I have recently encountered a concrete example of the need for something
> like this.  The application is storing variable sized data fields in fixed
> length records (say disk sectors).  The block is defined as a large string.
> The beginning of the block contains lengths for each of the variable sized
> fields.  The data items start at the end of the record and work their way
> backward.

This sounds to me like the beginning of the record definition is the
discriminant values and the end of the record is the text fields.
The one trick, to achieve a fixed size, is to have an extra discriminant
to define the size of the "middle".  This is based on my experience with
Ada83.  Perhaps Ada95 lets you do more "math" with discriminant values
to avoid the need for an extra discriminant.

Re: Variable sizes for record fields

[David Brown]

Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:

>> I have recently encountered a concrete example of the need for something
>> like this.  The application is storing variable sized data fields in fixed
>> length records (say disk sectors).  The block is defined as a large string.
>> The beginning of the block contains lengths for each of the variable sized
>> fields.  The data items start at the end of the record and work their way
>> backward.
> 
> This sounds to me like the beginning of the record definition is the
> discriminant values and the end of the record is the text fields.
> The one trick, to achieve a fixed size, is to have an extra discriminant
> to define the size of the "middle".  This is based on my experience with
> Ada83.  Perhaps Ada95 lets you do more "math" with discriminant values
> to avoid the need for an extra discriminant.

To make this work, I would need several things.  First of all, my
discriminants would have to be an array of values whose size is based on
another discriminant.

Second, I need to represent things (like the size of the middle) without
taking up any space.  They need to be computed and that's it.  The sizes of
each of the other text strings needs to be based on the array of
discriminant sizes.

Third, I need to be able to change the structure in-place.  It is
complicated code, and I don't think that the compiler would understand all
of the cases involved, even if you could arbitrarily assign to
discriminants like this.

I wasn't even able to make a simple record containing a discriminant and a
string of that length and come up with a way to make the particular
discriminant a constant and not take up any storage.

Dave Brown

Re: Variable sizes for record fields

[Larry Kilgallen]

In article <NV2f7.16792$ZM2.1470093@newsread2.prod.itd.earthlink.net>, David Brown <s-complangada@davidb.org> writes:
> Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
> 
>>> I have recently encountered a concrete example of the need for something
>>> like this.  The application is storing variable sized data fields in fixed
>>> length records (say disk sectors).  The block is defined as a large string.
>>> The beginning of the block contains lengths for each of the variable sized
>>> fields.  The data items start at the end of the record and work their way
>>> backward.
>> 
>> This sounds to me like the beginning of the record definition is the
>> discriminant values and the end of the record is the text fields.
>> The one trick, to achieve a fixed size, is to have an extra discriminant
>> to define the size of the "middle".  This is based on my experience with
>> Ada83.  Perhaps Ada95 lets you do more "math" with discriminant values
>> to avoid the need for an extra discriminant.
> 
> To make this work, I would need several things.  First of all, my
> discriminants would have to be an array of values whose size is based on
> another discriminant.

An Ada record type always has a fixed number of discriminants (often zero).

> Second, I need to represent things (like the size of the middle) without
> taking up any space.  They need to be computed and that's it.  The sizes of
> each of the other text strings needs to be based on the array of
> discriminant sizes.

Check into the Ada95 angle.

> Third, I need to be able to change the structure in-place.  It is
> complicated code, and I don't think that the compiler would understand all
> of the cases involved, even if you could arbitrarily assign to
> discriminants like this.

	POINTER_TO_NEW_RECORD := new MY_RECORD_TYPE (
		SIZE_1 => 42,
		SIZE 2 => 42,
		SIZE_3 => 42,
		SIZE_REST => 42 );

> I wasn't even able to make a simple record containing a discriminant and a
> string of that length and come up with a way to make the particular
> discriminant a constant and not take up any storage.

That is just the point.  Ada requires that the discriminants of the record
can be recognized at run time.  There is no way to do that without taking
up space.

Re: Variable sizes for record fields

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <NV2f7.16792$ZM2.1470093@newsread2.prod.itd.earthlink.net>, David Brown <s-complangada@davidb.org> writes:
> > Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote:
> >>> I have recently encountered a concrete example of the need for something
> >>> like this.  The application is storing variable sized data fields in fixed
> >>> length records (say disk sectors).  The block is defined as a large string.
> >>> The beginning of the block contains lengths for each of the variable sized
> >>> fields.  The data items start at the end of the record and work their way
> >>> backward.
> >>
> >> This sounds to me like the beginning of the record definition is the
> >> discriminant values and the end of the record is the text fields.
> >> The one trick, to achieve a fixed size, is to have an extra discriminant
> >> to define the size of the "middle".  This is based on my experience with
> >> Ada83.  Perhaps Ada95 lets you do more "math" with discriminant values
> >> to avoid the need for an extra discriminant.
> >
> > To make this work, I would need several things.  First of all, my
> > discriminants would have to be an array of values whose size is based on
> > another discriminant.
> 
> An Ada record type always has a fixed number of discriminants (often zero).

Additionally, the discriminants must be discrete types.

> > I wasn't even able to make a simple record containing a discriminant and a
> > string of that length and come up with a way to make the particular
> > discriminant a constant and not take up any storage.
> 
> That is just the point.  Ada requires that the discriminants of the record
> can be recognized at run time.  There is no way to do that without taking
> up space.

Another hint :

For records that have arrays sized by discriminant(s), it is best to declare
those arrays starting from 1. Otherwise you'll have sizing difficulties, because
you won't be able to use an expression within the array range to compute the
last subscript, within the range.

-- 
Warren W. Gay VE3WWG
http://members.home.net/ve3wwg

Re: Variable sizes for record fields

[Ken Burtch]

"Warren W. Gay VE3WWG" wrote:

> Another hint :
> 
> For records that have arrays sized by discriminant(s), it is best to declare
> those arrays starting from 1. Otherwise you'll have sizing difficulties, because
> you won't be able to use an expression within the array range to compute the
> last subscript, within the range.

Nor will you be able to declare a null array using a range of 1..0.

-- 
Ken O. Burtch: System Manager in a Box / Lintel       : Pegasoft
http://www.vaxxine.com/pegasoft                       : R.R.#1
Bio: 35;Bsc,UI,Lang,Games;Toons,Elves,SF,Pizza;Xian   : Jordan Station,
ON
``````````````````````````````````````````````````````` Canada L0R 1S0