My first experinece with Purebasic was "
Where is my SUB MAIN()" ?
The answer is very simple -
there is none!
Anything you write in the Editor is automatically inside the SUB MAIN (implicite).
Thats a disadvantage for somebody coming from Powerbasic, as the code just doesn't look as clean as we are used to it.
But knowing that it is like that, you just live with it.
Where is my SUB MAIN() ? Anywhere outside of a PROCEDURE.
So we start declaring our Variables. In Powerbasic we would write:
GLOBAL T01 AS LONG,T02 AS STRINGIn Purebasic it looks like this:
GLOBAL T01.l,T02.sWhich is somehow the same, less to write, maybe not as good readable, but no problem, so long you do not intermix "." and ",".
A bigger difference is with Pointers and structures.
Assume you have a structure in Powerbasic and you want to rebuilt the same structure in Purebasic.
While you would write in Powerbasic:
TYPE DATA
a(9) AS LONG
rft(10) AS STRING*256
END TYPE
LOCAL D01 AS DATAYou will be able to access your
D01.a(9)=1Which won't work like this in Purebasic.
This time you need to write more:
Structure DATA
a[10].l
rft.s{256}[11]
EndStructureAnd the first thing you see is, that while in PowerBasic all "
Ends" are
separate from
the thing they end:
END IF, END SELECT, END SUB
In
Purebasic all "ENDs" are
always together as a single word:
EndIf, EndSelect, EndProcedure
and the second thing you see, is that
you have to add one more element to the Array to get the same number of elements.
Which is just true
in structures, but not in normal Arrays. So better keep these special rules in mind.
Now take a look at the fixed lenght string in the Array and you see that the readabilty of the Purebasic code is a thing of discussion. At least for us long time Powerbasic users.
Saying that we come to pointers. In Purebasic the "
*" in a Pointer-declaration is a part of the name.
Means a variable "*POI" is another variable then "POI". They would be declared like this:
GLOBAL POI.l,*POI.iTo get a value out of a Pointer you will take PeekL() and PeekQ()
xpos=PeekL(@*Point\x)
or use constructs with Unions like this
Structure Point64
StructureUnion
p.POINT
q.q
EndStructureUnion
EndStructure
Procedure.l EventHoverGadget()
GetCursorPos_(cursor.POINT64)
hndl = WindowFromPoint_( cursor\q )For me this is far from the readablitiy of Powerbasic code, but still much better then C. But this may be a thing of behavior.
There is another thing, which is a bit different in Purebasic. As you can see,
API calls always end with an underscore, to make a difference to user procedures and Purebasic commands:
hndl = WindowFromPoint
_( cursor\q )
Like in old times
before Powerbasic 9, all Procedures must be in the
right sequence or you need to declare them first, because
there is no second Pass in the Purebasic compiler. This is a issue, which makes me wonder because they implemented a lot of things into Purebasic ... even a OGRE-based 3D Engine, but no second pass.
Also actually there are
MACROS which may be used for some sort of "OOP" but there is
no real Object-Implementation like the one in PB 9.
Actually the Points for the compiler go to Powerbasic. But i have no doubt that we'll see things like a second Pass in one of the next Updates.
Another thing i missed in Purebasic are
Procedure-LOCAL LABELS. I can define Labels in Purebasic. But they are always GLOBAL.
The fact that Labels are generally GLOBAL looks to me like a problem for complex projects.
I can make a
GOSUB LABEL. I even have a
FAKERETURN to take the return-adress from the stack when i want to jump back via a GOTO, for example in case of an error (nice Feature). But only in the "SUB MAIN" which is outside of any Procedure.
Why not inside Procedures? And then
MACROS. No LOCAL labels. No MACROTEMP. How can i use a Jump inside an MACRO, if i do not have MACROTEMP ?
Maybe there are tricks out there at least they are not explained in the help for MACROS. And thats the place where i expect these things.
There may be chances to do such things inside the underlying Assembler. But actually we are talking only from the Purebasic compiler.
About the general stability, i can say that all things i did until now (while its not much code) worked really fine.
The possibility to
just compile something for 32 and 64 bit is also a nice thing.
So after all
i can recommend PureBasic for x64 things.
The editor is well done, the language has gone through many evolutions since 2001 - while from my point of view its not yet where Powerbasic is, in terms of code-quality and Syntax-Design, and COM Objects.
But then there are other things which are great features. For example - the compiler leaves out unused PROCEDURES from the final executable. So you can load all your libraries and the code will not blow up unnecessary. You can compile residents and these will just work as internal commands.
And this is my last tip for today. I hope this will help you to get a good start into Purebasic x64. If you already use it and you have more comments for Powerbasic users, post them here.
;Resident File
; Example from the Purebasic Forums
; Save as myres.pb in \PureBasic430\Compilers Folder
; use CMD and change (CD ..) to that folder.
; type: "pbcompiler myres.pb /resident myres.res"
; copy the resulting "myres.res" into the "\Resident" Folder
; restart Purebasic
; the structures are now available in the Tools-Help
; the MACROS can be used like builtin commands.
Macro MakeLong(low, high)
low | (high<<16)
EndMacro
Macro LowWord(Value)
Value & $FFFF
EndMacro
Macro HighWord(Value)
(Value >> 16) & $FFFF
EndMacro
Structure char_array
c.c[0]
EndStructure
Structure strg_array
s.s{1}[0]
EndStructure
Structure Point64
StructureUnion
p.POINT
q.q
EndStructureUnion
EndStructure
