[fpc-pascal] Fwd: What to do to get new users
Sven Barth
pascaldragon at googlemail.com
Sat Oct 19 15:10:02 CEST 2024
Hairy Pixels via fpc-pascal <fpc-pascal at lists.freepascal.org> schrieb am
Sa., 19. Okt. 2024, 14:49:
> On Oct 19, 2024 at 7:37:15 PM, Martin Frb via fpc-pascal <
> fpc-pascal at lists.freepascal.org> wrote:
>
>> Because if the latter, well I know some people who would shot the person
>> introducing that in a high performance software...
>>
>
> yes it’s bad except for UI apps which is what FPC and new users seem to be
> focusing on. FPC has it already on some types which are widely used.
>
For UI apps it can also be bad depending on the performance impact.
>
>> Actually, if we are talking safety (rather than comfort for the
>> developer) then we may not need ARC at all. Because freeing memory is
>> not the only (nor biggest?) worry. Running out of mem (and handling it
>> gracefully, and without vulnerability) is important too. But ARC
>> doesn't solve that.
>> One way to solve that is pre-allocate any mem that may be needed, and
>> then never free or alloc any mem thereafter. And then you need no ARC at
>> all.
>>
>
> FPC sadly has no concept of custom allocators for classes, just something
> you can add to the type itself but that’s very limited. I really like how
> Jai and Odin have added allocators in as a core part of the language and
> library. Zig does something like this too but it’s much more clumsy and
> tedious.
>
For a class one can override NewInstance and FreeInstance. And with
TVirtualMethodInterceptor (I think not yet implemented in FPC) it might
even be possible to replace these on an existing class type without
inheriting from it. I have not tested that yet, but it *might* work.
Regards,
Sven
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20241019/ac5df273/attachment.htm>
More information about the fpc-pascal
mailing list