Feature announcement: Dynamic array extensions

classic Classic list List threaded Threaded
94 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph


> On May 20, 2018, at 7:23 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> The compiler now implements a "+" operator for arrays which is the same as if Concat() would be called on the arrays.
>

I haven’t built it yet but I’m curious, does += now push an element to the array or does this just work to concat 2 arrays? I would expect:

a: array of string = ();
a += ‘foo’;


to push a single string on the array.

Also can you use type helpers with dynamic arrays yet? Thinking about how to extend them if possible.

Thanks.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
Am 24.05.2018 um 17:27 schrieb Ryan Joseph:

>
>> On May 20, 2018, at 7:23 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>>
>> The compiler now implements a "+" operator for arrays which is the same as if Concat() would be called on the arrays.
>>
> I haven’t built it yet but I’m curious, does += now push an element to the array or does this just work to concat 2 arrays? I would expect:
>
> a: array of string = ();
> a += ‘foo’;
>
>
> to push a single string on the array.

This is currently not supported. And to avoid backwards compatibility
problems with existing operator overloads you'd probably need to convert
it to a dynamic array first:

=== code begin ===

a += ['foo'];

=== code end ===

> Also can you use type helpers with dynamic arrays yet? Thinking about how to extend them if possible.

Type helpers for dynamic arrays are already possible in 3.0, however
they must be named array types (both for the declaration of the helper
as well as the array) and they must be the same type (so equal type
declarations in different units do not work).

=== code begin ===

{$modeswitch typehelpers}

type
   TLongIntArray = array of LongInt;

   TLongIntArrayHelper = type helper for TLongIntArray
     procedure Test;
   end;

procedure TLongIntArrayHelper.Test;
begin
   Writeln(Length(Self));
end;

var
   lia: TLongIntArray = (1, 2, 3);
begin
   lia.Test;
end.

=== code end ===

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Anthony Walter-3
I just wanted to drop this trick to work around problems with record helpers ..

If you wanted to create a record helper for a type that is not normally allowed, or perhaps you want to have multiple record helpers for the same type, consider defining your own separate type and make it contain said type with implicit conversions to work around those problem.

Example:

TArray<T> = array of T;

TArrayList<T> = record
public
{ The array acting as a list }
var Items: TArray<T>;
{ Convert an array to a list }
class operator Implicit(const Value: TArray<T>): TArrayList<T>;
{ Convert an open array to a list }
class operator Implicit(const Value: array of T): TArrayList<T>;
{ Convert a list to an array }
class operator Implicit(const Value: TArrayList<T>): TArray<T>;

Then in this example you can add all the methods you want to dynamic arrays, because you have your own type which is nothing more than an alias to a dynamic array (array of T). Methods such as:

{ Performs a simple safe copy of up to N elements }
procedure Copy(out List: TArrayList<T>; N: Integer);
{ Performs a fast unsafe copy of up to N elements }
procedure CopyFast(out List: TArrayList<T>; N: Integer);
{ Returns the lower bounds of the list }
function Lo: Integer;
{ Returns the upper bounds of the list }
function Hi: Integer;
{ Reverses the items in the list }
procedure Reverse;
{ Swap two items in the list }
procedure Exchange(A, B: Integer);
{ Adds and item to the end of the list }
procedure Push(const Item: T);
{ Appends an array of items to the list }
procedure PushRange(const Collection: array of T);
{ Remove an item from the end of the list }
function Pop: T;
{ Remove an item randomly from the list }
function PopRandom: T;
{ Return a copy of the list with items passing through a filter }
function Filter(Func: TFilterFunc<T>): TArrayList<T>;
{ Resurn the first item matching a condition }
function FirstOf(Func: TFilterFunc<T>): T;
{ Removes an item by index from the list and decresaes the count by one }
procedure Delete(Index: Integer);
{ Removes all items setting the count of the list to 0 }
procedure Clear;
{ Sort the items using a comparer }
procedure Sort(Order: TSortingOrder = soAscend; Comparer: TCompare<T> = nil);
{ Attempt to find the item using DefaultCompare }
function IndexOf(const Item: T): Integer; overload;

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On May 25, 2018, at 1:37 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> This is currently not supported. And to avoid backwards compatibility problems with existing operator overloads you'd probably need to convert it to a dynamic array first:
>
> === code begin ===
>
> a += ['foo'];
>
> === code end ===

