No announcement yet.

SUBs local variables

  • Filter
  • Time
  • Show
Clear All
new posts

  • Tom Hanlin
    Variables in Subs and Functions are local by default. When you specify SHARED
    at the module level, this overrides the local default for the specified variable.
    For better or worse, this is long-time BASIC behavior, and PowerBASIC has to do it
    this way to avoid breaking many large existing programs.

    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:

  • Sebastian Groeneveld
    Hmm, even when LOCAL is put in the SUB's header, it will not really
    guarantee the variables inside to be LOCAL (well, not more than default).
    So what is the purpose of using the keyword on the header line?

    And if the online help states that:
    The default type of variables within the procedure may be set to
    LOCAL, SHARED, or STATIC by including one of these keywords in the
    procedure header (variables in SUBs are LOCAL by default).

    I would expect that adding LOCAL to the SUB's header would implicitly
    add LOCAL to each DIM statement that has no other scope specifier...
    At least, that would make sense

    Sebastian Groeneveld
    mailto:[email protected][email protected]</A>

    Leave a comment:

  • Davide Vecchi
    started a topic SUBs local variables

    SUBs local variables

    this is a follow-up of one of the topics contained in a previous thread ( ).

    lance had answered:

    1. the duplicate variable error will not occur if you include the word local in the dim statement in the sub... otherwise the compiler assumes that you are just redeclaring the same variable... ie:

    $dim all
    dim myvar as shared integer
    myvar = 1
    call mysub()
    print myvar
    sub mysub()
            dim myvar as local integer
            myvar = -1
    end sub
    this is right. myvar is dimmed as shared at module level, so it exists inside the sub too, then inside the sub a local or another scope descriptor must be needed in order to create another var with the same name but with different scope.
    however, if i don' t use local, the duplicate name definition error is not what happens, it is what should happen imo. what happens is that the shared attribute seems to be given to the var. anyway it becomes the same var of module level. i think the original post was asking about this.

    even though this is not my problem, this seems me incompatible with reference guide pag. 267 stating that
    "the default variable type within the sub body can be specified by including a type class keyword (static, shared, or local) at the end of the header; the default, if no keyword is included, is local".
    so i was expecting not to be necessary to repeat local in the dims inside the sub, since it should be the default.

    but it' s just matter of interpretation and of manuals printing, it can' t be a real problem for anybody, except maybe for some initial confusion. however just type local in the dims (it is more readable too) and go. probably this is not even necessary if you explicitly put local in the sub header.

    the new var will be local to the sub and will hide the shared one with the same name dimmed at module level. as long as the execution stays in the sub, myvar is the one dimmed in the sub, not the one dimmed as shared at module level.

    so far it' s all clear, now my question comes. i always found not so easy having a global and complete vision on all the aspects of vars scopes, so i' m probably missing some of them, but i can' t realize which one. i hope somebody can help me in figuring this out since i believe scopes separation is a very important way to easy maintainance.

    if i don' t use local in the sub, the compiler assumes that i' m just redeclaring the same variable, but i should not be allowed to dim twice the same var. if i can, then it' s not the same var. but it is.

    if you redeclare the same var within a scope where a var with the same name already exists, you can expect a healthy 466 duplicate name definition error, and you' ll get it. dimming the same scalar var twice should be a big no-no in pb/dos, afaik.

    the only way i' d expect this sub' s var to be [mis?]taken for the one at module level, is if i write
     dim myvar as [b] shared [b] integer
    in the sub.

    and if i do so, it works exactely like it works if i don' t put anything, as if the default scope for the sub' s dim was shared .

    hey, this is just for understanding, just to see if i' m sleeping on something hidden (from me).
    i got no scopes issues here. if you want local vars in the sub, just dim them as local (as dim entry clearly states in the docs).