Then, I would suggest it gets bolted into strutils, or sysutils. There are
many good reasons to optimize Setlength(), especially for script authors :-)
Currently, I am working (learning) Alpha Controls (alphaskins), and trying
to find a fit into FCL/LCL, or Graeme's GUI. And if I tweak too much,
Ah yes, that works, thanks.
I feel a bit silly because I haven't explored these useful features as
much as I should, possibly because assembly language isn't object oriented!
I think the difficulty with getting things like this approved is that it
crosses into the realm of defining the
Here's an example of the main problem that keeps us from using custom types to
replace dynamic arrays. We basically a need [] property modifier that treats
records the same way the dynamic array syntax does. GetValue could be a
procedure and use a var parameter and maybe even that would be
> On Sep 17, 2020, at 9:59 AM, J. Gareth Moreton via fpc-devel
> wrote:
>
> type generic TMyArray = record
> Data: ^T;
> Length: PtrUInt;
> end;
>
> The compiler will complain about T being an unresolved forward declaration.
> Outside of specifying a second parameter for the pointer
I hope they do allow you to fix it, because those features look useful,
especially with custom-made dynamic arrays (through a generic record).
I've got to try playing with them now to see if I can make something
that Chris Rorden would use!
Though not really related, it's not easy to specify
> On Sep 16, 2020, at 9:10 PM, J. Gareth Moreton via fpc-devel
> wrote:
>
> I figure I could design a dynamic array class, but it will very likely be
> incompatible with SetLength no matter what I try to do, and unless I'm
> mistaken, it won't have the benefit of automatically gaining an
Benito van der Zander via fpc-devel
schrieb am Mi., 16. Sep. 2020, 15:30:
>
> Hi,
>
>
> I'm against adding support for this. Dynamic arrays have guaranteed
> behavior. If users find that this behavior is not appropriate for their use
> case then they should not use them (or as you already
J. Gareth Moreton via fpc-devel schrieb am
Mi., 16. Sep. 2020, 16:10:
> I did wonder if it was possible to use an object of some kind or, I dare
> say, some evil low-level manipulation of its internal structure wrapped
> into a convenient function that, say, calls ReallocMem on the internal
>
On Wed, 16 Sep 2020, Benito van der Zander via fpc-devel wrote:
Hi,
I'm against adding support for this. Dynamic arrays have guaranteed
behavior. If users find that this behavior is not appropriate for their use
case then they should not use them (or as you already suggested,
I did wonder if it was possible to use an object of some kind or, I dare
say, some evil low-level manipulation of its internal structure wrapped
into a convenient function that, say, calls ReallocMem on the internal
pointer and sets the length field as normal. The trouble is, that will
be
Hi,
I'm against adding support for this. Dynamic arrays have guaranteed
behavior. If users find that this behavior is not appropriate for
their use case then they should not use them (or as you already
suggested, preallocate them).
well, setlength does not always initialize the array
I think dynamic arrays are really elegant features of Pascal and a strong
benefit versus C. However, when working with large projects one encounters
situations where one wants more. control. I would advocate allowing developers
to optionally use SetLengthNoInit and also allowing user to specify
The dynamic arrays in Lazarus have so many terrific properties. Giving power
users the ability to not initialize them would give clear performance benefits.
This is useful in real world sitautions where one has long term arrays, but
also can use transient arrays of the same type. Another
13 matches
Mail list logo
