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 <rcdai...@gmail.com> wrote: > On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling <mhertl...@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. >
-- 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