TheAtom

It is an improved version of the good old preprocessor by Anthony Casteel (also known as Deyja), from sources dating back to 2005 or so. I was going to mention it in relation to the other topic: http://www.gamedev.net/topic/640629-cc-like-define-directive-patch-attached/

It is built over version 0.5 of that preprocessor. I couldn't find any newer version (if it ever existed), in fact I can't seem to find the original sources whatsoever, anywhere. In addition to the features from 0.5, our version includes:

- multiline macros,

- recursive macro expansion,

- token concatenation with ## operator,

- evaluation of constant expressions (somewhat incomplete),

- additional features for #pragmas,

- minor things such as #warning and #error,

- incidentally, character literals are now converted to unsigned integers.

It is still independent from AngelScritpt and is platform-agnostic, and features a working line number translation between sources and the preprocessed file. And it is still pretty lightweight.

I have hopes to release (or should I say re-release) it soon, although that's not entirely up to me. And following that, discuss a possibility of including it in AngelScript sdk in some way (probably as an addon).

Indeed they are. I just realized that it is our preprocessor that converts the character literals into integers, as a normal step of preprocessing. We don't even have asEP_USE_CHARACTER_LITERALS enabled. Another false alarm!

It appears that character literals are now treated as signed (most likely per rev 1600), but scriptstdstring addon's index operators still use uint8. This forces a rather awkward syntax needed for working with literals of high ASCII codes without getting any warnings:

somestring[5] == uint8('Đ');

I think character literals should stay unsigned, but in any case their sign should match that of the addon.

The thing turned out to be a false alarm: it was Windows' CR/LF conversion mess up while loading the bytecode in our new test tool. Sorry to have bothered about this.

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