Every time a new assignment or parameter passing is made, the reference count of the String has to be increased, this is an atomic lock, and is related to memory management, so it’s there whether you’re using simple reference-counting or copy-on-write.

Under a GC, no atomic lock is required, a simple reference (pointer) has to be copied. This is very efficient, locally, but the memory management costs are just deferred to a later garbage collection phase. Since immutable strings don’t have reference to other objects, the GC for them can theoretically happen in parallel without any drawbacks (assuming the GC supports it).

So under a GC, an immutable String type makes a whole lot of sense, as implementing a copy-on-write one requires a lot of effort, and a mutable one is problematic multi-threading wise.

https://www.delphitools.info/2013/05/13/immutable-strings-in-delphi/

#pascal #string #strings #immutable_string #delphi #gc #programming

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

Every time a new assignment or parameter passing is made, the reference count of the String has to be increased, this is an atomic lock, and is related to memory management, so it’s there whether you’re using simple reference-counting or copy-on-write.

Under a GC, no atomic lock is required, a simple reference (pointer) has to be copied. This is very efficient, locally, but the memory management costs are just deferred to a later garbage collection phase. Since immutable strings don’t have reference to other objects, the GC for them can theoretically happen in parallel without any drawbacks (assuming the GC supports it).

So under a GC, an immutable String type makes a whole lot of sense, as implementing a copy-on-write one requires a lot of effort, and a mutable one is problematic multi-threading wise.

https://www.delphitools.info/2013/05/13/immutable-strings-in-delphi/

#pascal #string #strings #immutable_string #delphi #gc #programming

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)

how microsoft banned third party language compilers.

We are very keen on supporting WinRT with native Delphi & C++ code. Right now, the issues surrounding the WinRT space center around the fact that many OS-supplied APIs which are required by anyone implementing their own language RTL are actually off-limits unless you’re the VC++ RTL DLL. You know, little things like RtlUnwind for exception processing and VirtualAlloc (et. al.) for memory management… Any calls to those APIs from your application will automatically disqualify your application from being an “official” WinRT application capable of delivering through the MS app store.

source

when I read something like this, or even “how to pay to apple, get keys, and become an officially approved developer”, I have a strong desire to never participate windows/macos/ios development and I feel the freedom I have on GNU+Linux/BSDs, etecetra.

#microsoft #compilers #delphi #embarcadero #winrt #api #programming

բնօրինակ սփիւռքում(եւ մեկնաբանութիւննե՞ր)