It is unnecessary to hold RefString's clones in each RefString instance. Simply replace pString with a smart pointer to a reference-counted version of std::string. This way there are two reference counting mechanisms involved:

1. Each reference-counted std::string holds the number of RefString's that refer to it.

2. RefString's own reference count holds the number of AngelScript (or C++, if necessary) objects that refer to it, such as string handles.

So RefString's assignment can simply acquire the source RefString's smart pointer to the reference-counted std::string. By doing so it will release the reference-counted std::string it held previously (if any), decreasing its reference counter, which will result in its deletion if and only if no other RefString holds a reference to it.

That aside, unless you are handling reference of your string object inside ScriptUtils object, you may want to register your functions with signatures like

"void removeHtmlTags(string@+, const string& in)"

`+` indicating an autohandle.

About COW strings in general, they often prove to be more trouble than they are worth. If lots of raw assignments are expected, they might be a good thing. See http://stackoverflow.com/questions/707014/why-vc-strings-are-not-reference-counted for some reasons why many stl implementations just skip it (at least vc++ and stlport do; gcc libs apparently do not).

It is unnecessary to hold RefString's clones in each RefString instance. Simply replace pString with a smart pointer to a reference-counted version of std::string. This way there are two reference counting mechanisms involved:

1. Each reference-counted std::string holds the number of RefString's that refer to it.

2. RefString's own reference count holds the number of AngelScript (or C++, if necessary) objects that refer to it, such as string handles.

So RefString's assignment can simply acquire the source RefString's smart pointer to the reference-counted std::string. By doing so it will release the reference-counted std::string it held previously, decreasing its reference counter, which will result in its deletion if and only if no other RefString holds a reference to it.

That aside, unless you are handling reference of your string object inside ScriptUtils object, you may want to register your functions with signatures like

"void removeHtmlTags(string@+, const string& in)"

`+` indicating an autohandle.

About COW strings in general, they often prove to be more trouble than they are worth. If lots of raw assignments are expected, they might be a good thing. See http://stackoverflow.com/questions/707014/why-vc-strings-are-not-reference-counted for some reasons why many stl implementations just skip it (at least vc++ and stlport do; gcc libs apparently do not).

It is unnecessary to hold RefString's clones in each RefString instance. Simply replace pString with a smart pointer to a reference-counted version of std::string. This way there are two reference counting mechanisms involved:

1. Each reference-counted std::string holds the number of RefString's that refer to it.

2. RefString's own reference count holds the number of AngelScript (or C++, if necessary) objects that refer to it, such as string handles.

So RefString's assignment can simply acquire the source RefString's smart pointer to the reference-counted std::string. By doing so it will release the reference-counted std::string it held previously, decreasing its reference counter, which will result in its deletion if and only if no other RefString holds a reference to it.

That aside, unless you are handling reference of your string object inside ScriptUtils object, you may want to register your functions with signatures like

"void removeHtmlTags(string@+, const string& in)"

`+` indicating an autohandle.

About COW strings in general, they often prove to be more trouble than they are worth. If lots of raw assignments are expected, they might be a good thing. See http://stackoverflow.com/questions/707014/why-vc-strings-are-not-reference-counted for some reasons why many stl implementations just skip it (at least vc++ and stlport do; gcc libs apparently do not).

It is unnecessary to hold RefString's clones in each RefString instance. Simply replace pString with a smart pointer to a reference-counted version of std::string. This way there are two reference counting mechanisms involved:

1. Each reference-counted std::string holds the number of RefString's that refer to it.

2. RefString's own reference count holds the number of AngelScript (or C++, if necessary) objects that refer to it, such as string handles.

So RefString's assignment can simply acquire the source RefString's smart pointer to the reference-counted std::string. By doing so it will release the reference-counted std::string, decreasing its reference counter, which will result in its deletion if and only if no other RefString holds a reference to it.

That aside, unless you are handling reference of your string object inside ScriptUtils object, you may want to register your functions with signatures like

"void removeHtmlTags(string@+, const string& in)"

`+` indicating an autohandle.

About COW strings in general, they often prove to be more trouble than they are worth. If lots of raw assignments are expected, they might be a good thing. See http://stackoverflow.com/questions/707014/why-vc-strings-are-not-reference-counted for some reasons why many stl implementations just skip it (at least vc++ and stlport do; gcc libs apparently do not).