Assertions in torquescript?
by Alex Rice · in Torque Game Builder · 10/23/2005 (3:50 pm) · 10 replies
I see that in the C++ engine code, assertions are used extensively (keyword "assert" appearing in the T2D code nearly 1,000 times.).
In torquescript, what is the best way to use assertions, since there is no builtin console function for this purpose?
In torquescript, what is the best way to use assertions, since there is no builtin console function for this purpose?
About the author
#2
Here it is if you're interested:
Used as...
EDIT: I was thinking of adding something like a "t2dAssertISV" which worked in release builds (same as C++ AssertISV call - In-shipping version) as well but this will be there in your final products which isn't necessarily the best way to go but it isn't the worst either. ;)
- Melv.
10/24/2005 (5:52 am)
I added a script assertion in the T2D utility function group that only works in debug builds. Currently, there's no way to get at the originating script line/function from the "ConsoleFunction" macro else I would've exposed that info but you can enter your own condition and a failing message as you would expect.Here it is if you're interested:
//-----------------------------------------------------------------------------
// Assert Fatal.
//-----------------------------------------------------------------------------
ConsoleFunction( t2dAssert, void, 3, 3, "(condition, message) - Fatal Script Assertion" )
{
// Process Assertion.
AssertFatal( dAtob(argv[1]), argv[2] );
}Used as...
function doSomething(%count)
{
t2dAssert( %count > 0, "doSomething() - Invalid Count!" );
}EDIT: I was thinking of adding something like a "t2dAssertISV" which worked in release builds (same as C++ AssertISV call - In-shipping version) as well but this will be there in your final products which isn't necessarily the best way to go but it isn't the worst either. ;)
- Melv.
#4
10/24/2005 (6:12 am)
Thanks Melv I am going to start using that.
#5
- Melv.
10/24/2005 (6:50 am)
No probs. Here are both functions but again, be careful with the ISV one as it'll always be there in your code, even in release.//-----------------------------------------------------------------------------
// Assert Fatal.
//-----------------------------------------------------------------------------
ConsoleFunction( t2dAssert, void, 3, 3, "(condition, message) - Fatal Script Assertion" )
{
// Process Assertion.
AssertFatal( dAtob(argv[1]), argv[2] );
}
//-----------------------------------------------------------------------------
// Assert Fatal ISV (In Shipping Version).
//-----------------------------------------------------------------------------
ConsoleFunction( t2dAssertISV, void, 3, 3, "(condition, message) - Fatal ISV Script Assertion" )
{
// Process Assertion.
AssertISV( dAtob(argv[1]), argv[2] );
}- Melv.
#6
07/03/2006 (9:20 pm)
Thanks for adding these Melv. When using t2dAssert() in a RELEASE build of TGB, I was wondering if it's "free" or is there a runtime cost in script with creating the string object for the message parameter when the call to t2dAssert() is encountered? I know that in RELEASE the t2dAssert is a noop.
#7
07/03/2006 (9:39 pm)
I just noticed the condition is evaluated in RELEASE as well as DEBUG. I guess I will stick with my script-only assertion function, and just comment out the function calls before relase.
#8
The quick solution is to treat assert as a special function name at the script parser level. When encountered in a release build the function and all parameters are ignored and would not generate opcodes. If this is done assert would work as one would expect and have zero overhead with DSOs from release builds.
The better solution is to implement a simplified macro system into TorqueScript, but this may be a big task and possibly be as troublesome as it is in C/C++.
07/04/2006 (9:17 am)
At some point real assertions in TorqueScript need to be worked out... especially with the amount of script being written with TGB.The quick solution is to treat assert as a special function name at the script parser level. When encountered in a release build the function and all parameters are ignored and would not generate opcodes. If this is done assert would work as one would expect and have zero overhead with DSOs from release builds.
The better solution is to implement a simplified macro system into TorqueScript, but this may be a big task and possibly be as troublesome as it is in C/C++.
#9
Only the basic:
#define
#undef
#ifdef
#else
#endif
with those we can code scripts for testing purpouses that are
ignored if we want with only one line, comment don't do it here
because the code could spread along all the project.
07/04/2006 (2:41 pm)
I second the preprocesor system:Only the basic:
#define
#undef
#ifdef
#else
#endif
with those we can code scripts for testing purpouses that are
ignored if we want with only one line, comment don't do it here
because the code could spread along all the project.
#10
YAY to Tom's idea !
07/05/2006 (12:42 am)
NAY to C style macrosYAY to Tom's idea !
Quote:treat assert as a special function name at the script parser level. When encountered in a release build the function and all parameters are ignored and would not generate opcodes.
Torque Owner Hans Sjunnesson
--
Hans