Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 24 Aug 2010
Offline Last Active Dec 11 2013 01:23 PM

Posts I've Made

In Topic: AngelScript 2.26.2

04 April 2013 - 07:16 PM

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

In Topic: AngelScript 2.26.2

04 April 2013 - 04:56 PM

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!

In Topic: AngelScript 2.26.2

04 April 2013 - 12:44 AM

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.

In Topic: Debug information invalidates the bytecode

03 April 2013 - 08:46 PM

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.

In Topic: asOBJ_REF and asOBJ_VALUE at the same time

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