Comment Re:SafeStr is a totally broken API. (Score 1) 360
To say that SafeStr is a totally broken API is severely overstating the flaws you describe. No string implementation for C/C++ can be perfect, as I'm sure you well realize, having written one yourself. Any possible implementation is going to involve trade-offs. It's unavoidable.
You are correct in saying that any string that is modified with references may cause the other references to be left in an undefined state. Unfortunately, this is a problem with any sort of reference counting in C unless you abstract away the pointer and replace it with a handle (a la Win32) or something similar. If you're holding references to an object (whether it's a SafeStr string or something else entirely), do not modify the object. SafeStr does not prevent against doing this, but making the changes to cause SafeStr to throw an exception are minor, and we may very well do so in the next release.
You are also correct with your second point; however, this is a limitation that is clearly documented. The solution is simple: temporarily bump the reference count, perform your operations, and decrement the reference count. You can use XXL to facilitate this process by saving the string as an asset inside of an asset block.
Both of these problems are minor, obvious issues that aren't a big deal in practice. As I said, there are going to be trade-offs, no matter what, and we believe that SafeStr offers people a good set of them. SafeStr is *a* solution, but it is not intended to be *the* solution. Its trade-offs may not be acceptable to everyone, whereas those offered by bstring or other string implementations may be instead.
You are correct in saying that any string that is modified with references may cause the other references to be left in an undefined state. Unfortunately, this is a problem with any sort of reference counting in C unless you abstract away the pointer and replace it with a handle (a la Win32) or something similar. If you're holding references to an object (whether it's a SafeStr string or something else entirely), do not modify the object. SafeStr does not prevent against doing this, but making the changes to cause SafeStr to throw an exception are minor, and we may very well do so in the next release.
You are also correct with your second point; however, this is a limitation that is clearly documented. The solution is simple: temporarily bump the reference count, perform your operations, and decrement the reference count. You can use XXL to facilitate this process by saving the string as an asset inside of an asset block.
Both of these problems are minor, obvious issues that aren't a big deal in practice. As I said, there are going to be trade-offs, no matter what, and we believe that SafeStr offers people a good set of them. SafeStr is *a* solution, but it is not intended to be *the* solution. Its trade-offs may not be acceptable to everyone, whereas those offered by bstring or other string implementations may be instead.
