|
658 | 658 |
|
659 | 659 | 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. |
660 | 660 |
|
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. |
662 | 662 |
|
663 | 663 | To make this work with global variables, one can use global (unit-level) properties, see <<Properties>>. |
664 | 664 |
|
@@ -2140,7 +2140,7 @@ But records are still very useful when you need speed or a predictable memory la |
2140 | 2140 | * 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: |
2141 | 2141 | ** to communicate with libraries written in other programming languages, when they expose an API based on records, |
2142 | 2142 | ** 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). |
2144 | 2144 | * 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_:) |
2145 | 2145 |
|
2146 | 2146 | ### Variant records and related concepts |
@@ -2538,7 +2538,7 @@ include::code-samples/static_class_method.dpr[] |
2538 | 2538 |
|
2539 | 2539 | A _class property_ is a property that can be accessed through a class reference (it does not need a class instance). |
2540 | 2540 |
|
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_. |
2542 | 2542 |
|
2543 | 2543 | 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 |
2544 | 2544 | //(in FPC) ?? |
@@ -2622,9 +2622,9 @@ does not execute to the end in this case, `X` cannot be assigned, so who will cl |
2622 | 2622 |
|
2623 | 2623 | 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`. |
2624 | 2624 |
|
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"_. |
2626 | 2626 |
|
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: |
2628 | 2628 |
|
2629 | 2629 | [source,pascal] |
2630 | 2630 | ---- |
|
0 commit comments