Re: How is the concept of scope implemented?

Tony wrote:


> In C++, there is many kinds of scope: global, translation unit, function,
> local (between the curly brackets within a function), class and probably
> more. How is the concept of scope implemented by a compiler for a program?


I'm not sure how other compilers do it, but here's how my own compiler
does it. First a short introduction to scoping in my language:


* There's the global scope. In this language that's the same thing as
the translation unit scope, since as of yet, there can be only one
source file. It is unnamed. It can contain variables, functions and
classes.


* There are functions. They introduce a named, opaque scope. They can
contain variables, functions, classes and local scopes.


* There are classes. They introduce a named, tansparent scope. They
can contain variables, functions and classes.


* There are local scopes. They may be named or unnamed. They are
opaque. They can contain variables, functions, classes and local
scopes.


There's more to it than that, since there are also preconditions and
postconditions in the language, which require special visibility
rules. But for simplicity, let's ignore those for now.


The main purpose of these scopes is to determine symbol visibility and
variable lifetime. In this language, a symbol may be referenced by
absolute or relative path. For example:


void f() {
        int a;
        void g() {
                int a;


                class C {
                        int a;
                }


                f.a
                .f.a


                a
                g.a
                f.g.a
                .f.g.a


                C.a
                g.C.a
                f.g.C.a
                .f.g.C.a
        }
}


The first group of references here reference the variable a directly
in function f. The second group references the variable a directly in
function g. The third group references the variable a inside class C.


In general, absolute paths (those starting with .) start with the
global scope. For relative paths, their first element (x) refers to
the most deeply nested declaration x in a scope that encloses the
reference. Each subsequent element in the path must be a direct child
of its predecessor. And they must also enclose the reference, except
possibly for the last element and any elements refering to transparent
scopes directly before the last element.


Did that make any sense? :-) It sure took a while to put this into
words.


Well, you may only reference a symbol where this symbol is visible, or
it's a compiler error. Ensuring that all references are resolved
properly will make sure that they will work in the target language. If
you're going for assembly, they'll be present in the current
stack-frame or in another stack-frame you can reach by pointers. But
this language is currently translated to C++, so... :-)


--
Michiel Helvensteijn

Return to the comp.compilers page.
Search the comp.compilers archives again.