From: William S F. <ws...@fu...> - 2011-02-13 00:03:28
|
On 11/02/11 00:12, David Piepgrass wrote: >> I'm inclined to just make this an error when SWIG parses preprocessor >> directives in macros, just like the C compiler. The problem is there is some >> code in the Lib directory that will then fail and will need rewriting. Any >> objections to turning this kind of code into errors and hence more defined >> behaviour? > > I am using preprocessor directives inside macros quite a bit. Consider this monster macro, which is designed to wrap STL collections (not just vector<T>), especially when using custom intrusive ref-counting (because I don't use shared_ptr, I have my own system for reference counting.) I'm not sure how you could rewrite this not to use the preprocessor inside the macro, and it looks like SWIG is specifically designed to support the preprocessor inside macros -- notice how I can perform tests on the macro arguments such as > > #if #LISTNAMESPACE != "" > > ... where LISTNAMESPACE is an argument passed to the macro. This syntax is non-standard C and it shouldn't be in SWIG in my opinion. Nevertheless, it is powerful and given it is being used, it looks like it is here to stay. Meanwhile, I've put in a better fix for the defined() bug fix, keeping the preprocessor functionality as is. William |