FreeBASIC Dialects
FreeBASIC version 0.17b introduces a -lang command-line option, used to change the language compatibility mode for different dialects of the basic language.
Starting with version 0.18.3b the -lang qb dialect has been further restricted to only allow what would have been allowed in QuickBASIC.
In version 0.18.4b the -lang fblite dialect was added, intended to replace -lang deprecated in future.
In version 0.20.0b the #lang directive and $Lang metacommand were added to specify a dialect from source.
The -lang option was needed to allow FreeBASIC to support object-orientation and other features in the future, without crippling the QuickBASIC support or breaking compatibility with old FreeBASIC sources, and without making FreeBASIC difficult to maintain with many different versions of very similar packages. The QuickBASIC support can continue to be improved, if needed, without breaking the sources written specifically for FreeBASIC.
To compile old GW-BASIC or QuickBASIC/QBasic sources without too many changes, use the -lang qb option on the command-line when running fbc. This option will evolve into a better compatibility with QuickBASIC/QBasic code.
To compile FreeBASIC sources from 0.16b, use the -lang deprecated option. This option is maintained for compatibility and will not evolve in the future, and it's likely to disappear when FreeBASIC reaches a non-beta release.
For programmers who want to access some of FreeBASIC's newer features, but want to retain a more QBASIC-friendly programming style, use the -lang fblite option. This dialect will not undergo significant changes in the future, but will continue to be maintained and supported.
This option is also the most compatible with sources that were made using older versions of FreeBASIC.
It is recommended to use -lang fb for new projects, as new features (object classes, inheritance..) will be added exclusively to this dialect.
-lang fb (the default mode)Starting with version 0.18.3b the -lang qb dialect has been further restricted to only allow what would have been allowed in QuickBASIC.
In version 0.18.4b the -lang fblite dialect was added, intended to replace -lang deprecated in future.
In version 0.20.0b the #lang directive and $Lang metacommand were added to specify a dialect from source.
| -lang option | description |
| fb | FreeBASIC compatibility (default) |
| qb | qbasic compatibility |
| fblite | FreeBASIC language compatibility, with a more QBASIC-compatible coding style |
| deprecated | compatibility with FB 0.16 |
The -lang option was needed to allow FreeBASIC to support object-orientation and other features in the future, without crippling the QuickBASIC support or breaking compatibility with old FreeBASIC sources, and without making FreeBASIC difficult to maintain with many different versions of very similar packages. The QuickBASIC support can continue to be improved, if needed, without breaking the sources written specifically for FreeBASIC.
To compile old GW-BASIC or QuickBASIC/QBasic sources without too many changes, use the -lang qb option on the command-line when running fbc. This option will evolve into a better compatibility with QuickBASIC/QBasic code.
To compile FreeBASIC sources from 0.16b, use the -lang deprecated option. This option is maintained for compatibility and will not evolve in the future, and it's likely to disappear when FreeBASIC reaches a non-beta release.
For programmers who want to access some of FreeBASIC's newer features, but want to retain a more QBASIC-friendly programming style, use the -lang fblite option. This dialect will not undergo significant changes in the future, but will continue to be maintained and supported.
This option is also the most compatible with sources that were made using older versions of FreeBASIC.
It is recommended to use -lang fb for new projects, as new features (object classes, inheritance..) will be added exclusively to this dialect.
Not supported:
1) implicit variable declaration
1) implicit variable declaration
2) type suffixes (!, #, $, %, &)
- They are only allowed for numeric literals, but it's recommended to use Cast or the f (single), d (double), ll (longint), ul (ulong), ull (ulongint) numeric literal suffixes to resolve overloading.
3) DefByte, DefUByte, DefShort, DefUShort, DefInt, DefUInt, DefLng, Deflongint, Defulongint, DefSng, DefDbl, DefStr
4) all parameters passed by reference by default
5) OPTIONs of any kind (no context-sensitivity)
- Instead of Option NoKeyword, use #undef.
- Instead of Option Escape, use: !"some esc seq \n\r" (notice the '!' char) and pass -w pedantic to check for possible escape sequences.
- Option Explicit isn't needed, see item 1.
- Instead of Option Dynamic, declare variable-length arrays using ReDim. Dim can also be used to declare variable-length arrays using variable or no subscripts.
- Instead of Option Base, use explicit lower-bound subscripts in arrays declarations.
- Instead of Option Private, use Private to declare procedures with internal linkage.
- Instead of Option Gosub and Option Nogosub, use procedures with Sub or Function.
6) periods in symbol names
- Use namespaces instead.
- Nested procedures may be allowed in future.
- Use Select Case As Const expr for the latter.
9) Resume
- Most runtime and graphics library procedures now return an error code, like: IF OPEN( "text" FOR INPUT AS #1 ) <> 0 THEN error...
10) '$DYNAMIC, '$STATIC, '$INCLUDE meta-commands embedded in comments
- See item 5 about Option Dynamic.
- Use #include "filename" instead of '$include.
- Just remove them.
12) numeric labels
- Named labels can be used instead, e.g. label_name: / Goto label_name.
13) global symbols with the same name as keywords
- Declare them inside a namespace.
Supported: Anything allowed in version 0.16b, but:
1) GOSUB/RETURN and ON ... GOSUB (even at module-level)
- so the GOSUB implementation could be thread-unsafe in the -lang qb mode, allowing fast execution (-lang qb doesn't support multi-threading, while -lang deprecated does).
Not supported:
1) Classes
1) Classes
- Periods allowed in symbol names make it too difficult and/or ambiguous.
2) Operator overloading
- Periods allowed in symbol names make it too difficult and/or ambiguous.
3) Constructors, destructors and methods in TYPEs.
- Periods allowed in symbol names make it too difficult and/or ambiguous.
Supported: Anything allowed in the -lang deprecated dialect, plus..
1) GOSUB/RETURN
- Use Option Gosub to enable. This will disable RETURN from exiting a procedure, due to ambiguity.
Not supported:
1) Scope blocks
- All variables are given procedure scope. Explicit Scope blocks may be added later.
Supported: Everything not supported/allowed in the -lang fb dialect, plus..
1) Call can be used with forward-referenced functions.
2) Shared can be used inside functions. (W.I.P.)
3) All variables, implicitly or explicitly declared, are always allocated in the procedure scope, like in QuickBASIC.
4) The Data statement won't look up symbols, every token is assumed to be a literal string even without quotes, like in QuickBASIC.
Not supported:
1) Multi-threading
1) Call can be used with forward-referenced functions.
2) Shared can be used inside functions. (W.I.P.)
3) All variables, implicitly or explicitly declared, are always allocated in the procedure scope, like in QuickBASIC.
4) The Data statement won't look up symbols, every token is assumed to be a literal string even without quotes, like in QuickBASIC.
Not supported:
1) Multi-threading
- None of the threading procedures may be used.
2) Classes and Namespaces
3) Procedure and operator overloading
4) Constructors, destructors and other member procedures in Type definitions.
5) Scope blocks
6) Extern blocks
7) Variable initialization
3) Procedure and operator overloading
4) Constructors, destructors and other member procedures in Type definitions.
5) Scope blocks
6) Extern blocks
7) Variable initialization
- All variables are moved to the procedure scope (like in QuickBASIC), making initializing local variables too difficult to support.