Home About Rapid-Q News Archive Download Rapid-Q Screen Shots View Documentation FAQs Compatibility Issues Knowledge Base Links Code Contributions Coding Etiquette EZBoard Public Forum Rapid-Q Mailing List E-mail:

About Rapid-Q Rapid-Q is a cross platform BASIC programming language capable of generating GUI and CONSOLE applications (including CGI applications). Rapid-Q compiles your BASIC source codes to bytecode, which is by default attached to a running interpreter so your executable is self contained. Rapid-Q also allows you to compile as bytecode only, and this bytecode can be interpreted by most languages supporting DLLs, by using some specialized DLLs. If you're not familiar with using DLLs and other programming languages, this feature may not be worth much to you now. The size and speed of your compiled executable isn't as bad as you may think, however, this is the price you pay for an interpreted language.   Compiler Performance Rapid-Q is a single-pass compiler (except when using MACROs). Compilation time is fairly fast, for example, on my P200, compiling a 65,000 line source code took 20 seconds. Obviously you should be skeptical on what kind of code was compiled, but Rapid-Q performs well in compiling even the most notorious types of source codes. The first few seconds or milliseconds is used to initialize Rapid-Q's symbol table, so don't be deceived if it does take 3 seconds to compile a one line source code. Rapid-Q can also optimize your code by eliminating unnecessary instructions, but will likely double your compilation time.   Compatibility with QBasic/VisualBasic Rapid-Q was developed to support most of the commands in QBasic, except for file handling, and graphics routines. If you've used QBasic in any capacity, learning Rapid-Q should be real easy. The only problems that I foresee are file handling and graphics. Most QBasic programmers are familiar with graphics in the DOS world, but graphics under Windows is slightly different because of the multitasking nature of the OS. As for file handling, I decided to adopt file streams, instead of the OPEN command most BASIC programmers are familiar with. Once the programmer understands these two concepts, I think the rest should follow more easily (such as component based programming, which Rapid-Q is). As for VisualBasic, Rapid-Q was not originally modelled to adopt anything that VisualBasic had to offer, but was rather a slight coincidence and a bit of haggling by some users to support some of the richer features of VisualBasic. Rapid-Q is not to be considered a VisualBasic clone, there are many things that are different between the two languages. It is better to think of Rapid-Q as a combination of QBasic with the component-based nature of VisualBasic with some of my own ideas thrown in.   Rapid-Q's Feature List Cross platform DirectX, Direct3D support Easy DLL access Directly supports MySQL Ability to EXTEND types (object programming) Support for template classes, and property sets Built-in socket support (blocking and non-blocking calls) COM/DCOM support (ActiveX and Automation clients) Support for internal resources Support for MACROs, and overloaded MACROs Support for compiler directives, ie. $IFDEF Ability to create CGI applications SUBI and FUNCTIONI (infinite parameters) Supports arrays within UDTs Ability to write to off-screen pages in CONSOLE You can use the "-" operator on strings Easy to use and learn Most BASIC commands are implemented Integrated development environment with Form designer Compiles to self contained .EXE No additional run-times involved Compiles GUI & CONSOLE applications, autodetection Bytecode can be interpreted by other programming languages Over 1 year in development already, fairly stable Fully supported, active mailing list It's FREE   Rapid-Q's Not-So-Nice List No thread support No Drag 'n Drop Support Not truly multiplatform, Linux/Unix version is a stripped down version COM is not fully supported MDI applications not supported No support for ON ERROR Relaxed type checking No debugging options for Rapid-Q IDE Can't create arrays of EXTENDed types I know there's more... There are other limitations, but a workaround exists for most of them This page maintained by William Yu ©1999-2000