[Gambas-user] Correct strategy for VB static var conversion to Gambas?

[Benoît Minisini]

Le 30/05/2021 à 18:55, John Anderson a écrit :
> 
> Thanks, I understand your concern...and it is not my intention that my 
> needs require Gamabs to break anything it currently does well.
> 
> Let me explain the situation more.  Warning - this is long, but only way 
> I know of to explain.  If your time is short please just skip the rest. 
> The following ONLY applies to VB conversion project.
> 
> Well, in order to implement the equivalent of a "Static" var in a 
> function, and since a lot of our functions use common names as 
> "mystaticvar" in lots of functions: the only way I know of is to make a 
> separate module for each function.
> 
> So we go from a dozen or so module files on VB side to over a 1000 
> modules on Gambas side...just to deal with the fact Gambas doesn't 
> support static var type define inside a function.  And we don't even 
> know if Gambas scales that way.

It should work, but it's not a good idea per se. To implement static 
variable workaround, you don't have to add any module. You just have to 
declare these static variables on the top of the module. So if you have 
for example 20 functions with static variables in a module, you have to 
move 20 declaration on the top of the module, and prefix the name of the 
static variable with the name of its function to avoid name clash (which 
Gambas would do internally if he had to support function static variables).

Do you know 'gb.eval' and Highlight.Analyze()?

It takes a line of code, analyzes it, and return a list of token names 
and types.

It allows you to make automatic code conversion easily and reliably.

 > [...]
> 
> Beniot keeps pointing out to not use Structs except for C calls, so that 
> tells me there is something to really worry about there, and I need to 
> do more testing.  Our structs can be a flat 1440 X 1280 32 bit image 
> frame data along with several hundred INT32 and INT64, lots of 64 bit 
> "Doubles" (VB / C term), fixed length strings, byte arrays etc.  And 
> then those structs are contained arrays themselves.  So we might be 
> passing around a memory pointer to many 10's or 100 MB of data at a time 
> that has to work with Gambas  and C.  I know Gambas would rather have 
> Structs be setup  in it's own class object format, but we need 
> everything to be portable to C with a single pointer.  Maybe these big 
> structs will slow down Gambas too much.

The difference between normal arrays and embedded arrays (which use the 
VB syntax), is explained here: http://gambaswiki.org/edit/lang/arraydecl

They are not necessarily slower. They are just not Gambas objects, and 
are allocated inside the class or module they are declared in. Their 
size is consequently limited by the maximum size of a Gambas object or 
class. Which should be 4GB, so it should be enough.

As soon as you know the difference, they is no problem in using them for 
porting a project.

But it's better to use normal arrays for new code, and keep embedded 
arrays when dealing with external C code.

 > [...]
> 
> Assuming that big C-friendly Structs could be used in Gambas (If not we 
> couldn't eevn use Gambas):
> 
> What would be really cool is a gb.VBConversion component that could (and 
> we'd happily pay for this on a commercial project if it saves testing 
> time and errors):

I have my company now (actually I -am- a company, I am "self employed").

What is your company, and what is its country? I can make invoices 
inside European Union I think (must check). Outside of, I don't know how 
it works: the doomed french taxation system that nobody can understand 
completely, you know...

- if you agree that all the changes that will be part of Gambas are free 
software of course.

Now I answer your point, but don't hesitate to write a more detailed 
requirement specifications so that I can give you a delay.

> 
> 1. Support "static" var.  Gamabas already let's you Dim a var inside a 
> function, a Static seems reasonable.  You don't have to use it if you 
> don't want to.

As I told in a previous mail, it's possible to implement, except that 
"static" becomes ambiguous inside a class method (you will say that you 
don't care, but I have to).

> 
> 2.  Support "End Function, End Sub" etc without complaining.

Does it complain? I thought you can use 'End Function' or 'End Sub' 
instead of 'End' indifferently.

> Gambas can 
> also know that "Type" is a "Struct" and so on.  Those are minor little 
> things I know.  Just saving some steps will not hurt anything.

If you understand how to use Highlight.Analyze(), it's rather simple to 
do all the substitutions.

> 
> 3.  "Double" is 8 bytes in VB and C world, it would seem a small thing 
> to have Gambas know that a "Double" is same as "gb.Float" type also. 
> It's confusing reading Gambas code because in C world a "Float" is 4 
> bytes - which we never ever use anyway, and we never once used a VB Single.

Same remark.

> 
> 4.  With this gb.VBConversion, arrays could be delimited with "()" 
> instead of just "[]".  Why not make life easier for VB folks to get 
> drawn into Gambas World.

I'm afraid it's not possible. "()" is already an operator in Gambas, 
used for function calls.

An automatic translator may do the substitution, but it's a complex task 
to make the difference between array access and function access. I don't 
even know how VB managed that, but I guess it's just one horror amongs 
many others.

> 
> 5.  If possible, some way to define local or static arrays inside a 
> function.  Again, mybe not pretty, but it's what I have to work with on 
> a conversion - in many hundreds of functions.

As soon as you don't use embedded arrays. They cannot be local. But they 
can be static (as static = module/class global).

Regards,

-- 
Benoît Minisini