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

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

Inappropriate deallocation of dynamic storage is a well-known source of catastrophic program failures. In the context of nonextensible applications, such as statically linked programs, this problem can (in theory) be mastered by a careful programmer; for extensible programs, it cannot! There is always the possibility that a module may be added to a program later on; such an extension can introduce additional references to objects of which the implementor of the core modules is unaware. Therefore, Oberon neither requires nor allows explicit deallocation of dynamic storage.

source

#oberon #gc #programming #programming_languages

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

Inappropriate deallocation of dynamic storage is a well-known source of catastrophic program failures. In the context of nonextensible applications, such as statically linked programs, this problem can (in theory) be mastered by a careful programmer; for extensible programs, it cannot! There is always the possibility that a module may be added to a program later on; such an extension can introduce additional references to objects of which the implementor of the core modules is unaware. Therefore, Oberon neither requires nor allows explicit deallocation of dynamic storage.

source

#oberon #gc #programming #programming_languages

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

The language, however, makes veryfew assumptions about the environment. If not available from a given operating system, dynamic module loading, command invocation, and automaticgarbage collection can be introduced by a small run-time system. In principle, it is possible to forego dynamic loading and to create traditional, staticallylinked applications, but this is anachronistic for the challenges of today’s software systems. Automatic garbage collection is indispensable for reliable,extensible software systems and is probably the biggest culture clash between Oberon and other compiled languages such as Pascal, C, or C++.

source

#oberon #gc #programming #programming_languages

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

The language, however, makes veryfew assumptions about the environment. If not available from a given operating system, dynamic module loading, command invocation, and automaticgarbage collection can be introduced by a small run-time system. In principle, it is possible to forego dynamic loading and to create traditional, staticallylinked applications, but this is anachronistic for the challenges of today’s software systems. Automatic garbage collection is indispensable for reliable,extensible software systems and is probably the biggest culture clash between Oberon and other compiled languages such as Pascal, C, or C++.

source

#oberon #gc #programming #programming_languages

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

Programming makes me think that people value the things they do because they were hard, not because they were useful. Once I master the hard thing, I’m proud of myself and find it easy to forget that perhaps that damn thing should not have been so hard in the first place. Probably true for a lot of human activities. Stuff should simply be easier, that is all.

source

because author’s toots expire, i want to put it here. #programming

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