Watch, Follow, &
Connect with Us

QualityCentral

Public Report
Report From: Delphi-BCB/Compiler/Delphi/Language/Dynamic Arrays    [ Add a report in this area ]  
Report #:  1861   Status: Reported
Dynamic arrays should allow indexes of any ordinal type
Project:  Delphi Build #:  4.453
Version:    7.0 Submitted By:   David Marcus
Report Type:  New Feature Request Date Reported:  7/20/2002 2:25:00 PM
Severity:    Serious / Highly visible problem Last Updated: 5/2/2003 12:58:35 PM
Platform:    All versions Internal Tracking #:  
Resolution: None  Resolved in Build: : None
Duplicate of:  None
Voting and Rating
Overall Rating: (9 Total Ratings)
3.11 out of 5
Total Votes: None
Description
Static arrays allow indexes of any ordinal type. However, dynamic arrays currently are always integer-based with the index starting at 0. Delphi should have dynamic arrays that allow indexes of any ordinal type. See "Steps" for an example showing a suggested syntax.
Steps to Reproduce:
type
   Suit = ( Club, Diamond, Heart, Spade );

var
   X: dynamic array[ integer ] of integer;
   Y: dynamic array[ Suit ] of integer;
   Z: dynamic array[ Suit, integer ] of integer;
   J: integer;
   K: Suit;

begin

   getmem( X[ 3..5 ], Y[ Diamond..Spade ], Z[ 1..13, Suit ] )

   for J := 3 to 5 do
      X[ J ] := J;

   for K := Diamond to Spade do
      Y[ K ] := ord( K );

   for J := low( X ) to high( X ) do
      for K := low( Y ) to high( Y ) do
         Z[ J, K ] := X[ J ] + Y[ K ];

   dispose( X, Y, Z )
  
The syntax for open array parameters should be extended in the same way, e.g.,

procedure Clear( var X: dynamic array[ integer ] of integer );

var
   J: integer;
  
begin

   for J := low( X ) to high( X ) do
      X[ J ] := 0;
Workarounds
None
Attachment
None
Comments

Asleik Heisland at 7/28/2002 11:02:06 AM -
How should this be declared in an obvious/meaningful way?
I've rated it 2 as I feel this report could need more work on the syntax question, and it was a bit unclear to me what you mean by "same flexebility".

David Marcus at 8/15/2002 4:05:56 PM -
I've revised the report and  added a sample syntax in "Steps".

Robert Lee at 8/17/2002 4:49:04 AM -
Looking at your steps, I believe that you must include type info about the index in the declaration.   How would you propose to do that?  Also how would your propose to start at something other than zero?


David Marcus at 8/18/2002 11:12:51 AM -
First a comment: I would be ecstatic if Delphi simply allowed dynamic arrays with integer indexes to start at something other than zero--I'd often like to use 1. However, since Delphi allows indexes of any ordinal type for static arrays, it seems cleaner to allow the same for dynamic arrays.

Let me address your questions in reverse order:

> Also how would you propose to start at something other than zero?

My example has X starting at 3:

   getmem( X[ 3..5 ] );

(I originally wrote parentheses rather than brackets--that was a typo on my part.) This is basically just a Delphi translation of the Fortran

   allocate( X( 3:5 ) )

> I believe that you must include type info about the index in the declaration.

Can't the compiler determine the type when it allocates the array? I suppose that would introduce complications. How about something like this:

   var
      X: dynamic array[ integer ] of integer;
      Y: dynamic array[ Suit ] of integer;

   begin

      getmem( X[ 3..5 ], Y )

   end.

The word "dynamic" is already used by Delphi in a different context (for methods), so we might not want to use it here.  

Robert Lee at 8/19/2002 3:37:00 AM -
>David Marcus said - "First a comment: I would be ecstatic if Delphi simply allowed dynamic >arrays with integer indexes to start at something other than zero

There is nothing that says that you have to use [0].  Just skip it.  

>> Also how would you propose to start at something other than zero?
>My example has X starting at 3:
>
>   getmem( X[ 3..5 ] );

Computationally this is bad news as the offset (3 in this case) is not part of the declaration and therefore not a compile-time constant.  This means it would have to save the offset in the array variable (at some negative offset) then look it up and subtract it from every indexing operation.  This is likely to make each array access take 3-5 times longer than it currently does.

>   var
>     X: dynamic array[ integer ] of integer;
>      Y: dynamic array[ Suit ] of integer;
>
>The word "dynamic" is already used by Delphi in a different context (for methods), so we >might not want to use it here.  
>"

yeah, "dynamic" is spoken for and "[type]" overlaps with static arrays.  (BTW: you need the typeinfo to have compile-time typechecking of the index)

I would recommend:

   x: array of integer index suit;

with "index integer" being a default.

