Beware of inadverant memory leaks from code like the following:
// Do not do this! It leaks memory!
someStr = REALConvertString( someStr, someEncoding );
Instead, your code should look like this:
// This is the correct way to convert encoding and write over the original string.
REALstring temp = REALConvertString( someStr, someEncoding );
REALUnlockString( someStr );
someStr = temp;
If used in a plugin this will cause a crash. The code should read:
Thats just not true, the code above it creates new string called temp (= new memory there), then it releases the old string, called (someStr) which may be correct if you own the string and were going to replace it with the new one (by Xojos rules of ownership of objects). If you dont “own” it then you cant release it obviously.
Your code at bottom makes no sense at all since your basically just creating new string and releasing it again before doing anything with it. someStr and temp at that point is exactly same reference so your just releasing your new converted string, making it pointless to convert it in the first place if your not doing anything with it.
In my fp Plugin the code on top caused a crash in an application using it. Using the bottom code the application worked perfectly. That “someStr” was a REALstring passed to my plugin in an interface function, so doesn’t Xojo own it?
I removed the line
REALUnlockString( temp );
from my plugin. The application using it still worked perfectly.
So it appears that if a plugin does
REALUnlockString( someStr );
and someStr has been passed to the plugin by Xojo, it will cause a crash. I suspect one usually only wants to change encoding on REALstrings passed to the plugin from Xojo. So usually one should use:
There is a contradiction between the docs and its example:
[quote]REALConvertString
Converts the given string from its current encoding, to the new one specified by the “encoding” parameter (akin to the ConvertEncoding REALbasic function). Calling this function will allocate and return an entirely new string, which you should free with a call to REALUnlockString. […][/quote]
So one should unlock the new string temp (and of course if there is a reference to it from earlier also someStr), but temp is not unlocked in the doc’s example for REALConvertString:
[quote]Beware of inadverant memory leaks from code like the following:
// This is the correct way to convert encoding and write over the original string.
REALstring temp = REALConvertString( someStr, someEncoding );
REALUnlockString( someStr );
someStr = temp;[/quote]
It crashes because you don’t own the string when you get it in as parameter in a method you need to lock it to own it.
And your code at bottom only does not crash by luck for you probably since your disposed memory has not been written over yet. But such luck of course does not mean it is safe or makes sense, it just means it will crash eventually.
The title of this conversation should have been “REALConvertString doc is misleading”. Perhaps this would be better:
REALstring temp = REALConvertString( someStr, someEncoding );
REALUnlockString( someStr ); // use this line only if your code owns someStr
someStr = temp;