Thanks to Rob for pointing the way to a patch to detect header filenames. With a few adaptations I've applied it to a dev. version of Inline::CPP.
This has me thinking though. Here are a couple of issues that I think I could facilitate within Inline::CPP. Both relate to portability of applications using Inline::CPP. First: Someone writing code that uses Inline::CPP may not know whether the target system supports old style headers or new. Especially if something is being uploaded to CPAN. I was thinking that now that we're properly detecting which style header to use, we could apply that knowledge to whatever the user puts in AUTO_INCLUDE. Anything listed in AUTO_INCLUDE within <> brackets (but not "") could have a .h appended or removed based on the same rule that we're already applying to <iostream>. That way someone authoring code that uses Inline::CPP wouldn't need to worry about whether the target system supports old style headers or new. If the behavior is too "smart", I could add an option to disable it. "AUTO_HEADER_NAMING => 1" (default), "AUTO_HEADER_NAMING => 0" (option to disable the smartness). The second issue: If the target system uses pre-Standard headers, standard library tools are not placed in their own namespaces. And in fact, "using namespace std;" wouldn't even compile. Standard C++ places all tools from the standard library in namespace 'std'. A programmer can then choose whether to "using namespace std;", or fully qualify names, as in "std::cout << ...". But either one of those approaches would break portability with legacy compilers. Given that we're correctly detecting which style headers to use, and it's only the ".h" (legacy) compilers that don't support namespaces, I could add a "using namespace std;" to the list of #define's and #includes, IF we detected Standard C++, and NOT include that if we detected legacy C++. The pro is that a programmer using Inline::CPP could be relieved of the responsibility for dealing with differences between legacy and modern compilers. If I write some C++ function that uses a function out of the standard library I don't want to have to guess whether my tool will be compiled on a legacy compiler or modern compiler. By abstracting that issue away from the user he won't have to jump through hoops trying to detect with a bunch of crazy #ifdef's, and won't have to include trial-run code in his Makefile.PL (as we've had to do). He can just write generic C++ (as much as possible) and not worry. The con is that namespaces exist for a reason. In a large application they serve a similar function to Perl's package namespaces. I think the pro outweighs the con, particularly where I just don't see Inline::CPP being used to develop a C++ application big enough to care so much about namespaces. And, even if we're including namespace std by default we aren't forcing the user to NOT use other namespaces. If it is a concern, I could also create an "AUTO_NAMESPACE_STD" configuration option: 1 default, 0 optional to disable the smartness again. I'm more or less sold on applying both of these upgrades. But I'd be interested in opinions first. Dave -- David Oswald daosw...@gmail.com
