Well, for me it's the same as unsigned long and quad, they wrote it will not be implemented. Still i express my opinion on the matter. Opinions can change, even Freds and Freaks. ^^luis wrote: So... I think all this is a waste of energy. Just pointing this out, not telling to anyone he should stop
Structural Compiler-Modernizing instead of a ton of new fea.
Re: Structural Compiler-Modernizing instead of a ton of new
Re: Structural Compiler-Modernizing instead of a ton of new
Simple example from Today.
I want to make a Procedure that gives me 3 Parameters back.
In PowerBasic i can choose with any Procedure-Parameter wether its BYVAL or its BYREF.
Surprise ... in Purebasic there is nothing like that.
I would have to define structure and possibly use and return a Structure as Procedure-Parameter.
Which is simply more complicated then just say "this Parameter is BYREF".
Then in PowerBasic i have DWORD as unsigned INT32, and LONG as Signed INT32.
Surprise, PureBasic has no unsigned 32-bit Datatype.
The PureBasic Book says "This may lead to rounding Errors". I don't know.
Actually i did not really have noticed problems, anyway - i can not transfer several programs 1:1 if the datatype is missing.
To have all needed BASIC Datatypes in a Compiler ist just an advantage. Especially if you are going to interface or rewrite programs from other sources.
From just comparing directly the compiler - NOT the multiple features - but simply the compiler and the ease and possibilities, actually I'll still prefer PowerBasic for x32 and continue to use PureBasic for any x64.
I want to make a Procedure that gives me 3 Parameters back.
In PowerBasic i can choose with any Procedure-Parameter wether its BYVAL or its BYREF.
Surprise ... in Purebasic there is nothing like that.
I would have to define structure and possibly use and return a Structure as Procedure-Parameter.
Which is simply more complicated then just say "this Parameter is BYREF".
Then in PowerBasic i have DWORD as unsigned INT32, and LONG as Signed INT32.
Surprise, PureBasic has no unsigned 32-bit Datatype.
The PureBasic Book says "This may lead to rounding Errors". I don't know.
Actually i did not really have noticed problems, anyway - i can not transfer several programs 1:1 if the datatype is missing.
To have all needed BASIC Datatypes in a Compiler ist just an advantage. Especially if you are going to interface or rewrite programs from other sources.
From just comparing directly the compiler - NOT the multiple features - but simply the compiler and the ease and possibilities, actually I'll still prefer PowerBasic for x32 and continue to use PureBasic for any x64.
Re: Structural Compiler-Modernizing instead of a ton of new
PureBasic Syntax:TheoGott wrote:Simple example from Today.
I want to make a Procedure that gives me 3 Parameters back.
In PowerBasic i can choose with any Procedure-Parameter wether its BYVAL or its BYREF.
Surprise ... in Purebasic there is nothing like that.
Code: Select all
Procedure Return3Values(*value1.Integer,*value2.Integer,*value3.Integer)
If *value1 : *value1\i = 1 : EndIf
If *value2 : *value2\i = 2 : EndIf
If *value3 : *value3\i = 3 : EndIf
EndProcedure
Define a,b,c
Return3Values(@a, @b, @c)
Debug a
Debug b
Debug c
Did you try Xojo? It is for Windows, Linux, Mac, Web-Apps, and soon iOS (see video). Has VB-like syntax, OOP etc.TheoGott wrote:Then in PowerBasic i have DWORD as unsigned INT32, and LONG as Signed INT32.
Surprise, PureBasic has no unsigned 32-bit Datatype.
The PureBasic Book says "This may lead to rounding Errors". I don't know.
Actually i did not really have noticed problems, anyway - i can not transfer several programs 1:1 if the datatype is missing.
To have all needed BASIC Datatypes in a Compiler ist just an advantage. Especially if you are going to interface or rewrite programs from other sources.
From just comparing directly the compiler - NOT the multiple features - but simply the compiler and the ease and possibilities, actually I'll still prefer PowerBasic for x32 and continue to use PureBasic for any x64.
Re: Structural Compiler-Modernizing instead of a ton of new
xojo was previously RealBasic.
If you interpret adoption rates by web hits, it has a way to go compared to these others:
xojo
purebasic
powerbasic
freebasic
If you interpret adoption rates by web hits, it has a way to go compared to these others:
xojo
purebasic
powerbasic
freebasic
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Structural Compiler-Modernizing instead of a ton of new
Doh! I kept trying realbasic.com, so I didn't bother including it.
Danilo corrected me --> realsoftware.com
Either way, xojo is trying mightily to shed basic from its namesake. But that was not the core of their earlier problems.

