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
Tha
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 inhe
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,
preallocat
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
> poi
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 suggest
> 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 imp
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 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 typ
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 enoug
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 langua
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,
t
11 matches
Mail list logo