Pros/Cons of choosing one of the these two methods

[Ten_Mile_Hike]

Both of the ButtonClick procedure variations below work as expected. I am just
wondering if either method has advantages over the other or is it just a matter of style?

The only difference between the two procedures are the SetLength parameters used in
Line #9 vs. Line #15

TIA

Code: Pascal  [Select][+][-]

1. var
2.   Form1: TForm1;
3.   A:Array of string;
4.  
5. implementation{$R *.lfm}{ TForm1 }
6.  
7. procedure TForm1.Button1Click(Sender:TObject);
8. begin
9. setlength(A,Length(A)+1);
10. A[high(A)]:=(Sender as TButton).Name;
11. end;
12.  
13. procedure TForm1.Button2Click(Sender:TObject);
14. begin
15. setLength(A,High(A)+2);
16. A[high(A)]:=(Sender as TButton).Name;
17. end;
18.                    

[Zvoni]

Intuitively, i‘d go with the first, because an unset dynamic array has length 0, while High of an unset dynamic array should be „undefined“, though i accept that it probably returns „something“

[cdbc]

Hi
There seems to be some kind of new(ish) compiler-switch regarding dynamic arrays: {$ModeSwitch arrayoperators}
then you can do:

Code: Pascal  [Select][+][-]

1. A+= [(Sender as TButton).Name];

Just a thought...
P.s.: I too, would go with the first one.
Regards Benny

[Ten_Mile_Hike]

Thank you both. Wow; I can't keep track of the myriad of modes and their commensurate compiler switches.
I wonder how it is determined if a new capability is made available via compiler switches as opposed to
an actual new Pascal command?

Is a new capability introduced via a compiler switch or Macro etc. considered to be NOT breaking the Pascal
Standard whereas actually adding a new command to the language would anger the Pascal purists???

I personally would prefer as many useful commands as possible be added to any language as long as it made sense
to do so. I suspect that programmers as a whole exhibit "purist" /  "OCD" tendencies in all aspects of our lives. And
maybe that is a good thing...

[Thaddy]

There is no real difference in normal use except the second one is over-dimensioned.
FPC string types are #0 terminated anyway, also shortstrings.
One remark about the code though:
You declare it as an array of string, but that can be different. It is actually a TComponentName.
See: https://www.freepascal.org/docs-html/rtl/classes/tcomponentname.html
That does not matter too much too, but the real string type of the array in Lazarus is UTF8String, so implicit conversion will likely take place.

[Curt Carpenter]

I personally would prefer as many useful commands as possible be added to any language as long as it made sense
to do so. I suspect that programmers as a whole exhibit "purist" /  "OCD" tendencies in all aspects of our lives. And
maybe that is a good thing...

Not purism or OCD -- I think programmers want a durable, stable platform.

[Stefan Glienke]

Intuitively, i‘d go with the first, because an unset dynamic array has length 0, while High of an unset dynamic array should be „undefined“, though i accept that it probably returns „something“

High is defined as Length-1 so High of an unset dynamic array (which is equal to nil) is -1.
See doc: https://www.freepascal.org/docs-html/rtl/system/high.html

[Ten_Mile_Hike]

Thaddy,
Regarding being over dimensioned, I thought so also, but when I used

Code: Pascal  [Select][+][-]

1. setLength(A,High(A)+1)

instead of

Code: Pascal  [Select][+][-]

1. setLength(A,High(A)+2)

I got improper results when I used

Code: Pascal  [Select][+][-]

1. For x:=Low(A) to High(A) Do Memo1.lines.add(A[x]);

Maybe using TComponentName would fix tha.t

[ASerge]

I am just wondering if either method has advantages over the other or is it just a matter of style?

In the first case, it is a little faster, in the second - a little smaller code size. Because the Length function is inlined, but the High function is not.
Of course, the first option looks more natural.

[Zvoni]

Intuitively, i‘d go with the first, because an unset dynamic array has length 0, while High of an unset dynamic array should be „undefined“, though i accept that it probably returns „something“

High is defined as Length-1 so High of an unset dynamic array (which is equal to nil) is -1.
See doc: https://www.freepascal.org/docs-html/rtl/system/high.html

I thought so.
OTOH, consider this snippet

Code: Pascal  [Select][+][-]

1. Var
2.    A:Array[-10..-1] of string;
3.  

High returns -1, too.
That’s the reason why i‘d go with the first one when setting a (new) „length“ of a dynamic array

[Zvoni]

Thaddy,
Regarding being over dimensioned, I thought so also, but when I used

Code: Pascal  [Select][+][-]

1. setLength(A,High(A)+1)

instead of

Code: Pascal  [Select][+][-]

1. setLength(A,High(A)+2)

I got improper results when I used

Code: Pascal  [Select][+][-]

1. For x:=Low(A) to High(A) Do Memo1.lines.add(A[x]);

Maybe using TComponentName would fix tha.t

Because High(A)+1 returns 0 for an unset dynamic array
High doesn’t return the count (length) of a dynamic array

[MarkMLl]

I'd suggest that if you're using SetLength(), then you should be basing it on Length(). If that doesn't work as expected then it's the RTL developers' problem.

I personally would prefer as many useful commands as possible be added to any language as long as it made sense
to do so.

Definitely not: the underlying language should be as simple as possible, with everything else in libraries loaded (or ignored) as necessary. That is something that Wirth learned between Pascal and Modula-2, although the library concept might have been introduced slightly earlier by IBM.

Having said that, it would be desirable if the language's syntax could be extended, which by and large is not possible for Pascal and its siblings.

MarkMLl

[Warfley]

Thank you both. Wow; I can't keep track of the myriad of modes and their commensurate compiler switches.
I wonder how it is determined if a new capability is made available via compiler switches as opposed to
an actual new Pascal command?

The big problem is usually backwards compatibility. With Array Operators for example, before ArrayOperators modeswitch was added, you could already overload operators for arrays:

Code: Pascal  [Select][+][-]

1. type
2.   TIntArray = array of Integer;
3.  
4. operator +(const lhs, rhs: TIntArray): TIntArray;
5. var
6.   i, len: Integer;
7. begin
8.   result:=nil;
9.   len := Length(lhs);
10.   if length(rhs)<len then
11.     len:=Length(rhs);
12.   SetLength(result, len);
13.   for i:=0 to len-1 do
14.     result[i]:=lhs[i]+rhs[i];
15. end;

ArrayOperators will make this code not compile anymore. Therefore it needs to be it's own switch so it does not break existing code

[Thaddy]

You can turn arrayoperators off. {$modeswitch arrayoperators-}
And then use concat() instead. I hate that feature just for an addition.
It is useless. And arrayoperators is a misnominer: it should be arrayoperator, there is just 1 (one).

[PascalDragon]

You can turn arrayoperators off. {$modeswitch arrayoperators-}
And then use concat() instead. I hate that feature just for an addition.
It is useless.

Complain to the Delphi developers then.

And arrayoperators is a misnominer: it should be arrayoperator, there is just 1 (one).

I had picked the plural for future proofing in case we should ever decide to overload other operators for arrays.