funcdef void F();
array<F@> arr;
void f()
{
arr[0]();
}
The same issue happens here:
F@ g()
{
return null;
}
void f()
{
g()();
}
Speaking of funcdefs, Is it possible to allow them to be shared?
Bug with parsing of callable expressions
July 03, 2012 02:07 PM
Revision 1289. This code gives a parsing error, "Expected ';'" at the line with arr[0]().
The same issue happens here:
Speaking of funcdefs, Is it possible to allow them to be shared?
The same issue happens here:
Speaking of funcdefs, Is it possible to allow them to be shared?
July 03, 2012 02:37 PM
Thanks. I have definitely not predicted these scenarios. I'll work on the necessary changes.
funcdefs are automatically shared as long as all types (arguments and return value) are shared.
Regards,
Andreas
funcdefs are automatically shared as long as all types (arguments and return value) are shared.
Regards,
Andreas
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
July 03, 2012 06:54 PM
funcdefs are automatically shared as long as all types (arguments and return value) are shared.
That is good to know. I was just assuming that like everything else they are specific to the module. What is the expected behaviour if two modules declare funcdefs with the same name, but different signatures (and let's say that all arguments and the return value are shared)? I ask that in the light of that undocumented feature you mentioned once, with shared objects being ignored by the compiler after their first declaration.
July 03, 2012 09:50 PM
In this case each module will only see their own funcdef.
When checking if a matching funcdef exists, the engine compares all types and name and only if everything matches are they said to be the same type.
Perhaps it would be more consistent to require the declaration with 'shared' in order to match funcdefs from a different module, but so far I don't really see a problem with leaving it the way it is.
When checking if a matching funcdef exists, the engine compares all types and name and only if everything matches are they said to be the same type.
Perhaps it would be more consistent to require the declaration with 'shared' in order to match funcdefs from a different module, but so far I don't really see a problem with leaving it the way it is.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
July 21, 2012 12:39 AM
I've implemented the support for this in revision 1368.
Regards,
Andreas
Regards,
Andreas
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
169
July 21, 2012 04:58 AM
How feasible is it looking to add a function-call operator, given the new development?
(Pardon if this is tangental to the topic at hand; for the uninformed, Andreas remarked that this change would be involve of the work prerequisite to function-call operators.)
(Pardon if this is tangental to the topic at hand; for the uninformed, Andreas remarked that this change would be involve of the work prerequisite to function-call operators.)
July 21, 2012 02:45 PM
I don't think it will be too difficult. Basically the compiler needs to be modified in the same places where the function pointer is handled, so that when the expression is not a function pointer the compiler instead checks if it is an object with available methods named 'opCall'. If it is then the argument list should be evaluated and the right overload chosen just like a normal function call.
AngelCode.com - game development and more - Reference DB - game developer references
AngelScript - free scripting library - BMFont - free bitmap font generator - Tower - free puzzle game
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
