Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


#ActualTheAtom

Posted 25 February 2013 - 12:54 PM

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).


#3TheAtom

Posted 25 February 2013 - 10:13 AM

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).


#2TheAtom

Posted 25 February 2013 - 10:13 AM

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).


#1TheAtom

Posted 25 February 2013 - 10:10 AM

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).


PARTNERS