Michael Van Canneyt <mich...@freepascal.org> schrieb am Do., 17. Okt. 2024, 14:37:
> > > On Thu, 17 Oct 2024, Sven Barth via fpc-pascal wrote: > > > Michael Van Canneyt via fpc-pascal <fpc-pascal@lists.freepascal.org> > > schrieb am Do., 17. Okt. 2024, 11:40: > > > >> > >> > >> On Wed, 16 Oct 2024, Hairy Pixels via fpc-pascal wrote: > >> > >>> On Oct 17, 2024 at 12:03:47 AM, Guillermo Martínez Jiménez via > >> fpc-pascal < > >>> fpc-pascal@lists.freepascal.org> wrote: > >>> > >>>> Prease DON'T add garbage collector. IMO it isn't a good idea. I had > >>>> very bad experiences with it. Unless somebody found a new magic > >>>> algorithm in the last decade... > >>>> > >>> > >>> I used C# for Unity quite a bit and never had any problems. That’s even > >>> with the worst case scenario for game developing that needs real time > >>> graphics. Does that power all of .NET too and all those desktop > >>> applications? It’s been battle tested many years as far as I can tell. > >>> > >>> In 2024 you don’t need the performance of manual memory management in > UI > >>> apps. Garbage collector or anything else will work perfectly well. > >> > >> I don't write UI apps, only server apps. > >> Performance matters there, so a GC is not good. > >> We see this at times in our servers, when the GC kicks in; everything > just > >> stops. > >> > >> In each case, it is a bad idea to slap this on an existing language: > >> > >> a GC collected language is a complete paradigm shift from non-GC. > >> C# and Java (and probably others) were designed with GC in mind. > >> That it works there is therefore not surprising. > >> > >> By contrast, Pascal is not designed with GC in mind. > >> You'd need to redesign the language. > >> > >> If you do that, you can throw away all existing code if you introduce > GC, > >> because the two concepts do not merge easily. > >> > >> Embarcadero tried it in Delphi, and they failed. Not surprisingly, > >> they removed again all automatic memory management. > >> > > > > Probably something like the std::*_ptr (shared, unique, auto, etc.) from > > C++ could be implemented in FPC. Main point missing for a convenient > > solution would be a mechanism so that e.g. classes could be accessed as > is > > from such types (for example default fields) > > A proof of concept implementation should be doable without that however. > > I have one provided by a colleague that is a C++ jedi... I planned to put > it > in types.pp, since the implementation is ridiculously small and depends on > nothing. > Does it have tests as well? Otherwise that sounds good 😁 Regards, Sven >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
