Oh, and,
Are we going to get a truly uniform interface for setting arguments that can handle all types the same way?
Globals already have this kind of interface.
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
AngelScript 2.10.0 released
mono2k:
Yes there is. GetArgAddress and SetReturnAddress is the raw access to the pointer value, it doesn't add or release references. GetArgObject and SetReturnObject is more intelligent and will increase references of object handles, and in case of object values it will create copies of the object as necessary.
Deyja:
If you don't feel there is a need to upgrade then it's perfectly fine to continue with the version you're using.
I'm continously improving the interface to make it easier to use, currently the GetArgPointer and GetReturnPointer is the best interface if you want a uniform interface. It gives you the address of the location where the value is stored, and let's you set the value as needed. It may not be perfect yet, but let me know how I can make it better and I'll see what I can do.
Regards,
Andreas
Quote:
Is there any real difference between GetArgAddress & GetArgObject and between SetReturnAddress & SetReturnObject? I have a feeling this is the reason for my problem...
Yes there is. GetArgAddress and SetReturnAddress is the raw access to the pointer value, it doesn't add or release references. GetArgObject and SetReturnObject is more intelligent and will increase references of object handles, and in case of object values it will create copies of the object as necessary.
Deyja:
If you don't feel there is a need to upgrade then it's perfectly fine to continue with the version you're using.
I'm continously improving the interface to make it easier to use, currently the GetArgPointer and GetReturnPointer is the best interface if you want a uniform interface. It gives you the address of the location where the value is stored, and let's you set the value as needed. It may not be perfect yet, but let me know how I can make it better and I'll see what I can do.
Regards,
Andreas
Quote: If you don't feel there is a need to upgrade then it's perfectly fine to continue with the version you're using.You misconstrue. It's not that I don't need or want to, it's just that I haven't bothered.
Quote: I'm continously improving the interface to make it easier to use, currently the GetArgPointer and GetReturnPointer is the best interface if you want a uniform interface. It gives you the address of the location where the value is stored, and let's you set the value as needed. It may not be perfect yet, but let me know how I can make it better and I'll see what I can do.
The issue, if I remember the behavior you described in another thread, is that these functions treat primitive and object types differently. In one case, they return a pointer to the value, and in the other, they return a pointer to a pointer.
Yes, that's true. But it's only done that way because that's how AngelScript stores the values internally.
Andreas,
And what about properties being registered like
should I use GetArgAddress/SetReturnAddress or GetArgObject/SetReturnObject to access "signal_t" type variables?
Quote: Original post by WitchLord
Yes there is. GetArgAddress and SetReturnAddress is the raw access to the pointer value, it doesn't add or release references. GetArgObject and SetReturnObject is more intelligent and will increase references of object handles, and in case of object values it will create copies of the object as necessary.
And what about properties being registered like
engine->RegisterObjectType("signal_t", 0, asOBJ_REF | asOBJ_NOHANDLE); should I use GetArgAddress/SetReturnAddress or GetArgObject/SetReturnObject to access "signal_t" type variables?
asOBJ_REF | asOBJ_NOHANDLE means that the script engine may not hold any handles to the object type, i.e. it cannot instanciate variables of the type, nor pass it around in parameters.
This combination of flags is only useful for singletons, where a global property is registered from the application to give the script access to the singleton's methods and properties.
This combination of flags is only useful for singletons, where a global property is registered from the application to give the script access to the singleton's methods and properties.
it is not technically true. I'm using unsafe references and I'm able to pass a reference to "asOBJ_REF | asOBJ_NOHANDLE" object in parameters.
Is this an unwanted AS behaviour?
Is this an unwanted AS behaviour?
it will be nice to have an easy way to register a type that should not be allowed to be constructed in the script (i.e. instanced only via RegisterGlobalProperty) but it should be allowed to pass references to an object of that type as a parameter to script functions.
Why would you want that? If it is already available as a global property, why pass it around as a parameter?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
