[CMake] 2D arrays

Robert Dailey rcdailey at gmail.com
Thu Dec 1 14:14:25 EST 2011


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?

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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20111201/70491b40/attachment-0001.htm>


More information about the CMake mailing list