Skip to content

Commit ccc4140

Browse files
committed
Clean up punctuation and wording
1 parent 571d535 commit ccc4140

File tree

1 file changed

+4
-4
lines changed

1 file changed

+4
-4
lines changed

assets/content/cookbook/Other/hxcpp-pointers.md

Lines changed: 4 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ extern class Foo {
3838
}
3939
```
4040

41-
The downside with these is that its not ergonomic from a haxe pov to represent and consume pointers to objects.
41+
The downside with these is that its not ergonomic in haxe code to represent and consume pointers to objects.
4242

4343
```haxe
4444
extern class Foo {
@@ -71,7 +71,7 @@ void foo(::cpp::Pointer<int> p) {}
7171
7272
This type lives on the stack so does not contribute to GC pressure, it also is compatible with Dynamic, so you can pass `cpp.Pointer` types into dynamic places and use them with generic arguments. This type also contains loads of convenience functions for reinterpreting the pointer, arithmetic, conversions to haxe arrays and vectors, etc, etc. There are also member fields for accessing the `cpp.Pointer` as a `cpp.RawPointer` or `cpp.Star`.
7373
74-
It also retains the array access that `cpp.RawPointer` does. On top of this the `::cpp::Pointer` type has implicit to and from conversions for the underlying pointer, which means you can extern the following function
74+
It also retains the array access that `cpp.RawPointer` supports. On top of this the `::cpp::Pointer` type has implicit to and from conversions for the underlying pointer, which means you can extern the following function
7575
7676
```cpp
7777
void foo(int* v) {}
@@ -83,7 +83,7 @@ with this haxe function
8383
function foo(v:cpp.Pointer<Int>) {}
8484
```
8585

86-
You don't need to use `cpp.RawPointer` here, you can use `cpp.Pointer` and all the convenience it provides. So why would you ever want to use `cpp.RawPointer` if `cpp.Pointer` does everything it does and is compatible with more of haxe's type system.
86+
You don't need to use `cpp.RawPointer` here, you can use `cpp.Pointer` and all the convenience it provides. So why would you ever want to use `cpp.RawPointer` if `cpp.Pointer` does everything it does and is compatible with more of haxe's type system?
8787

8888
Function signatures.
8989

@@ -109,7 +109,7 @@ That `fromStaticFunction` call will generate a function pointer with the signatu
109109

110110
## cpp.Star
111111

112-
This is the last pointer type and like `cpp.RawPointer` it generates raw C pointers in the output code, the key difference is that this type does not support array access and will auto de-reference when accessing the underlying data. This means it's ideal for representing pointers to objects. E.g. the following C++
112+
This is the last pointer type and like `cpp.RawPointer` it generates raw C pointers in the output code. The key difference is that this type does not support array access and will auto de-reference when accessing the underlying data. This means it's ideal for representing pointers to objects. E.g. the following C++
113113

114114
```c++
115115
struct Bar {

0 commit comments

Comments
 (0)