> On Sep 17, 2020, at 7:23 PM, Ryan Joseph wrote:
>
> Certainly. I think it depends on what the solution is. It's a known short
> coming of the [] property and if the solution is as easy as allowing a var
> param variant then maybe it's feasible.
I'm remembering now I believe we did discuss
> On Sep 17, 2020, at 11:33 AM, J. Gareth Moreton via fpc-devel
> wrote:
>
> I think the difficulty with getting things like this approved is that it
> crosses into the realm of defining the language itself. I can't say I speak
> on behalf of Florian or Jonas, but I sense they want to avoid
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
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
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
> 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
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 imp
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
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
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
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
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 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 feature
> On Sep 15, 2020, at 10:34 PM, J. Gareth Moreton via fpc-devel
> wrote:
>
> I'm willing to settle with SetLength(array, len, ... len, NoInit: Boolean =
> False), but of course it depends on the overall support for it, which isn't
> looking too promising currently!
>
>
I'd rather put the
You all make good points. It's why I didn't suggest changing SetLength
because of the well-defined and safe behaviour, and yes, the System unit
is already crowded with intrinsics, and will become even more crowded
once the naming format of the assembly intrinsics are finalised. The
optional p
J. Gareth Moreton via fpc-devel schrieb am
Mo., 14. Sep. 2020, 19:00:
> With all this in mind, would there be support for an intrinsic such as
> "SetLengthNoInit" or "SetLengthNoClear" or some similar name that has
> all the benefits of SetLength (especially the reference counting) but
> doesn't
On Mon, 14 Sep 2020, J. Gareth Moreton via fpc-devel wrote:
On 14/09/2020 19:41, Michael Van Canneyt via fpc-devel wrote:
Better add an additional (optional) parameter SkipInit : Boolean = False;
Michael.
That won't work because constructs such as "var Data: array of array of
Byte; SetLen
On 14/09/2020 19:41, Michael Van Canneyt via fpc-devel wrote:
Better add an additional (optional) parameter SkipInit : Boolean =
False;
Michael.
I was probably a bit too critical in my last e-mail. I'm sure it's
possible given SetLength is an intrinsic rather than a real subroutine.
Is it
On 14/09/2020 19:41, Michael Van Canneyt via fpc-devel wrote:
Better add an additional (optional) parameter SkipInit : Boolean = False;
Michael.
That won't work because constructs such as "var Data: array of array of
Byte; SetLength(Data, 25, 25);" are allowed. Eevn if it's technically
an i
On Mon, 14 Sep 2020, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
This is something that came up in a discussion with a client. One thing
he noticed when using SetLength with dynamic arrays is that it can cause
a CPU bottleneck because it initialises the entire block to zero, which
Hi everyone,
This is something that came up in a discussion with a client. One thing
he noticed when using SetLength with dynamic arrays is that it can cause
a CPU bottleneck because it initialises the entire block to zero, which
is often undesirable if the array is going to be overwritten wit
23 matches
Mail list logo
