(1) error 135: Only valid in -lang deprecated or qb, found 'defint' in 'cls: defint a-z'
(2) error 137: Suffixes are only valid in -lang deprecated or qb, found 'temp' in 'declare sub replace (byref temp$, a$, b$)'
(2) error 137: Suffixes are only valid in -lang deprecated or qb, found 'temp' in 'declare sub replace (byref temp$, a$, b$)'
???
Last edited by agamemnus on Jun 05, 2007 20:35, edited 1 time in total.
agamemnus wrote:I hope that once your object oriented stuff is added, you can begin supporting the QB stuff (eg: without using -lang qb) again.
Is there a reason that this would work when FB's OO stuff is more complete? I don't see as to why this would be, unless QB was put in it's own Class? :P Even then a compiler option vs using langQB, doesn't really seem like it would be bad.
agamemnus wrote:I hope that once your object oriented stuff is added, you can begin supporting the QB stuff (eg: without using -lang qb) again.
Is there a reason that this would work when FB's OO stuff is more complete? I don't see as to why this would be, unless QB was put in it's own Class? :P Even then a compiler option vs using langQB, doesn't really seem like it would be bad.
Cause it seems that the new 17b version with -lang qb has fewer features than the 16c version...
agamemnus wrote:Cause it seems that the new 17b version with -lang qb has fewer features than the 16c version...
Well, afaik, a lot of compatibility issues with QB have been fixed since the -lang qb came out. I don't recall any compatibility being lost with -lang qb...
The -lang qb switch has brought us back some QB features that were missing since the first versions of FB.
The most important :
-Defaut variable type is back to SINGLE
-Byte alignment of UDT is now the default
-STR left-pads positive integers with a space again
-RND uses a clone of QB's algorithm by default
-LOCATE accepts the full 5 arguments accepted by QB (but the last 2 have no effect)
This is not yet complete compatibility but it's a lot closer.
Some of that is terrible, though.... I coded some programs with the no-space-padding thing and now it's back. I could not use the -lang qb option but then other things will break. =\
I've never been a fan of the space-preceded str() function, but I guess it's necessary for QB programs to work more as expected. To remove the space, ltrim(str(...)) still works, and will give consistent results between the different dialects, but it doesn't look particularly nice (though that could be covered up with a macro) and it's not as efficient.
One problem with "-lang qb", which I think probably hurts it most, is the lack of variable initialisers (e.g. dim a as integer = 2). If like to use them, it's one the biggest stumbling blocks to writing code that will compile in all three dialects, and it's mainly for this reason that I generally don't consider it worthwhile.
For some situations, in many ways, "-lang deprecated" is a happy medium. Many (reasonably well-written) programs written in QBASIC can work OK in it without needing changes, and the same can be said for programs written in the new dialect that don't use any advanced features.
Cause it seems that the new 17b version with -lang qb has fewer features than the 16c version...
Read changelog.txt, thanks.
Where are you going with this? Your qb compatibility fixes are nice, but counting prime said:
>One problem with "-lang qb", which I think probably hurts it most, is the lack of variable initialisers (e.g. dim a as integer = 2). If like to use them, it's one the biggest stumbling blocks to writing code that will compile in all three dialects, and it's mainly for this reason that I generally don't consider it worthwhile.
