New compilers very soon from PowerBASIC.

[hutch--]

Here is some REAL LINE NUMBERED BASIC.

Code Select Expand


' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

FUNCTION PBmain as LONG

    0007:DIM VAR AS LONG
    0006:VAR = 0
    0005:VAR = VAR + 1
    0004:IF VAR < 10 GOTO 0005
    0003:? FORMAT$(VAR)
    0002:VAR = VAR - 1
    0001:IF VAR > 0 GOTO 0002
    0000:? FORMAT$(VAR)

End FUNCTION

' ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤


Still blows out to 7680 bytes.  :bg

[hutch--]

The true issues with PB are:
- no support for an object format. You're stuck in the little PB world.
- you have to buy 2 compilers to get the full functionality.

The first was a valid complaint but for no longer with the two coming compilers. They use a format called SLL (static link library) but it is not the same as OMF or COFF as neither of them could handle the internals of a basic compiler and other compilers could not handle the content. There is a reason for a separate console compiler as it is tuned to perform that task with functionality that the GUI version does not contain or use. I regularly design algos in the console compiler and use the results in either. It just happens to be that development and testing from the console is faster than building a user interface just to test out results.

The other very low level capacity that the pre-release info states is the optional removal of unused text based source code which reduces the output size down to containing only code that is called and used in the application. There is an option to create procedures with no stack frame called FASTPROC which will solve on of the few problems the compilers had with very short leaf procedures.

When they are released I will get my hands on them at some stage and post some results here.

[José Roca]

- you have to buy 2 compilers to get the full functionality.

You don't. Using the Windows API, you can develop console applications with the GUI compiler and GUI applications with the console compiler. But the console compiler makes the dirty work for you and, as hutch, I use it for developing and testing non GUI related code.

Regarding atatic libs, the new compilers are so fast that I prefer to use include files: they  have some advantages, such allowing conditional compilation. I guess that static libraries will be mainly used by third party programmers wanting to hide his code.

[japheth]

You don't. Using the Windows API, you can develop console applications with the GUI compiler and GUI applications with the console compiler.

I'm aware of the Win32 API and AllocConsole() or CreateWindowEx(), and if needed you can also patch the flag in the PE header. The problem is not on the technical side.

Regarding atatic libs, the new compilers are so fast that I prefer to use include files: they  have some advantages, such allowing conditional compilation. I guess that static libraries will be mainly used by third party programmers wanting to hide his code.

IMO you guess wrong.

[José Roca]

IMO you guess wrong

I did mean among PB users. With other languages they are also used to get shorter compile times.

[japheth]

I did mean among PB users. With other languages they are also used to get shorter compile times.

Ok, I see. However, IMO there are more advantages than just "shorter compile times" when a compiler does support an object format. The generic question in this regard is: What are linkers good for? But since this discussion probably has been led a few thousands times already, I'll stop here.

[hutch--]

Its a case of market targetting, there is a demand for a console specific basic compiler where you can write code from LINE NUMBERED BASIC to pure API code and assembler and most flavours inbetween. Now while its no big deal to write console specific API code or call functions from MSVCRT, not everyone wants to write that type of code and this is what the console compiler caters for. It cannot build a DLL, that is the situation where you use the wider capacity GUI compiler. It just happes to be that the GUI version does not contain the console specific runtime functions.

Libraries are a matter of taste, I have been writing and using them for over 20 years so I will probably build a library of PB functions but the dead code removal method removes the necessity of having to do that when you have large collections of related code. Where with the earlier versions you copied out the code you wanted which can be a pain with nested dependencies, the dead code removal technique allows you to bundle large numbers of functions in a single source file which you can then include as a complete file as the compiler will not insert code from unused functions.

With about the same coding effort as including libraries, you do something like this,

Code Select Expand


#include "myio.bas"
#include "mymathsfunctions.bas"
#include "myMSVCRT.bas"


With this any code you call from the include files is added to the final binary and the rest in those files is extracted out of the final build. A version or so ago PowerBASIC no longer requires a prototype for its local functions so you don't have to add matching include files to source files. Prototypes are required for external functions like API calls and these can be tuned to how you want to call the API. PB has multiple techniques for passing arguments to functions, the normal by value, it will pass arguments by reference and has yet another trick where you can pass a dynamic string by copy when the API prototype may be written for another data type. You can also specify an over-ride of passing the argument by value.

[hutch--]

Just one favour requested, I have just had to waste the time cleaning up this mess of postings not related to this topic. I have just moved the C/C++ code to the C/C++ subforum. Please keep this mess out of here as it just makes more work for me to keep the forum readable. I will delete any further off topic postings.