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