Danilo corrected me --> realsoftware.com
Either way, xojo is trying mightily to shed basic from its namesake. But that was not the core of their earlier problems.
The nice thing about standards is there are so many to choose from. ~ Andrew Tanenbaum
Re: Structural Compiler-Modernizing instead of a ton of new
It looks not only ugly and complicated, it is also very error prone if a,b,c have values different from 0 beforeDanilo wrote:PureBasic Syntax:Code: Select all
Procedure Return3Values(*value1.Integer,*value2.Integer,*value3.Integer) If *value1 : *value1\i = 1 : EndIf If *value2 : *value2\i = 2 : EndIf If *value3 : *value3\i = 3 : EndIf EndProcedure Define a,b,c Return3Values(@a, @b, @c) Debug a Debug b Debug c
and you forget an '@' at the procedure call.
ByRef with future PB:
Code: Select all
Procedure Return3Values(ByRef value1, ByRef value2, ByRef value3)
value1 = 1
value2 = 2
value3 = 3
EndProcedure
Define a,b,c
Return3Values(a, b, c)
Debug a
Debug b
Debug c
Code: Select all
Procedure Return3Values(@value1.i, @value2.i, @value3.i)
value1 = 1
value2 = 2
value3 = 3
EndProcedure
Define a,b,c
Return3Values(a, b, c)
Debug a
Debug b
Debug c
Re: Structural Compiler-Modernizing instead of a ton of new
I agree with this, although the @ sign (or a ByRef modifier in the call) is a great indicator to the author that the values could be modified by the called function. I would prefer to leave these in for the call, and get a syntax error if one (the method chosen by Fred) is not used.Danilo wrote:It looks not only ugly and complicated, it is also very error prone if a,b,c have values different from 0 before
and you forget an '@' at the procedure call.
+1Danilo wrote:Looks like a good and useful request for the language.
Re: Structural Compiler-Modernizing instead of a ton of new
Yes. Today i tried again to convert some PowerBasic Functions into PureBasic.
Really missing the BYREF. If you have it you don't know how you feel if you fo not have it. If somebody is going to add new features, think of a "BYCOPY" also, as the third Option PowerBasic has (BYVAL ... BYREF ... BYCOPY).
BYVAL will do essentially a new (hidden) local variable of that type and assign it that value of the given Pointer. For this reason the original value is SAFE.
BYREF would be good because actually its not easy to get multiple results from structures out of a Procedure, without using an Array. The actual system with Procedure-Parameters "ARRAY","MAP" and "LIST" looks like some sort of "Help construct".
How about this Syntax for BYREF (IN/OUT):
which would be easier to parse for the compiler then
which would be like the actual syntax and do just the same.
and of course BYVAL (IN):
"Protected PA.Point"
and just copy the Memory from the original structure inside it
Anytime PA is used inside the the Procedure, this one is used.
At the end of the Procedure the thing is deleted like all local Vars.
Using this system, you can transfer structures of all type in an out of a Procedure.
This will make several things a bit more easy then its currently. And it will help people to convert PowerBasic x32 to PureBasic x64.
If i can specify BYREF and BYVAL explicitly, like in PowerBasic, then i know exactly what goes where.
PS: Thanks for the Hint with the @ - thats just what i need now to get forward.
About RealBasic, i do not think its what i need, it looks to bloated for me.
The only much more expensive Alternative would be possibly WinDev.
PowerBasic is Ok for me just it is not able to compile x64 DLL's and EXE's.
Thats what i use PureBasic for.
Really missing the BYREF. If you have it you don't know how you feel if you fo not have it. If somebody is going to add new features, think of a "BYCOPY" also, as the third Option PowerBasic has (BYVAL ... BYREF ... BYCOPY).
BYVAL will do essentially a new (hidden) local variable of that type and assign it that value of the given Pointer. For this reason the original value is SAFE.
BYREF would be good because actually its not easy to get multiple results from structures out of a Procedure, without using an Array. The actual system with Procedure-Parameters "ARRAY","MAP" and "LIST" looks like some sort of "Help construct".
How about this Syntax for BYREF (IN/OUT):
Code: Select all
Procedure Test(BYREF.Point PA,BYREF.Rect RA)
Code: Select all
Procedure Test(BYREF PA.Point,BYREF RA.Rect)
and of course BYVAL (IN):
The compiler will internally/transparent define an new, internalProcedure Test(BYVAL.Point PA,BYVAL.Rect RA)
"Protected PA.Point"
and just copy the Memory from the original structure inside it
Anytime PA is used inside the the Procedure, this one is used.
At the end of the Procedure the thing is deleted like all local Vars.
Using this system, you can transfer structures of all type in an out of a Procedure.
This will make several things a bit more easy then its currently. And it will help people to convert PowerBasic x32 to PureBasic x64.
If i can specify BYREF and BYVAL explicitly, like in PowerBasic, then i know exactly what goes where.
PS: Thanks for the Hint with the @ - thats just what i need now to get forward.
About RealBasic, i do not think its what i need, it looks to bloated for me.
The only much more expensive Alternative would be possibly WinDev.
PowerBasic is Ok for me just it is not able to compile x64 DLL's and EXE's.
Thats what i use PureBasic for.