[CMake] 2D arrays

[Michael Hertling]

On 12/01/2011 06:04 PM, Robert Dailey 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.

Some remarks w.r.t. your name mangling:

- In array2d_advance(), you are using variables "offset", "_index"
  or "_size", i.e. non-mangled names. As long as array2d_advance()
  is a macro, you're at risk to overwrite equally named variables
  within the caller's scope - one more point for using functions.
- You must be prepared that the user performs *nested* iterations.
- You must even be prepared for nested iterations over the *same*
  array; therefore, the name mangling must be sufficiently unique.

> 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.

Regarding clean-up operations, I've had no special issues in mind. IMO,
it is just good style to think about the lifetime of non-local objects,
i.e. objects which do not go out of scope automatically. An example for
a necessary clean-up are the XXX_FIND_REQUIRED_YYY variables defined by
FIND_PACKAGE(). While the variables defined by the find module / config
file are conveyed to the caller, i.e. they're persistent in this sense,
the XXX_FIND_REQUIRED_YYY ones are removed since they might influence
a subsequent processing of the same find module / config file.

>> 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.

BTW, why just 2D arrays, why not nD?

Regards,

Michael