What is that doing being the scenes? If it’s creating a whole new array and appending it then it’s probably pretty inefficient and hopefully can be optimized away.

Since dynamic array helpers work could you expose a function that adds an element to the array (an grows it if needed) so we could make helpers for it? Pushing a value to an array is perhaps the most common function used for lists so it makes sense to get that right imo.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Michael Van Canneyt


On Fri, 25 May 2018, Ryan Joseph wrote:

>
>
>> On May 25, 2018, at 1:37 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>>
>> This is currently not supported. And to avoid backwards compatibility problems with existing operator overloads you'd probably need to convert it to a dynamic array first:
>>
>> === code begin ===
>>
>> a += ['foo'];
>>
>> === code end ===
>
> What is that doing being the scenes? If it’s creating a whole new array and appending it then it’s probably pretty inefficient and hopefully can be optimized away.
>
> Since dynamic array helpers work could you expose a function that adds an
> element to the array (an grows it if needed) so we could make helpers for
> it?  Pushing a value to an array is perhaps the most common function used
> for lists so it makes sense to get that right imo.
I think the above is "right", and completely equivalent to sets, which are in some ways
like an array: a "collection" of same typed values.

To add an element to a set you also do
   MySet:=MySet+[aValue];

That said, sets do have
   Include(MySet,AValue);
to include a single value.

Maybe this syntax can be extended to dynamic arrays.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph


> On May 25, 2018, at 12:43 PM, Michael Van Canneyt <[hidden email]> wrote:
>
> I think the above is "right", and completely equivalent to sets, which are in some ways
> like an array: a "collection" of same typed values.
>
> To add an element to a set you also do
>  MySet:=MySet+[aValue];
>
> That said, sets do have
>  Include(MySet,AValue);
> to include a single value.
>
> Maybe this syntax can be extended to dynamic arrays.

We can do + operator overloads on array classes though so it’s not totally crazy to see this syntax in code. Ultimately if it’s optimized well doing [xx] is no big problem I suppose.

Having said that my feeling with dynamic arrays is that they’re more difficult to use than collection classes and lack basic functionality (until perhaps just now) so why use them? I just got burned really bad by some call to FPC_INTERLOCKEDINCREMENT64 from dynamic arrays which killed performance (who knows why) so I had to pull them out of all my code just in case.

The procedural syntax of Insert(arr, 0, value) is less enticing than arr.Insert(0, value) also but again we can fix that with type helpers.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Ryan Joseph <[hidden email]> schrieb am Fr., 25. Mai 2018, 04:35:


> On May 25, 2018, at 1:37 AM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> This is currently not supported. And to avoid backwards compatibility problems with existing operator overloads you'd probably need to convert it to a dynamic array first:
>
> === code begin ===
>
> a += ['foo'];
>
> === code end ===

What is that doing being the scenes? If it’s creating a whole new array and appending it then it’s probably pretty inefficient and hopefully can be optimized away.

Yes, that is what it does. Though a possible optimization would be that the compiler detects "dynarr := dynarr + [elem]" and converts it to "Insert(elem, dynarr, High(dynarr))". 


Since dynamic array helpers work could you expose a function that adds an element to the array (an grows it if needed) so we could make helpers for it? Pushing a value to an array is perhaps the most common function used for lists so it makes sense to get that right imo.

That function already exists and is called Insert() (see above). 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Michael Van Canneyt
In reply to this post by Ryan Joseph


On Fri, 25 May 2018, Ryan Joseph wrote:

