At 11:56 �� 19/4/2002, Tim Swenson wrote: ><snip> >>Actually equivalent Sbasic code generated by Turbo is faster by a factor >>of almost 15% or so (in tests I run) over QLiberator. >>Turbo has other problems though like parameter passing... > >TURBO does have more constraints than does Qlib. Qlib allows linking in >of extensions (TURBO does not). Qlib allows for keywords not loaded in an >extension, if the code never hits that section (TURBO complains at runtime >about a keyword not being available even if that section of the code is >never executed). There are other examples out there. I find that TURBO >feels a bit more constricting that Qlib.
I don't see that really to be a problem. However I remember reading somewhere about George wanting to solve this. It's like not loading QLib_run! The thing is that Turbo being around for so long (from the time of Supercharge) it has an impressive amount of code templates that do the trick. And George updates it extremely often. What was the last time Q-Liberator was updated? Additionally being restrictive in some aspects I believe that is a feature. By being very strict programmers are forced to write "clean" programs (Not that dirty tricks aren't possible of course... you can still call machine code ;-) or mess with the Memory :-). And now with full GD2 support it's a clear choice. >With all that said, I'm still a big fan of TURBO as it is FREEWARE. I'd >like to see some more elegant work-arounds to some of the issues, but I'll >take what I get. The combination of TURBO and TurboPTR is the only >freeware way to write PE programs in SBasic. Well in a little bit EasyPTR too :-) (At least that's what I gather :-)) Phoebus
