From: David B. <da...@da...> - 2009-08-10 21:27:27
|
As far as I know, even if there is a cast such as a double, it doesn't work. It has been this way for a very long time. The documentation is pretty clear about being able to resolve identifiers although maybe it should also include type names. Keep in mind that because the preprocessor runs before anything else, there is no way to resolve things such as typedefs until much later. That's partly why the behavior is the way it is. Cheers, Dave On Aug 10, 2009, at 4:16 PM, William S Fulton wrote: > Dave, is this something that should work if the cast was a standard > C type, say double? That documentation link has an example using a > double cast (F_CONST) that indicates it should work. I'm wondering > if the documentation is out of date or it is a bug, as this ability > to handle constants with this cast was working in 1.1p5, but got > dropped somewhere in the early versions of 1.3. I checked 1.3.10 and > a few versions after it and they all ignore F_CONST. > > William > > David Beazley wrote: >> The behavior of the preprocessor is described here: >> http://swig.sourceforge.net/Doc1.3/SWIG.html#SWIG_nn12 >> In short, constants are not going to be created unless the Swig >> preprocessor can fully resolve all identifiers that appear in a >> macro definition and the resulting text can be evaluated as a >> valid arithmetic expression. The appearance of (word) is going >> to make SWIG ignore the definition. You're going to need to >> remove the cast to get SWIG to recognize it as a constant. >> As for arrays, SWIG traditionally did not evaluate expressions in >> array dimensions. I have no idea if that is supported now or >> not. You may have to experiment with it. >> Cheers, >> Dave >> On Aug 5, 2009, at 12:31 PM, glenneroo wrote: >>> Couldn't find anything on this in bugtracker, feature tracker or >>> user list. >>> >>> My .i file (attached) just includes a standard .h file with some >>> structs and lots of #DEFINEs. >>> >>> This line is causing me pain: >>> #define MAX_SECTOR_CHARS (word) 16 >>> >>> It's not being processed by constantWrapper(). >>> >>> When i remove the (word) it's passed to constantWrapper() >>> normally. I can't see any warnings in SWIG either. I would debug >>> but i can't find where it's being parsed. I have also tried >>> changing word to char and int, neither of which works. >>> >>> Any ideas? Is more info required? Should i post this in the forums? >>> >>> My .h file looks something like this: >>> >>> #define MAX_SECTOR_CHARS (word) 16 >>> struct blah >>> { >>> byte sectors[(MAX_SECTORS+7)/8]; >>> }; >>> >>> >>> ...which leads me to ask also, there is no support for RPN >>> handling of such array cases? I guess i have to manually do the >>> math: (16+7)/ 8 ? >>> >>> Many thanks for any clues! >>> >>> -glenn >>> /* File : xvcs.i */ >>> %module _versions >>> >>> %{ >>> /* include in the generated wrapper file */ >>> typedef word freq_num_type_t; >>> %} >>> /* tell SWIG about it */ >>> typedef word freq_num_type_t; >>> >>> %{ >>> /* Includes the header in the wrapper code */ >>> #include "xvcs.h" >>> %} >>> >>> /* Parse the header file to generate wrappers */ >>> %include "xvcs .h >>> "------------------------------------------------------------------------------ >>> Let Crystal Reports handle the reporting - Free Crystal Reports >>> 2008 30-Day >>> trial. Simplify your report design, integration and deployment - >>> and focus on >>> what you do best, core application coding. Discover what's new with >>> Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________ >>> Swig-user mailing list >>> Swi...@li... >>> https://lists.sourceforge.net/lists/listinfo/swig-user >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports >> 2008 30-Day trial. Simplify your report design, integration and >> deployment - and focus on what you do best, core application >> coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Swig-user mailing list >> Swi...@li... >> https://lists.sourceforge.net/lists/listinfo/swig-user > |