btw, I was going to ask.
In the past REALstring was positioned as thing, which is able to keep and pass binary data (with \0).
It seems on that time MemoryBlock was not inside of REAL SDK.
in SDK 2015, I have notice steps to make REALstring more close to encoding.
Should we stop to think about REALstring as binary-data-container?
REALstring is still good for binary data if no encoding is set.
MemoryBlocks are better often.
Depends on what you do.
If you need to pass binary data to app to write to BinaryStream, Database or Socket, you better keep using strings.
no, it’s int and that makes it 32bit. Better would be RBInteger which is 32 or 64bit.
Is there a bug report for this?
I am guessing the reason why it is so much slower (even if you have the function pointer pre-loaded) that we are getting pointer to their actual plugin wrapper and not to the function.
I was bitten by this badly where I was loading my own plugin function and could not understand what on earth was not thread safe in my code. Reason turned out to be that REALLoadObjectMethod did not give me pointer to my own function but to the Xojo wrapper they create around Plugin code. And that wrapper does all the Yields and checks and things that make it not thread safe from point of view of Xojo’s awful thread model.
So from this I am guessing maybe same thing applies when we do dynamic load on Operator_Convert, making it so much slower with all those checks, and probably automatic yield (making it not thread safe) and so on.
Xojo really should have plugin wrapper functions automatically generated have all this turned off by pragmas. A plugin can decide after all on its own if it wants to Yield or not!