// CPP -------------------------------------------------
Object::operator int () const {
return (int) this->val;
}
engine->RegisterObjectBehaviour("object", asBEHAVE_CAST, "int f()", asMETHOD(Object, operator int), sCALL_THISCALL);
// or
int castObjectFromInt (Object* obj) {
return (int) obj->val;
}
engine->RegisterGlobalBehaviour(asBEHAVE_CAST, "int f(const Object& in)", asFUNCTION(castObjectFromInt), asCALL_CDECL);
// SCRIPT ---------------------------------------------
object o (10);
int a = (int) o;
🎉 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!
asBEHAVE_CAST
Author
there will be at some point a new behaviour that let you attach
a function when the cast operator is called ?
just throwing some ideas ;)
how can i make this change to the parser and compiler in a straightforward way ?
what classes are involved if i want to add a new behaviour ?
I'm actually starting to work on this right now. The first thing I need to do is to change the syntax for casting. AngelScript will now support the old C style as well, i.e.
This is necessary, because the current casting syntax conflicts with the class constructors when casting to an object type.
Once I have this I plan on providing the possibility for registering casting behaviours for classes, much like you suggested.
Regards,
Andreas
(int)expressionThis is necessary, because the current casting syntax conflicts with the class constructors when casting to an object type.
Once I have this I plan on providing the possibility for registering casting behaviours for classes, much like you suggested.
Regards,
Andreas
Author
thanx, hope to see something working soon.
will primitive to primitive casting be provided by the engine or we are supposed to write our functions for casting e.g. a float to an int (althout desirable) ?
will primitive to primitive casting be provided by the engine or we are supposed to write our functions for casting e.g. a float to an int (althout desirable) ?
Casting between built-in types (primitives) will be provided by the engine, just as it is today. You will not be required to register those casts. That wouldn't make much sense, would it? ;)
I don't see much reason for allowing the application to overload these casts either, but if you have a really good reason perhaps you can convince me otherwise.
I don't see much reason for allowing the application to overload these casts either, but if you have a really good reason perhaps you can convince me otherwise.
It may be advantageous to be able to register primitive-to-primitive casting. For example, the default float->int conversion is truncation. It may be more appropriate for your scripts to round in some other fashion.
Might I suggest a syntax more in line with the C++ syntax rather than the C syntax. The C syntax will suffer all the same problems in AngelScript that it does in C++. Obviously, you can't use templates. But something like 'cast(type)(value)' stands out - that ()() isn't something you see normally, and AFAIK isn't current syntactically correct in AngelScript under any circumstances. It can be in C++, if a function returns a function pointer or a functor object.
Might I suggest a syntax more in line with the C++ syntax rather than the C syntax. The C syntax will suffer all the same problems in AngelScript that it does in C++. Obviously, you can't use templates. But something like 'cast(type)(value)' stands out - that ()() isn't something you see normally, and AFAIK isn't current syntactically correct in AngelScript under any circumstances. It can be in C++, if a function returns a function pointer or a functor object.
Author
imho a notation more like "x = cast<type> (value);" would be better looking and less confusing than ()()...
i agree with deyja, would be better if primitive to primitive casting is provided by the engine BUT could be overridable by the programmer if he wants to. are we speaking of modularity ? i think a perfect engine should provide a basic implementation for making it to work, but leave the programmer the possibility to replace that functionality completely with something more suitable for each application he's developing.
i agree with deyja, would be better if primitive to primitive casting is provided by the engine BUT could be overridable by the programmer if he wants to. are we speaking of modularity ? i think a perfect engine should provide a basic implementation for making it to work, but leave the programmer the possibility to replace that functionality completely with something more suitable for each application he's developing.
I suggested ()() instead of <>() simply because angelscript doesn't already use <> as brackets. Why introduce that mess to AngelScript?
You brought up a good point that I hadn't thought about before. I didn't remember the case when an expression evaluates to a function pointer, which is then called. It would have a very similar syntax to the C cast. Of course the expression wouldn't be a data type, so it would be possible to tell them apart, but it might be better to do something like you're suggesting, with the cast<type>() or cast(type)().
I've never been a fan of the C++ dynamic_cast<>, const_cast<>, etc, but then I never really thought about why they were needed.
Thanks for bringing this up. I'll do some more thinking before deciding upon the exact syntax that I'll adopt.
Making casts between primitive types overridable shouldn't be too difficult. But I'll leave that to a future version.
Thanks,
Andreas
I've never been a fan of the C++ dynamic_cast<>, const_cast<>, etc, but then I never really thought about why they were needed.
Thanks for bringing this up. I'll do some more thinking before deciding upon the exact syntax that I'll adopt.
Making casts between primitive types overridable shouldn't be too difficult. But I'll leave that to a future version.
Thanks,
Andreas
I actually like the new C++ style casts. They're quite verbose, but it allows the compiler to perform some extra checking. This alerts you if you try things that aren't going to work. Implementing their full support in AS is probably too much though.
I like cast<type>(value) better than cast(type)(value). It doesn't make it really stand out, but making the cast a function might work too: cast(type, value). Or leaving out the cast keyword and use just <type>(value). You could even go for something exotic like value->type. Just throwing some ideas around.
I like cast<type>(value) better than cast(type)(value). It doesn't make it really stand out, but making the cast a function might work too: cast(type, value). Or leaving out the cast keyword and use just <type>(value). You could even go for something exotic like value->type. Just throwing some ideas around.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
