> Dean Arnold wrote: > > Yet more issues... > > > > Appears Inline::Struct has some parsing issues w/ > > certain declarations, notably, > > > > char a[8]; // actually, any array declaration > > unsigned long b; // actually unsigned anything > > float x; // but double is OK > > > > I think these are Inline C shortcomings, rather than Inline::Struct > problems per se. At least these are areas in which Inline C also struggles. >
Actually, it looks to be a bit of both.... I'm no Parse::RecDescent expert, but my interpretation of the Inline::Struct::grammar indicates that there's no attempt to capture array indices after an IDENTIFIER token; that may be due to the fact that Inline::C can't handle them anyway. (And since C permits an arbitrary number of dimensions, I suspect support for same would be a challenge anyway) Also, I noticed in the XS/C generated by Inline::Struct, when a struct uses a pointer to another struct, the generated code seemed incomplete (compared to a struct with just primitive types). Anyway, I've tossed in the towel on Inline::Struct and am tackling the issue with a direct Inline::C implementation. With a lot of cut/paste, I can emulate most of what Inline::Struct would've done anyway (building an accessors for each field), and perhaps the resulting code will be a bit more optimal. However, it would be nice if all these limitations were documented in Inline::Struct's POD, so potential users won't have to spend 2 days fussing with it before finding these things out... At least this dialog will end up in the online archives for those willing to search/google... Many thanks for your help! Dean
