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!


Wracky

Member Since 03 Jun 2007
Offline Last Active Feb 05 2015 01:11 PM

Posts I've Made

In Topic: Template containers angelscript addon library release!

29 January 2015 - 03:07 PM

Awesome! Thank you so much!
This literally saved me a lot of work. I was working on my own map implementation a while back, until Andreas pointed me here.
You nicely unified the code behind all containers, which really is a big plus.

 

The iterator additions make this complete. I love it.

I do prefer the standard bindings, so I'll change them like you suggested.
The extra safety measure will really come in handy as well. I can compile my engine with the security in debug, and without in release if it becomes relevant to increase performance after testing the game logic in debug. Perfect.

Thanks again


In Topic: Template containers angelscript addon library release!

08 January 2015 - 02:03 PM

Sweet!

I'm downloading it now. Thank you so much for the quick response.
I found Andreas' suggestion interesting as well.

Is it possible to make the map behave more like the stl one ?
Can it be extended so that find returns an iterator directly?

 

If that is possible, maybe functions like begin, end, rbegin, rend etc can also be supported.

In that case, find can return end if an object cannot be found, like stl does.

Thanks again.


In Topic: Template containers angelscript addon library release!

02 January 2015 - 06:00 PM

Hi Sami,

Thanks for posting! Looks good!
Do you have any plans for adding support for opIndex to the map and unorderd_map ?

So that maps can be used like myMap[myKey] = myValue ?

I think that would be a nice addition.

 

Another thing: 

While trying to add AACT to our project, I noticed that it didn't play nice with our custom String class.
Sure there is a define in the aatc_config that I can change, but our string doesn't have the same interface as the std::string and this gives some problems in the implementation of the aatc_script_Funcpointer::Set functions.

 

It was easily to fixed though, and kind of our problem for being boneheads and writing our own string class :P
I see why that's kind of a problem when you can't use asIScriptFunction* instead of names....

Anyway!
Keep up the good work!


In Topic: Ownership problem of Funcdefs.

11 October 2013 - 04:54 PM

Thanks for the quick responses.

I got it to work now :) with the type ID from the scriptModule.
The CScriptWeakRef also assumes it gets an handle that was reffed when it was passed, so it releases it as to not keep the strong.

So to make sure the object didn't get destroyed because of that I had to pass the object reffed (so add another ref)

 

Anywayz, glad to finally get it to work.

Oh btw, I looked at the documentation regarding asBEHAVE_GET_WEAKREF_FLAG, and it looked like a whole lot to take in.
Our application though, is fully aware of refcounting on application-registered objects, whether they were reffed/created by script or by the application.
We have our own set of smart pointers, much like the ones in boost, that count strong as well as weak references. Ref-objects expose addRef and Release functions that share the same use/ref count, which we use for the behaviours in script.

 

So basically I could write my own template specialization for weakref<T> instead of adding the WEAKREF_FLAG behavior I guess?
If I use template specialization for all Application types, and use CScriptWeakRef for everything else, I don't have to deal with the shared boolean, and can use our existing weakref methods.  I'll try that later :)

Well thanks again!

Regards,

Wracky.
 


In Topic: Ownership problem of Funcdefs.

10 October 2013 - 02:51 PM

I tried the GetTypeIdByDecl() approach before I commented, but that just returns asINVALID_TYPE for anything other than Application classes. The function is invoked by script, so it is compiled and other types should be available at the point of the call.

 

Thanks for telling me about the asBEHAVE_GET_WEAKREF_FLAG. Can't believe I've missed that :-)

Regards,

Wracky


PARTNERS