[Gambas-user] Correct strategy for VB static var conversion to Gambas?
johna at starflightinc.com
Sun May 30 18:55:54 CEST 2021
On 5/29/2021 3:50 PM, Christof Thalhofer wrote:
> Am 29.05.21 um 22:09 schrieb Benoît Minisini:
>> So maybe I could allow declaring "static variables" (actually private
>> global class variables) inside functions in the future.
> That would make code even uglier. Is there any reason to do this that
> makes sense?
> Alles Gute
> Christof Thalhofer
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.
Static might not seem "pretty" to you, but you don't have to use it in
your code if you don't want to. For those of us working on an existing
conversion project: Having a way to use as much tested / working VBcode
as possible would be a big plus. Pretty? Probably not by your
standard. But easily upgrading VB6 code to Gambas is really "pretty" to
me, and a lot of VB programmers might agree. Time = Money.
Gambas is SOOO close to working with VB code as-is too. Then I get
into details and it's like I'm seeing a mirage on a desert of
not-a-lot-of-solutions. That doesn't mean Gambas isn't really great -
No, you can't always blindly do global "find and replace" on modules
that contain more than one function that have same static var names
inside function. You can wind up with functions sharing vars that are
supposed to have scope of only one function at a time, and that would be
Good point about "With Globals.mod". That can work.
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 bottom line is on Tuesday morning I have to go into the boss and
tell him Gambas looked really good initially...but it is just enough
different that the time required to convert working code is now going
to take X amount of time longer because we need to redesign the module
layout because Gambas doesn't have a way to declare a static var or
array in a function. Then he'll say "How does this make the final
product any different?"...and I'll say "It doesn't"...and then he'll say
"Screw that".... and so on. OK. That's not anyone's fault, it is what
it is. Maybe we can't use Gambas after all...if we have to redesign
from scratch it might as well go to Qt where we don't have to worry
about structs being C compatible - but Qt is going closed source these
days. Dang. There's goofy Xojo but...it has issues too.
In the industrial world we like to get everything working and vetted one
time - because on a semicon fab line it can cost millions of dollars
testing time over several months before the machine is turned loose to
run really expensive product. One wafer of devices is worth upwards for
USD$250k, and the machine must not break or stop for any reason while
processing. So we have to do a lot of in-house testing and do our best
to break code ahead of time, and build in lots of safety checks. Once
the product is in the field we try not to ever change it - because
changing a single line of code could trigger a customer on-site test
cycle again and that costs lots of time & money. Think Big and Think
Big Giverment DoD contractors, and think of all the rules that are in
place if we have to do a software update.
We don't even make an GUI installer package for customers - we send them
a whole disk image ready to setup from thumb drive or just physical
SSD. On Windows that's done with WES7 (Like Win7 but licensed across a
fleet of machines, and still current for a few more years to industrial
users), and on Linux we just send a disk all ready to go. In any case
customer plugs in disk, it boots and system runs fine on any hardware we
have in the field. No install dependencies to worry about because
we've set everything up on the disk image, and that's how it'll be for a
After the system is running, we probably won't update anything for
decades, nor would we want to. These machines are not on the 'Net, and
they have only two jobs to do: Run, and Run Faster. Forever. No matter
how the source code looks.
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):
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.
2. Support "End Function, End Sub" etc without complaining. 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.
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.
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.
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.
I know I know Gambas is not Basic, but it seems surely inspired by VB in
a lot of ways. Having a way to have it embrace legacy VB code a little
easier (with minimal re-write time) would be REALLY cool, as long as it
doesn't break any existing projects.
If you were building a new project in Gambas, or working with an
existing Gambas project: not any of what I just wrote would be required.
Over 'N Out
More information about the User