[CMake] 2D arrays

[Michael Hertling]

On 12/01/2011 08:14 PM, Robert Dailey wrote:
> PARENT_SCOPE isn't working for me. For example, I changed one line in
> array2d_begin_loop to the following:
> 
> set( _array2d_index 0 PARENT_SCOPE )
> 
> And from within array2d_advance(), I do:
> 
> message( "_array2d_index: ${_array2d_index}" )
> 
> and it prints no value. Can you try this and see if it works for you?

You say that you changed *one* line, i.e. array2d_begin_loop() is still
a macro? If so, this can't work; you need to turn array2d_begin_loop()
into a function in order to have PARENT_SCOPE show the desired effect.

Regards,

Michael

> On Thu, Dec 1, 2011 at 11:04 AM, Robert Dailey <rcdailey at gmail.com> wrote:
> 
>> On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling <mhertling at online.de>wrote:
>>
>>> On 11/30/2011 03:29 AM, Robert Dailey wrote:
>>>> I use macros so the _array2d_ variables fall through the scope of the
>>> macro
>>>> and are available in the next call to array2d_advance(). I could use
>>>> functions + properties but this solution works, I saw no need to use the
>>>> slightly more verbose global properties feature.
>>>
>>> What I've had in mind are functions and the PARENT_SCOPE option of SET().
>>>
>>
>> This is a good idea, thanks.
>>
>>
>>>> What specific helper variables are you referring to? I would most likely
>>>> use more uniquely mangled local variables instead, but I figured the
>>>> preceeding underscore in front of each was sufficient. What would you
>>>> recommend here? I'd like to avoid a cleanup() method because it seems
>>>> unnecessary. If my local variables cause conflicts later, and if name
>>>> mangling isn't the idiomatic solution, I'd like to hear whatever idea
>>> you
>>>> have (that doesn't involve cleanup() if possible).
>>>
>>> Because you must preserve some variables between multiple function/macro
>>> invocations - i.e. you can't work with local variables only - one might
>>> like to have a mean to purge these variables when their job is done in
>>> order to not pollute the current scope more than necessary. Of course,
>>> it's not absolutely indispensable, but if a set of non-local variables
>>> is used just internally by a set of related functions, it is possibly
>>> worth a thought how to not have these variables hang around later on.
>>>
>>
>> When you say "pollute the current scope", what specific issues are you
>> referring to? In my experience the biggest danger are naming conflicts,
>> which are silent issues and cause subtle symptoms that are hard to debug.
>> I've attempted to remedy this, as I said, by using name mangling... i.e.
>> prefix everything with _array2d_, which I'm pretty sure no one else will
>> ever use.
>>
>> I respect the notion of a cleanup method. I will implement one but it
>> really is optional... whether you call it or not, in practice, the
>> differences will never be noticed since the names are unique enough. Now,
>> if keeping those variables lingering around cause performance issues or
>> memory issues in CMake, then that's a different discussion.
>>
>>> What would this buy me? Typically I've avoided ARGN unless it is
>>> absolutely
>>>> necessary, but a variable in this case seems more direct. Can you
>>> explain
>>>> what benefits this has?
>>>
>>> AFAICS, you don't need the "width" parameter because it can be obtained
>>> as the length of "var_names". Thus, additionally specifying "width" is
>>> error-prone; e.g. (width,var_names)=(3,"fruit;animal") is inherently
>>> invalid.
>>>
>>> Using ARGN would allow the user to specify the array elements freely as
>>> separate arguments at the end of array2d_begin_loop(), without the need
>>> to pass them in as a semicolon-separated list in double quotes.
>>
>>
>> Oh, I didn't realize you eliminated the "width" parameter. That's actually
>> a very awesome idea. I misread your code sample and thought you still kept
>> 'width' but simply moved the list of field names to the end. I wasn't sure
>> what that would provide me :)
>>
>> Great ideas and I will implement these and re-post my code. Hopefully it
>> can be added to CMake later or become useful to other people.