Have a few questions about AS, so I figured I would just lump them into one thread! 1. Is there casting in AS? Does it use the c-style cast of (<type>)? 2. Is there an easy way of wrapping math.h for use with AS? I want to expose sin, cos, etc to my scripts. I assume there is no easy shortcut? 3. What are handles exactly? I've read the docs(more than once!) but I'm still a little confused. If someone could give me a one-liner example of why I would use them vs not using them - would be awesome! Cheers!

1. Yes, and no. I'm still working on the full implementation of casting in AS, but it is already working somewhat. You can cast to primitives, either through int(epxr) or cast<int>(expr). I think of the first as the construct cast, i.e. it creates an int 'object' from the expr, and the second as the cast operator. You can also register constructors for your types that can be used by the cast operator to allow casts between types. In a future version I'll also add the possibility of registering cast behaviours (instead of constructors), as well as easier casting between classes related to each other.

2. Just register the functions in math, as you would any other global function, e.g. RegisterGlobalFunction("float sin(float)", asFUNCTION(sinf), asCALL_CDECL); Of course, if your target system doesn't support native calling conventions yet, then you'll have to write the wrapper that uses the generic interface.

3. Handles are sort of like smart pointers in C++. In AngelScript they are stored as a pointer to the object, and AngelScript makes sure to increment and decrement the reference count of the object as necessary when manipulating the pointer. For an object to support handles, you need to register the ADDREF and RELEASE behaviours. Since with AngelScript I'm trying to provide a safe environment for development, i.e. without loose pointers or memory leaks, you'll find that by supporting handles in your objects you're getting a more flexible way of working with them, i.e. with handles AngelScript will let you pass the type by reference to a functions without any restrictions. Without handles AngelScript will only let you pass the type by reference in one direction, i.e. either 'in' or 'out'. Handles will also allow you to do polymorphing for script classes that implement interfaces, since AngelScript is able to determine the true class from the handle to an interface, and thus let you cast to the parent class, or any other interface it implements.

I hope that helped a little. :)

Regards,
Andreas

PS. I know, I really need to put these things in the documentation.

Yes thanks!

So if one doesn't register the ADDREFF / et. al. , we just can't use handles?

Are the constructors, / et. al. behaviours mandatory when registering a instantiable(sp?) object?

The constructor is only mandatory if the object stores information that must be initialized at allocation, e.g. virtual function table, reference counter, or pointers to other objects.

The destructor is only mandatory if your object needs to free resources upon destruction, and doesn't have the addref/release behaviours registered. If the addref/release behaviour is registered AngelScript will never call the destructor, since that is the responsibility of the release behaviour.

Regards,
Andreas

Just to add: a constructor is also required for registered class types (types you register in C++) that are 'complex'. A 'complex' class is one that contains a constructor (maybe destructor too) in the C++ class.

The reason is that for those types of objects the compiler will decide whether or not to pass that object, when passed or returned by value, in memory or in registers depending on whether it is complex.

So, if your class in C++ has a constructor make sure you register a constructor behavior for your type (when you register the type) to keep behavior of AngelScript in sync with the C++ compiler.

Actually, that behaviour is controlled by the parameter asOBJ_CLASS_CDA sent to RegisterObjectType. The acronym CDA means (C)ONSTRUCTOR, (D)ESTRUCTOR, (A)SSIGNMENT, i.e. this flag should be used for classes with all three of these. For classes that have only a contructor defined the parameter should be asOBJ_CLASS_C, and so on.

AngelScript doesn't use the registered constructor, or lack of registration, to determine how the class should be passed to the C++ application. It wouldn't work since the application is allowed to register constructors for C++ types that normally don't have constructors, and so on.

Quote: Original post by WitchLord
Actually, that behaviour is controlled by the parameter asOBJ_CLASS_CDA sent to RegisterObjectType. The acronym CDA means (C)ONSTRUCTOR, (D)ESTRUCTOR, (A)SSIGNMENT, i.e. this flag should be used for classes with all three of these. For classes that have only a contructor defined the parameter should be asOBJ_CLASS_C, and so on.

AngelScript doesn't use the registered constructor, or lack of registration, to determine how the class should be passed to the C++ application. It wouldn't work since the application is allowed to register constructors for C++ types that normally don't have constructors, and so on.

I was only basing my experience on the PPC64 port when doing "returns in mem" stuff and from yesterday.

I ran into a problem yesterday with a class that I was registering for AngelScript. I registered the time as asOBJ_CLASS and then gave it a bunch of member functions (no constructor, destructor or assignment). I had a global function that returned this registered class by value - however when it was called (on x86 platform, didn't test on ppc64) the arguments to the function were all messed up. Internally, on the native function call the argument list was off by a DWORD.

The problem turned out to be that when VS2005 compiled that native C++ function that returned the object by value, it does so "in memory" -- but AngelScript wasn't taking this into account when it was setting up the native system call.

The fix: I registered the class as asOBJ_CLASS_C and gave it a default constructor behavior. Fixed the problem.

This made me remember when I was doing the PPC64 port, how there was a check to see if the class was "complex" or not...and things would be handled differently if it was (such as return in memory).

Indeed. That's why it is important to pay attention to the asOBJ_CLASS_??? parameter when registering types. I wish there was some way of determining this value automatically, but I've yet to discover how.