On 10/18/24 11:41 AM, Karoly Balogh via fpc-pascal wrote:
Hi,
On Thu, 17 Oct 2024, Michael Van Canneyt via fpc-pascal wrote:
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.
Maybe it was mentioned in the thread, I just glanced through it, but how
about ARC (Automatic Reference Counting), Objective C style? To be honest,
I really liked that, and we already have it kind of in place for strings,
even temporary strings and maybe even temporary arrays created inside a
function. We'd just need to extend it for a bunch of other things, I
suppose. Manual FreeAndNil() is the ugliest part of Object Pascal for me
for sure... OTOH, for Object Pascal you might end up with RAII in this
case, instead of ARC, because how how the language works. I did not like
it that much in C++, but maybe because modern C++ syntax is properly
horrid...
But anyway, that concept replaces GC for a majority of use cases, and I
really liked it for the couple of years I've been doing iOS stuff. But of
course Apple adopted it for all the underlying classes too, which points
back to the fact, that modern languages are usually a thin wrappers around
some library concept, and if your library API is as full of legacy and as
inherently messy as ours, there's little you can do.
Reference counting already exists, if all your objects are accessed
through interfaces. Then you just inherit from TInterfacedObject and
you're good. I used this approach in PTCPas and it works well. I wonder
why it's not used more often.
There are also advanced records, which support implementing reference
counted smart pointers, RAII-style objects, etc. It's just that there
are not ready made implementations in the standard library. However, the
language already supports them. I used advanced records for the Unicode
support for the video unit, to implement TEnhancedVideoCell in a way
that conserves memory, by overlaying a WideChar and a WideString. Since
most graphemes are represented by a single Unicode code point, that
falls in the BMP, it fits in a single WideChar, so there's no need to
allocate extra memory on the heap for a WideString. However, to support
all languages, we need to support graphemes, represented by a sequence
of code points (e.g. non-BMP characters, combining characters), so for
them, a WideString is allocated on the heap. See the implementation in
videoh.inc and video.inc, if you're curious. This means we have all the
power of C++ objects, without the ugly parts (no multiple inheritance of
classes and the "diamond" problem).
Btw, I usually don't mind calling FreeAndNil() myself, most of the time,
objects have a clear ownership, so an object creates the objects it owns
in the constructor, and destroys them in the destructor. For the more
complicated cases, there are the options, mentioned above. I've used
them very few times, but when I needed them, they were there.
For once, I'd be really glad if a bunch of the containers would be
Thread-Safe by default, like TList and things, and they aren't, because
they're based on almost 3 decade old Delphi concepts, when multithreading
wasn't as big of a deal as these days. No amount of "lets add GC" would
fix this. (And I know we have thread-safe alternatives, but they aren't
used everywhere and consistently. So when using a bunch of libraries, you
still end up managing thread-safety by hand...)
More modern container libraries, using generics, RAII, or whatever else
are always a good idea, but AFAIK there are already some decent TList
alternatives in the RTL and packages (fgl, rtl-generics)? It's just a
matter of learning about them and getting used to using them.
I think we should start using more modern (generics-based) containers
inside the compiler sources itself, but that's another story, that only
concerns compiler developers, not users. :)
Nikolay
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