>
>
>> On May 25, 2018, at 12:43 PM, Michael Van Canneyt <[hidden email]> wrote:
>>
>> I think the above is "right", and completely equivalent to sets, which are in some ways
>> like an array: a "collection" of same typed values.
>>
>> To add an element to a set you also do
>>  MySet:=MySet+[aValue];
>>
>> That said, sets do have
>>  Include(MySet,AValue);
>> to include a single value.
>>
>> Maybe this syntax can be extended to dynamic arrays.
>
> We can do + operator overloads on array classes though so it’s not totally crazy to see this syntax in code. Ultimately if it’s optimized well doing [xx] is no big problem I suppose.
>
> Having said that my feeling with dynamic arrays is that they’re more
> difficult to use than collection classes and lack basic functionality
> (until perhaps just now) so why use them?  I just got burned really bad by
> some call to FPC_INTERLOCKEDINCREMENT64 from dynamic arrays which killed
> performance (who knows why) so I had to pull them out of all my code just
> in case.
Dynamic arrays are reference counted. The interlocked increment is there to
make the operations thread safe. I do not know whether the classes you speak
of are thread safe. If there is no FPC_INTERLOCKEDINCREMENT64, most likely
they are not.

Dynamic arrays have their reason for existence. For one thing, they are a continuous block
in memory, properly aligned and whatnot. The collection classes make no such
guarantees.

>
> The procedural syntax of Insert(arr, 0, value) is less enticing than arr.Insert(0, value) also but again we can fix that with type helpers.

Arrays are not objects. They do not have methods.

I understand where the tendency to make everything an object comes from
but the basic pascal types (including dynamic arrays) have always been handled
procedurally. Nothing wrong with that. I often write small programs
procedurally.

And that is why type helpers exist, to tack on an object-like approach.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Ryan Joseph <[hidden email]> schrieb am Fr., 25. Mai 2018, 07:55:
The procedural syntax of Insert(arr, 0, value) is less enticing than arr.Insert(0, value) also but again we can fix that with type helpers.

You are overestimating what type helpers are capable of doing for dynamic arrays - see my remark about named types and matching types in my first reply to you. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph
In reply to this post by Michael Van Canneyt


> On May 25, 2018, at 1:06 PM, Michael Van Canneyt <[hidden email]> wrote:
>
> Dynamic arrays are reference counted. The interlocked increment is there to
> make the operations thread safe. I do not know whether the classes you speak
> of are thread safe. If there is no FPC_INTERLOCKEDINCREMENT64, most likely
> they are not.
>
> Dynamic arrays have their reason for existence. For one thing, they are a continuous block
> in memory, properly aligned and whatnot. The collection classes make no such
> guarantees.

I made my own class because I wanted to guarantee nothing silly was going on behind the scenes. I didn’t need thread safe so opting out of all the extra work done to make them safe is important sometimes. That would be nice if you could do the same with dynamic arrays honestly.

>
>>
>> The procedural syntax of Insert(arr, 0, value) is less enticing than arr.Insert(0, value) also but again we can fix that with type helpers.
>
> Arrays are not objects. They do not have methods.
>
> I understand where the tendency to make everything an object comes from
> but the basic pascal types (including dynamic arrays) have always been handled
> procedurally. Nothing wrong with that. I often write small programs
> procedurally.
>
> And that is why type helpers exist, to tack on an object-like approach.

Agreed but sometimes we like to just type arr.insert() because it’s faster or more consistent with other code. I suspect FPC users are already making their own type helper wrappers for this.

One of the worst things I’ve encountered recently is C# forcing EVERYTHING to be a class. Total nightmare.


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On May 25, 2018, at 1:02 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Yes, that is what it does. Though a possible optimization would be that the compiler detects "dynarr := dynarr + [elem]" and converts it to "Insert(elem, dynarr, High(dynarr))”.

100%

