That is not the original string
Right. String is an opaque type, you’re never ever gonna be modifying that (safely), even using “unsafe” code. You don’t know how its internal storage looks.
Ok, clear. - some characters as I have to type at least 20 to answer 
And the SubPtr and FunctionPtr?
Should be covered by https://docs.elementscompiler.com/API/Aspects/FunctionPointer/ and https://docs.elementscompiler.com/API/Aspects/BlockPointer/; the latter is the default for a delegate, the former makes it a non-block function pointer (the distinction between function and sub really is moot, here). Note that the is only applicable to the native platforms (Cocoa, Island).
See also the Blocks section on https://docs.elementscompiler.com/Platforms/CrossPlatform/Differences/ for some further reading, as well as https://docs.elementscompiler.com/Concepts/Blocks/.
1 Like
I did not understand why this syntax:
"Dim p as Ptr (of Char) with parentheses.
This syntax would not be better, without the use of parentheses:
Dim p as Ptr of Char.
Or
Dim p as Ptr Char
Or
Dim p as Char Ptr
Or
Dim p as Char Pointer
or
Dim p as Pointer Char
On ‘PowerBasic’, there are pointers, generally, in this form:
Dim p as Integer PTR
or
Dim p as Integer Pointer
On ‘powerbasic’ to dereference a pointer the “@” operator is used.
Page: 151 on
On ‘freebasic’ a pointer is used using C-style operators: “*”, “->”.
the idea is to match existing established VB syntax paradigms, such as List(Of String)
Ok, I understood, in relation to function declarations, what the syntax would look like, something similar to this:
Sub myFunction (p as Ptr (of Integer))
Correct. Again, symmetrical to, say,
Sub myFunction(l As List(Of Integer))
Correct.
To give you the complete story:
We started out with a syntax of IntegerPtr, StringPtr, etc.
But this would interfere with the old VB6 (undocumented) “pointers” that work completely different than the currently implemented full functional pointers.
It also gave a problem with pointers to user defined classes as the types should be created on the fly; when you create a class named MyClass, this would need to auto create a MyClassPtr.
And what if you have 2 classes with the same name in two different namespaces? These would generate the same pointer name, creating a conflict.
So, to create a pointer system where we can use a VB like syntax, there was no other choice than to fall back to a Generics-like sytax, that supports all build-in, referenced and user-defined types.
Well, they too would have be me in different namespaces then ;).
But the point(er) remains, we’re not doing it that way, yeah…
I don’t even see it as a “tough, no other choice compromise”, iMHO it’s sensible and fits in well with the langauge, as in essence it’s is (or behaves like) a generic type, in many ways. E.g. how Ptr(Of T).Dereference is of type T.
1 Like