Has PB a ByRef like VisualBasic?

[FromVbToPb]

Hallo, i am new here and want check out if i can replace me old VB6 codes to PB and switch maybe my main coder language to PB.
So i am new in PB and only working with a Demo version for now. Forgive if the question is maybe boring, and forgive bad english, it is not me main language.

A short question at the beginning

I searched a ByRef Option for PB Procedure parameters. Is there non or i have not found it jet. (i read now texts for days to write a simple code translator for VB6 to PB. I had to translate step be step 100'000 code lines and more .......)

(For People don't know VB, ByRef means a parameter in a procedure given by-reference (not by-value and not by-pointer), so inside changes of the variable is visible outside and given pack to the caller)

Example, i search a way to change ByVal to ByRef, without the need of changing anything else then the ByRef option, not code inside the procedure and not calling code should be need to be changed. (So not replace it whit pointers, pointer parameters are not acting the same like by-reference parameters, like VB coder know).

;In VB Pseudo-Code!
Function StringOp(ByVal Par1$, ByVal Par2$) As String
Par1$ = Par1$ & Par2$
Par2$ = Par2$ & Par1$
Return Par2$
End Function

;Only change is the first ByRef
Function StringOp(ByRef Par1$, ByVal Par2$) As String
Par1$ = Par1$ & Par2$
Par2$ = Par2$ & Par1$
Return Par2$
End Function

C$ = StringOp(A$, B$)

Has PB really no ByRef for standard Variables like String and Long, or i had not see it jet? (with option "Array" Arrays are giving by reference in the procedure, like it should be.)

Tanks for any info.

[srod]

Hi,

except for arrays, lists, maps and the like, parameters are passed by value; there is no BYREF keyword (and no equivalent!)

If you want to pass a parameter 'by reference' then we use simple pointers and pass the address of the variable in question.

Code: Select all

Procedure byRefTest(*param.INTEGER)
  ;Let us change the parameters value to 10 by dereferencing the address.
    *param\i = 10
EndProcedure

;Call the procedure passing the address of the variable x.
  x = 0  ;x defaults to an integer parameter.
  byRefTest(@x)  ;@ is the 'address of' operator.
  
;Examine the value of x (should be 10!)
  Debug x

If you've never used pointers before then do not be put off by them, they are very simple - especially where PB is concerned. Pointers to strings need a little care.

[spikey]

Also check out the Shared keyword in the online help, its not identical but is a very handy thing to know about.

[FromVbToPb]

Hooo! This is very very very painful!!!

I had to translate a LOOOOOT of code, and all codes are precisely intestinally in every singe parameter ByVal or ByRef declared. It is unthinkable to correct every singe procedure and put pointer handlings it.
I don't like pointers at all for simple string handlings, even if i missed it too in VB sometimes. And i use in my codes ByRef very often once for speed up of string transfer and for returning value. I missed in VB efen a ByRefFix or ByRefConst to explicate declare ByRef and forbid modifications in the same time, so to be able to use explicate ByRef only for speed and not for returning proposes.

To use shared in a code base on many hundrets of Procedures and many modules is no option too. (This code base works as a function enhancement beside the small given in VB and is in use now for many years and permanently optimized. It is al lot of code an a lot of names!)

I have now check out the syntax and Code differences between VB and PB and see now the strengths and weaknesses of both compilers step by step better. Some divergences are completely incompatible and need a hand recoding. But the miss of ByRef is be fare one of the most painful one!

Together whit other weaknesses, i had do made the sad desiccant that i can not switch to PB and will still the old fashion VB6 (because i don't want to switch to the VB.net monster) and i can only hope that once someone develops a basic dialect wit more compatibility to VB (j wait now for many years.........).

I reality like PB and would like to switch. PB has a very goot base and i like a lot of things more then how VB handles it, and if some weaknesses are fixed it maybe becomes the attention it deserves in my opinion. I have not heard much of PB and joust stumble over it. But some weaknesses are simply to painful for professional or semi professional development.


???
It there any chance that the PB developers implement a ByRef Option?? I don't care if it is slow, so long its working. A simple &Parameter or @Parameter would be ok if no ByRef keyword should be used. Is the implementation of ByRef so difficult that it can not be done? It would be a big benefit, and it is in my opinion for a basic language not a “like to have” but a ”must have”.

[srod]

Can't agree that BYREF is a must have in any shape or form; especially when we have pointers which can easily do the same thing (strings aside).

Converting 100000 lines of code from one language to another is never going to be easy regardless of syntax and whether BYREF is supported or not. If you are looking to switch from VB 6 and convert your old 'legacy code' then, well, you have your work cut out no matter how you approach it.

You could always take a look at RealBasic. That has a similar syntax to VB and the last time I looked they seemed to offer some kind of VB to RB converter. Might be worth a shot.

[Thorium]

I too came from VB6 and i am not missing it a bit.
We dont need ByRef in PB because we have pointers and after i got used to them i like them more than VB's ByRef.

I wouldnt convert a code base to PB. It's way to much work and you need to test all the code. I would build a new code base and convert code the moment i need it. So slowly building a new PB code base. If you have a big project you want to convert to PB, i probably wouldnt do it. Maintain it in VB6 and start a new one in PB. Such convertions are no fun to do and a lot of work. And you dont win a lot by doing it.

[FromVbToPb]

Hmm. You set it your self: "Pointers to strings need a little care.", the little care is extra work.

Because ByVal ByRef and ByPinter it not the same, to use ByPinter for ByRef proposes is a work around and not a clean solution.
There is even a reason for using ByRef for Arrays and Lists, String is a special array, thats why "Pointers to strings need a little care."
If no ByRef for Numeric Variables is supported, that is ok for me, i can do this with pointers without complaining (that much , but it hurts by strings.

Even if me translation once is don, i still would like to have a ByRef Option. In real life, if you have a Procedure don (not concerning about translations) and you make the decision to change the handling of a parameter later, you only change a option, and thats it. Chaining ByVal to ByPoint don't work that easy, you have to do extra work you don't need with ByRef, at least for strings.

But maybe i get in wrong because i am learning PB now only for a few days, i am not unwilling to change habits if it make sense.

Thorium:
It is what i intend to do. I create a translator witch makes the raw an dirty confession, and then i step by step transcode stuff manually, and i am prepared for a lot of work, if i have then a good coding language and don't end up in a dead end like with VB6 again. Im coding now for yeas (only VB6) and i am not so naive to think the conversion is easy and quick. And i don't blame PB for incompatibility in PB makes it better then VB. But all that work has to have a reason and the Result then has to work for a other decade or two I have even Qbasic codes in me code base witch still works fine, translated once in VB6 (easier then to PB), i programmed it as teenager in school time.


Tanks for you very quick and nice answers!!!

Tanks for the tip of RealBasic, i will check this too. (I check in once many yeas ago, before it was stronger, and then forget it.)

[skywalk]

PowerBasic is closer in syntax to VB6 and might still have ByRef keyword.
That said, PureBasic's syntax is more elegant.
However, unlike PowerBasic, PureBasic only allows 1 native string type per compilation.
Ascii or Unicode.
To use both types in your code and inside gadgets, you pick 1 and build the other with memory functions, Peek/Poke.

[Little John]

Converting 100000 lines of code from one language to another is never going to be easy regardless of syntax and whether BYREF is supported or not. If you are looking to switch from VB 6 and convert your old 'legacy code' then, well, you have your work cut out no matter how you approach it.

My thoughts exactly! That's the bottom line here.

Regards, Little John

[BorisTheOld]

PowerBasic is closer in syntax to VB6 and might still have ByRef keyword.
That said, PureBasic's syntax is more elegant.

Not more elegant, just different and a little quirky.

We've used VB, PowerBasic, and many other programming languages - they all have features that make them a little different from each other. The trick is to use the language to suit one's programming style.

@FromVbToPb

We like to make our code as self-documenting as possible: highly structured, rigid naming rules, and no "tricky" code. Unfortunately, PB requires some "tricky" code to implement a ByRef feature. It also requires some "tricky" code to pass structures to a procedure.

By "tricky" code, I mean code that is not immediately obvious to a non-expert programmer.

Languages with a built-in ByRef feature, such as PowerBasic, might use the following syntax:

Code: Select all

Sub MyProc(ByRef MyVar As String)
  MyVar = "Hello"
End Sub

Dim StringVar As String

MyProc(StringVar)

Whereas PB requires the use of a fake structure combined with pointers to accomplish the same thing:

Code: Select all

Procedure MyProc(*MyVar.String)
  *MyVar\S = "Hello"
EndProcedure

Define StringVar.String

MyProc(@StringVar)

We use macros to do simple text substitutions so that we can make the code a little more readable:

Code: Select all

Macro ByRef(Name, Type)
  *Name.Type
EndMacro

Macro sRef(Name)
  *Name\s
EndMacro

Macro sVal(Name)
  Name\s
EndMacro

Macro Ref(Name)
  @Name
EndMacro

Procedure MyProc(ByRef(MyVar, String))
  sRef(MyVar) = "World"
EndProcedure

Define StringVar.String

sVal(StringVar) = "Hello"

Debug sVal(StringVar)

MyProc(Ref(StringVar))

Debug sVal(StringVar)

This is just a very simple example. We use more complex constructs to implement ByRef for all data types, and to implement OOP classes.

[ts-soft]

Whereas PB requires the use of a fake structure combined with pointers to accomplish the same thing:

Code: Select all

Procedure MyProc(*MyVar.String)
  *MyVar\S = "Hello"
EndProcedure

Define StringVar.S

MyProc(@StringVar)

This can't work for strings, use this:

Code: Select all

Procedure MyProc(*MyVar.String)
  *MyVar\s = "Hello"
EndProcedure

Define StringVar.String

MyProc(StringVar)

Debug StringVar\s

[BorisTheOld]

I typed the example between beers and forgot the exact syntax.

Anyway, the changed example works.

The point of my tome is that the confusing, ASM-like, syntax can be modified to give the code a more BASIC look. This approach is particularly useful when passing structures to a procedure.

Unlike lists, maps, and arrays, structures must use pointers in the called procedure, even though they are all passed by reference. So to get around this PB quirk we use macros to disguise the pointers and make the code more readable.

[skywalk]

PowerBasic is closer in syntax to VB6 and might still have ByRef keyword.
That said, PureBasic's syntax is more elegant.

Not more elegant, just different and a little quirky.

Yes, beauty is in the eyes of the beholder.
There is no argument PureBasic is different. But after reviewing the alternatives for 50-75k lines of VB6 code, I almost vomited when I compared the syntax of VB.Net or PowerBasic to PureBasic. Sure, there are shortcomings, but they are slowly disappearing. Or I design them out.

Whereas PB requires the use of a fake structure combined with pointers to accomplish the same thing:

I don't agree with this terminology. PB uses pointers and structures. It is direct. What is fake?
Took a while to catch on to this coming from VB6, but it is more flexible and preferred.

[BorisTheOld]

Whereas PB requires the use of a fake structure combined with pointers to accomplish the same thing:

I don't agree with this terminology. PB uses pointers and structures. It is direct. What is fake?

Fake in the sense that Strings are Strings, not Structures. PB's approach seems to be a little quirky, as is it's need for pointers when passing a structure to a procedure.

But this is just the way the language works. All I'm suggesting is a way to reduce the clutter.

Part of the problem for new users is that the PB reference manual isn't rigorous in its explanations. We've spent a lot of time analyzing various language features and filling in the gaps in the reference manual. Things aren't always what they seem. Not that the manual is wrong. It's just that it often doesn't tell the whole story.

[srod]

You ever tried reading the VB user manual? I'd try it if I had a spare decade or two!

I think the PB manual gives a great compromise between functionality and information overload. It gets you up and running and from there you choose your own path; whether that involves more reading or rolling your sleeves up and throwing down some code. No, too many language guides simply throw too much unnecessary information your way. Personally I love the PB user manual.

Afraid I am from the school of wanting to throw some code down as quickly as possible. I wait until I screw my system up completely before actually asking what I did wrong?

Works for me.