🎉 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!
variable argument
Author
Angel Script cant not support variable argument,such as
printf("%d%d%d\n", 10, 10, 100);
but because its native C call interface, I think it is easy to do.
can you add it?
it is verry very useful
Quote: it is verry very useful
No, it is verry very dangerous. AngelScript supports the alternative C++ typesafe method - streams.
Exactly.
Variable arguments may not be difficult to implement, at least the way C++ works, but making them safe is near impossible, thus AngelScript will not support them.
Streams are a very good alternative for this, and can easily be used.
out << 10 << 10 << 100 << endl;
Another alternative is to use string concatenation to format the string for printing.
print("" + 10 + 10 + 100 + "\n");
Both of these alternatives are supported by AngelScript. For the first alternative you should be able to use Sam Cragg's stream classes. (They may need to be adapted to the latest version of AngelScript.)
The second alternative can already be used with the asCScriptString add-on. Just register a function for printing strings.
Regards,
Andreas
[Edited by - WitchLord on August 18, 2005 7:00:10 AM]
Variable arguments may not be difficult to implement, at least the way C++ works, but making them safe is near impossible, thus AngelScript will not support them.
Streams are a very good alternative for this, and can easily be used.
out << 10 << 10 << 100 << endl;
Another alternative is to use string concatenation to format the string for printing.
print("" + 10 + 10 + 100 + "\n");
Both of these alternatives are supported by AngelScript. For the first alternative you should be able to use Sam Cragg's stream classes. (They may need to be adapted to the latest version of AngelScript.)
The second alternative can already be used with the asCScriptString add-on. Just register a function for printing strings.
Regards,
Andreas
[Edited by - WitchLord on August 18, 2005 7:00:10 AM]
Something seems to be wrong with your first example. It is just the word 'out'. Chances are, the board misinterpreted your opening angle as starting an HTML tag. For your second example, does the std::string addon binding code support this syntax? If not, I'll add it for you. I've already had to modify it to support binding strings with custom allocators; it would be trivial to add a few more operator+s.
Funny.. I would have thought that users of a scripting language would've been more open to the advantages of using domain-specific languages. Are the differences really that great between specifying a native function's signature when registering it with Angel Script and specifying a variable's type when sending it to printf? The consequences of an error certainly are the same..
Personally generally I find complex formatting much easier to manage with printf rather than the equivalent using C++'s streams. I also use printf regularly and the few typesafety problems I've had were almost always easily spotted and fixed.
I'm willing to admit that this is mostly a matter of personal opinion and habit, which is exactly why I think the feature should be provided as an alternative if it truly is an easy feature to implement.
Personally generally I find complex formatting much easier to manage with printf rather than the equivalent using C++'s streams. I also use printf regularly and the few typesafety problems I've had were almost always easily spotted and fixed.
I'm willing to admit that this is mostly a matter of personal opinion and habit, which is exactly why I think the feature should be provided as an alternative if it truly is an easy feature to implement.
Many of us will let our users modify our scripts though, and just think about how easy it would be to do some damage with it.. I mean, I don't think I'm the only one who has crashed an app with printf().. :p
Deyja:
I fixed the example. Thanks for letting me know.
Yes, the asCScriptString already supports this kind of concatenations.
doynax:
I do not quite understand what you mean. I'm not trying to make the script library safe from application writer errors, only from script writer errors. That is, AngelScript can't guarantee that the application writer has registered function pointers with the right signature, but it is the responsibility of the application writer to do that guarantee. On the other hand, AngelScript can guarantee that scripts do only what the application allows them to do. This is extremely important as scripting is mostly used give the possibility to users customize the application and you wouldn't want to have the scripts crash the application, would you?
Maybe in the future I'll implement dynamic function parameters, but it would then be a custom calling convention that passes not only the parameter values but also the parameter types. This would allow the application to verify that the type is what it is expecting. This kind of implementation however is not easy, and would go completely against what AngelScript currently does.
DvDmanDT:
I'm glad you agree with me. :)
I fixed the example. Thanks for letting me know.
Yes, the asCScriptString already supports this kind of concatenations.
doynax:
I do not quite understand what you mean. I'm not trying to make the script library safe from application writer errors, only from script writer errors. That is, AngelScript can't guarantee that the application writer has registered function pointers with the right signature, but it is the responsibility of the application writer to do that guarantee. On the other hand, AngelScript can guarantee that scripts do only what the application allows them to do. This is extremely important as scripting is mostly used give the possibility to users customize the application and you wouldn't want to have the scripts crash the application, would you?
Maybe in the future I'll implement dynamic function parameters, but it would then be a custom calling convention that passes not only the parameter values but also the parameter types. This would allow the application to verify that the type is what it is expecting. This kind of implementation however is not easy, and would go completely against what AngelScript currently does.
DvDmanDT:
I'm glad you agree with me. :)
Quote: Original post by WitchLord
On the other hand, AngelScript can guarantee that scripts do only what the application allows them to do. This is extremely important as scripting is mostly used give the possibility to users customize the application and you wouldn't want to have the scripts crash the application, would you?
Actually, to me Angel script in itself seems to be aimed more towards C programmers wanting to force an abstraction layer between their game logic and engine, rather than a simple language for end-users wanting to tweak the behaviour of their application.
I do see your point however and I agree that in some cases it is necessary to be able to provide a perfect sandbox for the scripting environment.
Still, most environments provide the script writer with enough power to do things much worse than crashing the application already, an infinite loop or memory leak is probably worse (i.e. more inconvenient for the user and harder to debug) and both are very hard to guard against. Besides, it's not as if a printf wrapper would open up the application to buffer overrun exploits.
I guess what I'm trying to say is that while the use of variadic functions would be an inevitable security hole it's still not that much of a problem in practice, and I've always been sceptical of cutting features just because they are too easy to abuse.
I should probably also point out that I don't use AS actively and have little personal interest in whether this gets implemented or not, I'm just arguing for the sake of it.
Quote:
I guess what I'm trying to say is that while the use of variadic functions would be an inevitable security hole it's still not that much of a problem in practice, and I've always been sceptical of cutting features just because they are too easy to abuse.
That's one of major philosophical flaws that allow things like SQL Injection and cross site scripting to occur: Why cut a feature when the chance of it being exploited is slim. The answer: because history has proven this design philosphy to cost businesses billions.
AngelScript already has guards against memory leaks and infinit loops, so I really don't consider them very difficult to implement. The application just have to be aware of the possibility and make implement the script interface correctly. [wink]
My aim with AngelScript is to make a scripting layer that is safe for tampering and make it easy for application writers to embed in their projects. My first goal thus has to be to eliminate security risks. With security risks I don't just mean potential weaknesses that hackers can exploit, but also things that can have the application crash with hard to detect bugs, etc.
That said, I intend to implement full support for pointers (something that I more or less had in version 1.10.1d, but removed for 2.0.0). Only this time the support for pointers will be optional, i.e. the application writer chooses whether he wishes to expose this powerful but unsafe feature or not. It will probably be a while before I get to implement this though.
printf() is a very convenient way of formatting strings, but too frequently it is the cause of errors, especially for inexperienced programmers which most script writers certainly will be. I will not support printf in the way C implements it, and there is no way you can convince me otherwise. I'm not trying to be hard on you, I see your point and I somewhat agree with you, it just don't fit together with my goals for AngelScript. I may allow variable arguments in another way though, but it will then be a controllable way (like I mentioned above).
My aim with AngelScript is to make a scripting layer that is safe for tampering and make it easy for application writers to embed in their projects. My first goal thus has to be to eliminate security risks. With security risks I don't just mean potential weaknesses that hackers can exploit, but also things that can have the application crash with hard to detect bugs, etc.
That said, I intend to implement full support for pointers (something that I more or less had in version 1.10.1d, but removed for 2.0.0). Only this time the support for pointers will be optional, i.e. the application writer chooses whether he wishes to expose this powerful but unsafe feature or not. It will probably be a while before I get to implement this though.
printf() is a very convenient way of formatting strings, but too frequently it is the cause of errors, especially for inexperienced programmers which most script writers certainly will be. I will not support printf in the way C implements it, and there is no way you can convince me otherwise. I'm not trying to be hard on you, I see your point and I somewhat agree with you, it just don't fit together with my goals for AngelScript. I may allow variable arguments in another way though, but it will then be a controllable way (like I mentioned above).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
