Skip to content

Commit 3a49511

Browse files
committed
A few fixes on top, to keep the intended meaning, but phrased better
1 parent b940d35 commit 3a49511

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

modern_pascal_introduction.adoc

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -658,7 +658,7 @@ end.
658658

659659
Note that this trick cannot be done as easily with global procedures, functions and variables. With procedures and functions, you could expose a constant pointer to a procedure in another unit (see <<Callbacks>>), but that looks quite dirty.
660660

661-
The usual solution is then to create a trivial "wrapper" function that underneath simply calls the functions from the internal unit, passing the parameters and return values around.
661+
The usual solution is to create trivial "wrapper" functions that simply call the functions from the internal unit, passing the parameters and return values as needed.
662662

663663
To make this work with global variables, one can use global (unit-level) properties, see <<Properties>>.
664664

@@ -2140,7 +2140,7 @@ But records are still very useful when you need speed or a predictable memory la
21402140
* The memory layout of records (size, padding between fields) is clearly defined in some situations: when you request the _C layout_, or when you use `packed record`. This is useful:
21412141
** to communicate with libraries written in other programming languages, when they expose an API based on records,
21422142
** to read and write binary files,
2143-
** to play dirty low-level tricks (like unsafe typecasting one type to another, being aware of their memory representation).
2143+
** to implement dirty low-level tricks (like unsafe typecasting one type to another, being aware of their memory representation).
21442144
* Records can also have `case` parts, which work like _unions_ in C-like languages. They allows to treat the same memory piece as a different type, depending on your needs. As such, this allows for greater memory efficiency in some cases. And it allows for more _dirty, low-level unsafe tricks_:)
21452145

21462146
### Variant records and related concepts
@@ -2538,7 +2538,7 @@ include::code-samples/static_class_method.dpr[]
25382538

25392539
A _class property_ is a property that can be accessed through a class reference (it does not need a class instance).
25402540

2541-
It is a quite straightforward analog of a regular property (see <<Properties>>). For a _class property_, you define a _getter_ and / or a _setter_. They may refer to a _class variable_ or a _static class method_.
2541+
It is similar to a regular property (see <<Properties>>), but all classes access (read and write) the same value. For a _class property_, you can define a _getter_ and / or a _setter_. They may refer to a _class variable_ or a _static class method_.
25422542

25432543
A _class variable_ is, you guessed it, like a regular field but you don't need a class instance to access it. In effect, it's just like a global variable, but with the namespace limited to the containing class. It can be declared within the `class var` section of the class. Alternatively
25442544
//(in FPC) ??
@@ -2622,9 +2622,9 @@ does not execute to the end in this case, `X` cannot be assigned, so who will cl
26222622

26232623
The solution of Object Pascal is that, if an exception occurs within a constructor, then the destructor is called. This is a reason why _your destructor must be robust_, which means it should work in any circumstances, even on a half-created class instance. Usually this is easy if you release everything safely, like by `FreeAndNil`.
26242624

2625-
_The memory of the class is guaranteed to be zeroed right before the constructor code is executed_, so we know that at the beginning, all class references are `nil`, all integers are `0` and so on.
2625+
A helpful property we can use to write robust destructors (that can handle half-created instances) is that _the memory of the class is guaranteed to be zeroed right before the constructor code is executed_. So we know that at the beginning, all class references are `nil`, all integers are `0` and so on. The strategy for writing a robust destructor is thus: _"be prepared that any field may still be zero, and handle it without errors"_.
26262626

2627-
So below works without any memory leaks:
2627+
In effect, code below works without any memory leaks, even though constructor execution is interrupted, leaving only `Gun1` but not `Gun2` created:
26282628

26292629
[source,pascal]
26302630
----

0 commit comments

Comments
 (0)