Re: [CMake] 2D arrays
On 12/01/2011 06:04 PM, Robert Dailey wrote: On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling mhertl...@online.dewrote: 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
Re: [CMake] 2D arrays
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 rcdai...@gmail.com wrote:
On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling mhertl...@online.dewrote:
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
Re: [CMake] 2D arrays
On Wed, Nov 30, 2011 at 7:18 PM, Michael Hertling mhertl...@online.dewrote: 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
Re: [CMake] 2D arrays
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.dewrote:
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
Re: [CMake] 2D arrays
On 11/30/2011 03:29 AM, Robert Dailey wrote:
On Tue, Nov 29, 2011 at 5:57 PM, Michael Hertling mhertl...@online.dewrote:
Just some spontaneous questions/remarks:
Thanks; I really appreciate it!
- Why do you use macros instead of functions?
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().
- What's about cleaning up the numerous helper variables,
e.g. by an additional array2d_cleanup() function or the like?
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.
- In array2d_begin_loop(), couldn't you rearrange the parameters,
array2d_begin_loop(advanced fruit;animal ${two_dee_array}), use
LIST(LENGTH var_names _array2d_width) and take ARGN as the array?
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.
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
Re: [CMake] 2D arrays
I have created a pretty clean solution to this until there is native
support for multi-dimensional arrays in CMake. I have attached the module,
hopefully it will prove useful to others. Here is an example of how to use
it:
set( two_dee_array
apple cat
orange dog
banana elephant
)
array2d_begin_loop( advanced ${two_dee_array} 2 fruit;animal )
while( advanced )
message( Fruit: ${fruit} )
message( Animal: ${animal} )
array2d_advance()
endwhile()
-
Robert Dailey
On Mon, Nov 28, 2011 at 2:31 PM, Robert Dailey rcdai...@gmail.com wrote:
Is it possible to have 2D arrays in CMake? As far as the core syntax is
concerned, it seems like only 1D arrays are supported. So far I've had to
work around this issue by using a flat array and skipping over elements
using foreach() with a range and step.
Any ideas? Thanks.
-
Robert Dailey
array2d.cmake
Description: Binary data
--
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
Re: [CMake] 2D arrays
On 11/30/2011 12:28 AM, Robert Dailey wrote:
I have created a pretty clean solution to this until there is native
support for multi-dimensional arrays in CMake. I have attached the module,
hopefully it will prove useful to others. Here is an example of how to use
it:
set( two_dee_array
apple cat
orange dog
banana elephant
)
array2d_begin_loop( advanced ${two_dee_array} 2 fruit;animal )
while( advanced )
message( Fruit: ${fruit} )
message( Animal: ${animal} )
array2d_advance()
endwhile()
-
Robert Dailey
Just some spontaneous questions/remarks:
- Why do you use macros instead of functions?
- What's about cleaning up the numerous helper variables,
e.g. by an additional array2d_cleanup() function or the like?
- In array2d_begin_loop(), couldn't you rearrange the parameters,
array2d_begin_loop(advanced fruit;animal ${two_dee_array}), use
LIST(LENGTH var_names _array2d_width) and take ARGN as the array?
Regards,
Michael
On Mon, Nov 28, 2011 at 2:31 PM, Robert Dailey rcdai...@gmail.com wrote:
Is it possible to have 2D arrays in CMake? As far as the core syntax is
concerned, it seems like only 1D arrays are supported. So far I've had to
work around this issue by using a flat array and skipping over elements
using foreach() with a range and step.
Any ideas? Thanks.
-
Robert Dailey
--
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
Re: [CMake] 2D arrays
On Tue, Nov 29, 2011 at 5:57 PM, Michael Hertling mhertl...@online.dewrote:
Just some spontaneous questions/remarks:
Thanks; I really appreciate it!
- Why do you use macros instead of functions?
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's about cleaning up the numerous helper variables,
e.g. by an additional array2d_cleanup() function or the like?
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).
- In array2d_begin_loop(), couldn't you rearrange the parameters,
array2d_begin_loop(advanced fruit;animal ${two_dee_array}), use
LIST(LENGTH var_names _array2d_width) and take ARGN as the array?
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?
--
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
Re: [CMake] 2D arrays
How about the following two examples for a table or 2d array.
In the first one, each column can have a name too. Its like an array of
pointers in C++.
set(fruits apple orange banana)
set(animals cat dog elephant)
set(columns fruits animals)
foreach(column ${columns})
foreach(item ${${column}})
message(${column} has item ${item})
endforeach()
endforeach()
Or if you have pairs, one fruit with one animal
set(tuples
apple\;cat
orange\;dog
banana\;elephant
)
foreach(pair ${tuples})
message(pair has items ${pair})
foreach(component ${pair})
message(component = ${component})
endforeach()
endforeach()
Both of those seem close enough to 2d array functionality using the cmake
language.
Clint
On Nov 29, 2011, at 4:28 PM, Robert Dailey wrote:
I have created a pretty clean solution to this until there is native support
for multi-dimensional arrays in CMake. I have attached the module, hopefully
it will prove useful to others. Here is an example of how to use it:
set( two_dee_array
apple cat
orange dog
banana elephant
)
array2d_begin_loop( advanced ${two_dee_array} 2 fruit;animal )
while( advanced )
message( Fruit: ${fruit} )
message( Animal: ${animal} )
array2d_advance()
endwhile()
-
Robert Dailey
On Mon, Nov 28, 2011 at 2:31 PM, Robert Dailey rcdai...@gmail.com wrote:
Is it possible to have 2D arrays in CMake? As far as the core syntax is
concerned, it seems like only 1D arrays are supported. So far I've had to
work around this issue by using a flat array and skipping over elements using
foreach() with a range and step.
Any ideas? Thanks.
-
Robert Dailey
array2d.cmake--
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
--
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
[CMake] 2D arrays
Is it possible to have 2D arrays in CMake? As far as the core syntax is concerned, it seems like only 1D arrays are supported. So far I've had to work around this issue by using a flat array and skipping over elements using foreach() with a range and step. Any ideas? Thanks. - Robert Dailey -- 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