>
>
> Since dynamic array helpers work could you expose a function that adds an element to the array (an grows it if needed) so we could make helpers for it? Pushing a value to an array is perhaps the most common function used for lists so it makes sense to get that right imo.
>
> That function already exists and is called Insert() (see above).
>

Oh Insert on the last element works like Push. There really should be a Push/append etc.. function in there. I know it’s redundant but doing

Insert(arr, High(arr), value) is more work than Push(arr, value) and it’s not clear if we can add this ourselves easily without making tons of overloads.


Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Michael Van Canneyt
In reply to this post by Free Pascal - General mailing list


On Fri, 25 May 2018, Sven Barth via fpc-pascal wrote:

> Yes, that is what it does. Though a possible optimization would be that the
> compiler detects "dynarr := dynarr + [elem]" and converts it to
> "Insert(elem, dynarr, High(dynarr))".
>
>
>> Since dynamic array helpers work could you expose a function that adds an
>> element to the array (an grows it if needed) so we could make helpers for
>> it? Pushing a value to an array is perhaps the most common function used
>> for lists so it makes sense to get that right imo.
>>
>
> That function already exists and is called Insert() (see above).

Nice. I didn't know Insert() could be used to append to the end of a string.

One learns every day ! One for the documentation :-)

To be clear: for strings you can do

var
   S : String;

begin
   S:='123';
   Insert('456',S,Length(S)+2);
   Writeln(S);
end.

and it will append. Is the same true for dynamic arrays ?
i.e. any insert position >= length will do an append ?

Michael.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Michael Van Canneyt
In reply to this post by Ryan Joseph


On Fri, 25 May 2018, Ryan Joseph wrote:

>
>
>> On May 25, 2018, at 1:06 PM, Michael Van Canneyt <[hidden email]> wrote:
>>
>> Dynamic arrays are reference counted. The interlocked increment is there to
>> make the operations thread safe. I do not know whether the classes you speak
>> of are thread safe. If there is no FPC_INTERLOCKEDINCREMENT64, most likely
>> they are not.
>>
>> Dynamic arrays have their reason for existence. For one thing, they are a continuous block
>> in memory, properly aligned and whatnot. The collection classes make no such
>> guarantees.
>
> I made my own class because I wanted to guarantee nothing silly was going on behind the scenes. I didn’t need thread safe so opting out of all the extra work done to make them safe is important sometimes. That would be nice if you could do the same with dynamic arrays honestly.
I'm guessing you are not using strings either then, for performance reasons ?
Because exactly the same happens there.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Bart-48
In reply to this post by Ryan Joseph
On Fri, May 25, 2018 at 8:42 AM, Ryan Joseph <[hidden email]> wrote:
> Oh Insert on the last element works like Push. There really should be a Push/append etc.. function in there. I know it’s redundant but doing
>
> Insert(arr, High(arr), value) is more work than Push(arr, value) and it’s not clear if we can add this ourselves easily without making tons of overloads.

Add() would sound more logical to me then.

Bart
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph
In reply to this post by Michael Van Canneyt


> On May 25, 2018, at 3:18 PM, Michael Van Canneyt <[hidden email]> wrote:
>
> I'm guessing you are not using strings either then, for performance reasons ? Because exactly the same happens there.

really? I had a collection class with a dynamic array for the storage and that’s when I got the high CPU usage in the thread safe stuff. I replaced the storage with a pointer to a block of memory which I managed myself and the problem went away. I just wanted to a dynamic array that was fast, minimal and could append elements.

I use lots of strings but I never had that problem. Are strings reference counted like dynamic arrays? I thought a string was just an array of 255 chars.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Michael Van Canneyt
Michael Van Canneyt <[hidden email]> schrieb am Fr., 25. Mai 2018, 10:15:


On Fri, 25 May 2018, Sven Barth via fpc-pascal wrote:

> Yes, that is what it does. Though a possible optimization would be that the
> compiler detects "dynarr := dynarr + [elem]" and converts it to
> "Insert(elem, dynarr, High(dynarr))".
>
>
>> Since dynamic array helpers work could you expose a function that adds an
>> element to the array (an grows it if needed) so we could make helpers for
>> it? Pushing a value to an array is perhaps the most common function used
>> for lists so it makes sense to get that right imo.
>>
>
> That function already exists and is called Insert() (see above).

Nice. I didn't know Insert() could be used to append to the end of a string.

One learns every day ! One for the documentation :-)

To be clear: for strings you can do

var
   S : String;

begin
   S:='123';
   Insert('456',S,Length(S)+2);
   Writeln(S);
end.

and it will append. Is the same true for dynamic arrays ?
i.e. any insert position >= length will do an append ?

Correct :) 

Similar for indices <= 0: they will always prepend (for strings <= 1 of course). 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Ryan Joseph <[hidden email]> schrieb am Fr., 25. Mai 2018, 10:24:


> On May 25, 2018, at 3:18 PM, Michael Van Canneyt <[hidden email]> wrote:
>
> I'm guessing you are not using strings either then, for performance reasons ? Because exactly the same happens there.

really? I had a collection class with a dynamic array for the storage and that’s when I got the high CPU usage in the thread safe stuff. I replaced the storage with a pointer to a block of memory which I managed myself and the problem went away. I just wanted to a dynamic array that was fast, minimal and could append elements.

I use lots of strings but I never had that problem. Are strings reference counted like dynamic arrays? I thought a string was just an array of 255 chars.

ShortString is limited to 255 chars. AnsiString and UnicodeString don't have that limitation and they are reference counted just like dynamic arrays.

The type of "String" depends on the current settings:
- $H-: String = ShortString (this is the default for all modes except the Delphi ones) 
- $H+ and "$modeswitch unicodestrings-": String = AnsiString (or AnsiString(CP_ACP) to be precise) (this is the default for mode Delphi) 
- $H+ and "$modeswitch unicodestrings+": String = UnicodeString (this is the default for mode DelphiUnicode) 

If I had to guess you were probably doing something with the arrays they weren't designed for. :/

Regards, 
Sven 


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Ryan Joseph


> On May 25, 2018, at 3:57 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> If I had to guess you were probably doing something with the arrays they weren't designed for. :/
>

It’s a little foggy now but I think I had a dynamic array in a class which was being passed around some functions or the class (with the dynamic array) was in a record which was being passed around some functions. I think this was happening within tight loops also.

Bottom line is if the that thread lock function does anything expensive then passing around dynamic arrays within tight loops could be a deal breaker unless you could manually declare a dynamic array as not thread safe.

Regards,
        Ryan Joseph

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
Ryan Joseph <[hidden email]> schrieb am Fr., 25. Mai 2018, 12:45:


> On May 25, 2018, at 3:57 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> If I had to guess you were probably doing something with the arrays they weren't designed for. :/
>

It’s a little foggy now but I think I had a dynamic array in a class which was being passed around some functions or the class (with the dynamic array) was in a record which was being passed around some functions. I think this was happening within tight loops also.

Bottom line is if the that thread lock function does anything expensive then passing around dynamic arrays within tight loops could be a deal breaker unless you could manually declare a dynamic array as not thread safe.

When passing around dynamic arrays in such situations var and constref parameters should be used and assignments inside those loops should be avoided. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Feature announcement: Dynamic array extensions

Free Pascal - General mailing list
In reply to this post by Ryan Joseph
Am 25.05.2018 um 08:42 schrieb Ryan Joseph:
>
>> On May 25, 2018, at 1:02 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>>
>> Yes, that is what it does. Though a possible optimization would be that the compiler detects "dynarr := dynarr + [elem]" and converts it to "Insert(elem, dynarr, High(dynarr))”.
> 100%

FPC now optimizes "dynarr := dynarr + [elem]" to "Insert(elem, dynarr,
high(sizeint))" and "dynarr := [elem] + dynarr" to "Insert(elem, dynarr,
0)".

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12345