No. But you could involve variables with ```STATIC``` storage class. In fact you could make the whole subprogram ```STATIC```.
The problem is you would have to check if an INTEGER-class variable is zero for first run, or if a string is the "" empty string. For a SINGLE, DOUBLE or _FLOAT it's better to allocate a related INTEGER "flag" to go along with it so it's easier to check to see if it's zero. However the programmer might need zero as a proper value, so have to be prepared for that. All this is for doing the "start-up" code, only to be done the first time the subprogram is executed inside the application created by QB64.
The second example from here illustrates it well:
https://qb64phoenix.com/qb64wiki/index.php/SHARED
Another way is to use global variables but I don't recommend it anymore.
Trying to write a subprogram that has, say three parameters, will have to be called with three parameters always in QB64. Will have to be called with the same order of types as in the definition of the subprogram. But as I've said, you could create a parameter that is a "flag" that sets other "default values" into action inside the subprogram. This is in case there are a large number of values to activate and you need to do that rarely. Looking from the outside, however, all parameters have to be provided for a subprogram an user writes. If this is too hard for your library conversion, you could employ a preprocessor although it's clunky. It could be simple search and replacement that provides the "missing" parameters for a call to a subprogram. But in QB64 you could define other subprograms which are "macros" that simply forward to another subprogram that needs many parameters.
Take for example:
and so forth.
The problem is you would have to check if an INTEGER-class variable is zero for first run, or if a string is the "" empty string. For a SINGLE, DOUBLE or _FLOAT it's better to allocate a related INTEGER "flag" to go along with it so it's easier to check to see if it's zero. However the programmer might need zero as a proper value, so have to be prepared for that. All this is for doing the "start-up" code, only to be done the first time the subprogram is executed inside the application created by QB64.
The second example from here illustrates it well:
https://qb64phoenix.com/qb64wiki/index.php/SHARED
Another way is to use global variables but I don't recommend it anymore.
Trying to write a subprogram that has, say three parameters, will have to be called with three parameters always in QB64. Will have to be called with the same order of types as in the definition of the subprogram. But as I've said, you could create a parameter that is a "flag" that sets other "default values" into action inside the subprogram. This is in case there are a large number of values to activate and you need to do that rarely. Looking from the outside, however, all parameters have to be provided for a subprogram an user writes. If this is too hard for your library conversion, you could employ a preprocessor although it's clunky. It could be simple search and replacement that provides the "missing" parameters for a call to a subprogram. But in QB64 you could define other subprograms which are "macros" that simply forward to another subprogram that needs many parameters.
Take for example:
Code: (Select All)
SUB Thismany (a%, b&, c%, d$, e#)
:
END SUB
SUB TMFooString (a$)
Thismany 0, 0, 0, a$, 1.0
END SUB
SUB TMSetDouble (n#)
Thismany 0, 0, 0, "", n#
END SUBand so forth.