I am not, in favor of the offset.  

David Marcus at 8/20/2002 4:24:49 PM -
Skipping [0] makes range checking less effective and is an invitation to off-by-1 errors.

I wasn't suggesting this as a speed improvement, but a way to make code more understandable. If you want speed, allow the initial index to be part of the declaration.

Robert Lee at 8/21/2002 3:35:39 AM -
David Marcus said - "Skipping [0] makes range checking less effective and is an invitation to off-by-1 errors."

Valid point.  

David Marcus also said - "I wasn't suggesting this as a speed improvement, but a way to make code more understandable. If you want speed, allow the initial index to be part of the declaration.
"
I wasn't saying you were, but there has been a history of "wouldn't it be nice if..." changes implemented without consideration of the speed sequences, that then cause a minor furor when they turn out to be very slow and everyone is saddled with them.  

BTW: Here is a workaround for your situation that gives you exactly what you want for the price of having to deal with an extra local variable.

type
  TSomeOrdinal=1..3094237409;
  TArray=array[TSomeOrdinal] of integer;
  PArray=^TArray;
  TDynArray=array of integer;

var
  DynArray=TDynArray;
  A:PArray;

begin
  SetLength(DynArray,N);
  A:=PArray(DynArray);
  // Keep DynArray but Use A locally


Note that you could build a class around this and eliminate the extra variable at the expense of having to use Var.A[index] rather then the nicer looking Var[index]

David Marcus at 8/21/2002 8:43:30 PM -
The following program runs without error despite the range error.

{$R+}
{$Q+}
{$apptype console}
program Test;

type
  TSomeOrdinal=1..high(integer) div sizeof(integer);
  TArray=array[TSomeOrdinal] of integer;
  PArray=^TArray;
  TDynArray=array of integer;

var
  DynArray: TDynArray;
  A:PArray;

begin
  SetLength(DynArray,3);
  A:=PArray(DynArray);
  A[ 13 ] := 7;
  writeln( A[ 13 ] );

end. // Test.

David Marcus at 8/21/2002 8:34:10 PM -
"...rather than the nicer looking..." Yes, but nice looking code is exactly what I want. I've done my share of 0 to 1 "hacks". I'm looking for Borland to make these unnecessary.

Regarding

   A:=PArray(DynArray);

haven't you completely subverted range checking? Giving up range checking is the last thing I want to do.

I completely agree that we shouldn't ignore the speed of the code. However, I was thinking of #1861 as a supplement to what we have now rather than a replacement. Take a look at #2148. #2148 gives nonzero lower indexes for integer indexes without changing the speed of the code (the lower index is known at compile time). #1861 and #2148 could be implemented independently. Each would have their uses.

By the way, Fortran allows arbitrary lower indexes of arrays (sometimes the lower index is known at compile time and sometimes it isn't) even though the Fortran designers generally are very concerned with speed.

Robert Lee at 8/22/2002 5:41:38 AM -
David Marcus said - ""...rather than the nicer looking..." Yes, but nice looking code is exactly what I want. I've done my share of 0 to 1 "hacks". I'm looking for Borland to make these unnecessary."

Yes, I feel your pain here.  I've been trying to get a "nice" looking matrix class for years.

David Marcus also said - "Regarding   A:=PArray(DynArray); haven't you completely subverted range checking?"

Only half of it. <g> You get the lower end checking, but you lose the high bound checking.

David Marcus at 8/22/2002 5:53:03 PM -
> I've been trying to get a "nice" looking matrix class for years.

It is certainly long overdue. What do you want it to look like?

Robert Lee at 8/23/2002 2:41:57 AM -
David Marcus said - "> I've been trying to get a "nice" looking matrix class for years.

It is certainly long overdue. What do you want it to look like?
"

  M[i,j,k,...] //  i.e. multidimensional + not take nine function calls to get access to the data

  Internally, I would like to optinally make the dimensions indirect so that you can "swap" rows for example or sort etc. with only an index change.  

David Marcus at 8/21/2002 4:47:27 AM -
I've revised the description and the steps.

Ivan Levashew at 12/16/2006 1:38:41 PM -
In Ada, it looks like :

type Integer is range /implementation-defined/;

subtype Natural  is Integer range 0 .. Integer'Last;
subtype Positive is Integer range 1 .. Integer'Last;

type String is array(Positive range <>) of Character;
type Matrix is array(Natural range <>, Natural range <>) of Float;

String and Matrix are unconstrained types here. All the instances however are constrained,
any String and Matrix variable cannot change its length (instead Unbounded_Strings can) after initialization.
But we can define another variable.

Look at 37791, please (Delphi/Ada)

Server Response from: ETNACODE01

Copyright© 1994 - 2013 Embarcadero Technologies, Inc. All rights reserved.