In order to allow concatenation of strings to be efficient in both time and space, it must be possible for the result to share much of the data structure with its arguments. This implies that fully manual storage management (e.g. based on explicit malloc/free) is impractical. (It can be argued that this is true even with conventional string representations. Manual storage management typically results in much needless string copying.) Though an explicitly reference counted implementation can be built, we will assume automatic garbage collection. [Կարդալ աւելին]

In order to allow concatenation of strings to be efficient in both time and space, it must be possible for the result to share much of the data structure with its arguments. This implies that fully manual storage management (e.g. based on explicit malloc/free) is impractical. (It can be argued that this is true even with conventional string representations. Manual storage management typically results in much needless string copying.) Though an explicitly reference counted implementation can be built, we will assume automatic garbage collection. [Կարդալ աւելին]

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. [Կարդալ աւելին]

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. [Կարդալ աւելին]

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. [Կարդալ աւելին]

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. [Կարդալ աւելին]

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++. [Կարդալ աւելին]