[CMake] Functions inherit parent variables?

[Robert Dailey]

Well you're really comparing apples to oranges. C++ nested scoping rules
really have nothing to do with two separate functions sharing scoped
variables. It doesn't even really serve as a good analogy, so I can't be
100% certain what you were trying to tell me ;-)

However I appreciate your response. I really just wanted to make sure this
isn't a bug, because the way the called function inherits the calling
function's local variables is an unusual behavior for a language, at least
in my experience. So I had to think twice about it ;)

---------
Robert Dailey


On Fri, Mar 2, 2012 at 6:53 PM, Michael Hertling <mhertling at online.de>wrote:

> On 03/01/2012 06:01 PM, Robert Dailey wrote:
> > No, the print statement is not missing. In fact it prints just fine
> > (function test() is able to obtain the value for variable SOME_TEST).
>
> I meant the output "SOME_TEST: HELLO WORLD" was missing in your report.
>
> > This isn't exactly the same as C++. In C++, a function does not have
> access
> > to the calling function's local declarations. In order for the function
> to
> > get access to these, they must be passed in as parameters.
>
> There wasn't talk of functions but of the "{" and "}" tokens:
>
> #include <stdio.h>
>
> int main(void)
> {
>    int outer = 1;
>    {
>        int inner = 2;
>        printf("outer=%d, inner=%d\n",outer,inner);
>    }
>    return 0;
> }
>
> As you will see, there's access to the outer scope from the inner one.
>
> However, to be more precise, C/C++'s scoping is static, i.e. it's in
> effect at compilation time only, and - in contrast to Pascal, e.g. -
> the ISO dialects don't allow a nested definition of functions, so a
> function's scope isn't part of another function's one. Therefore, a
> called function can't see the variables of the calling function as
> their scopes aren't descendants but siblings.
>
> Interpreted languages like CMake's one often have dynamic scoping,
> i.e. an invocation of a function creates a new scope - capable to
> hold variables - and pushes it on a stack from where it is popped
> and destroyed when the function terminates. When dereferencing a
> variable, it is searched by traversing the stacked scopes from
> inner to outer until it is found. Therefore, a called function
> can see the calling function's variables since the latter's
> scope is accessible from the former's one.
>
> Maybe, it was a rather bad idea to compare C/C++'s static
> block scoping with CMake's dynamic function scoping.
> Sorry about that.
>
> Regards,
>
> Michael
>
> > On Wed, Feb 29, 2012 at 9:54 PM, Michael Hertling <mhertling at online.de
> >wrote:
> >
> >> On 03/01/2012 01:38 AM, Robert Dailey wrote:
> >>> I ran a quick test:
> >>>
> >>>
> >>> function( test )
> >>> message( "SOME_TEST: ${SOME_TEST}" )
> >>> endfunction()
> >>>
> >>> function( start )
> >>> set( SOME_TEST "HELLO WORLD" )
> >>> test()
> >>> endfunction()
> >>>
> >>> start()
> >>>
> >>>
> >>> Seems like a function has access to the calling scope's defined
> >> variables.
> >>> I thought because functions created a new scope, that excluded access
> to
> >>> variables defined in the outer scope (i.e. calling scope)
> >>>
> >>> Can someone explain?
> >>
> >> The line "SOME_TEST: HELLO WORLD" is missing, I guess?
> >>
> >> As usual with scoping mechanisms, there is access to the outer scope
> >> from within the inner scope: Read access via ordinary dereferencing
> >> and write access via PARENT_SCOPE. It's quite the same as in C/C++
> >> with the { and } tokens; see also the C++ "::" operator.
> >>
> >> Regards,
> >>
> >> Michael
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120302/fa0c2c23/attachment.htm>