One problem I had initially was that the xsubpp output would not compile, complaining that cstdio.h and several other standard headers have syntax errors in them. That's odd, since these are standard headers distributed with the compiler -- it seems highly unlikely that they contain syntax errors, even if this is a Microsoft product.
I finally fixed it by putting the C++ header #includes first in the file and the standard Perl C header #includes after them. (and by making sure that the XS output was recognized as C++ rather than C, but that's tangential to my question). Other monks have run into very similar problems (here and here), and at least one person independently found the same solution.
Great. Problem solved. But why? Why should there be this restriction on the order of #included headers in XS modules? I can keep on using this solution in future XS extensions, but I'll feel like a member of some cargo cult if I keep doing it without understanding the why. So does any monk out there have a clue what's really going on here that the order of #includes has this effect?
--DrWhy
"If God had meant for us to think for ourselves he would have given us brains. Oh, wait..."
In reply to Why does order of #include's matter in XS file for C++ extensions under Windows? by DrWhy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |