> On May 25, 2018, at 1:06 PM, Michael Van Canneyt <mich...@freepascal.org>
> 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 - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
