Hi,
i made two patches to fix my Android app crashing:
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/235
https://gitlab.com/freepascal.org/fpc/source/-/issues/39985
I do not believe it is possible to build a stable Android 64-bit library
with current fixes
Cheers,
Benito
O
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
Hi,
what about overloading operators for OBJECTs?
They do not conflict with any default operators.
I expected this to work, but it did not compile:
type generic TXQHashset = object //(specialize
TXQBaseHashmap)...
class operator =(const a, b: TXQHashset): boolean;
end;
Cheers,
Be
Hi,
Don't forget that the record/management operator approach will again
blow up binary size; for every variable declared like this you risk
creating a new type.
the classic Delphi way was to use an interface for freeing. It only
requires one type and nothing blows up.
type
TDefer = c
Hi,
that is a great idea
It especially useful for generics, where each specialization can create
a huge amount of identical methods
Best,
Benito
On 13.10.21 19:33, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
So one optimisation that has cropped up a couple of times is finding
ways
Hi,
in my big decimal unit, I need to divide by 10 all the time,
e.g.
https://github.com/benibela/bigdecimalmath/blob/master/bigdecimalmath.pas#L1324-L1325
would the magic div help there much?
Bye,
Benito
On 09.11.21 22:12, J. Gareth Moreton via fpc-devel wrote:
This one for Marģer
Hi,
it could always inline it.
For small sizes do that mov and for large sizes do rep stosb on x86. It
is very fast nowadays. Faster than FillChar on my Intel laptop. (except
for mid sizes like 128 bytes)
Bye,
Benito
On 16.04.22 01:26, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
T
Hi,
FillChar is on most platforms an assembly function and FPC *never*
inlines assembly functions.
even without inlining, rep stosb is faster than FillChar:
{$asmmode intel}
procedure repfillchar(var buffer; len: sizeuint; c: byte);
begin
asm
mov al, c
mov rdi, buffer
mov rcx,
Hi,
and the FPC implementation is actually documented to not be stable in
the code:
{
QuickSort
Average performance: O(n log n)
Worst performance: O(n*n)
Extra memory use: O(log n) on the stack
Stable: no
Additional notes: Uses the middle element asthe pivot. This makes it work
well also on a
Hallo,
i made a patch for faster management operators:
https://gitlab.com/benibela/fpc-source/-/commit/1aa0866112c97dd0c7ed7f3a4b1c7ab6420cb942
And it has been working fine on fixes3_2, but when I tried to apply it
on main, I get an error message:
views.inc(4318,17) Error: Wrong number o
ion I had about them is why they can't be inlined. Does anyone
have the answer for that? Not being able to be inlined is the biggest
performance problem I suspect, followed by the copy operator which gets called
redundantly on assignment to temporary memory.
On Jul 22, 2023, at 7:07 AM, Benit
se because "copy" was not public in the record. I can set a
flag [cnf_ignore_visibility] in the compiler
Bye,
Benito
On 23.07.23 16:35, Hairy Pixels via fpc-devel wrote:
On Jul 23, 2023, at 7:13 AM, Benito van der Zander via
fpc-devel wrote:
with my patch, "copy"
12 matches
Mail list logo