This sounds like a fine approach to me. Alternatively or additionally, you could #define __INLINE_CPP_STANDARD_HEADERS__ (and equivalent for std namespace) and allow the user to handle the situation, or any other standards-dependent code, themselves.
David On Dec 19, 2011 10:55 PM, "David Oswald" <daosw...@gmail.com> wrote: > 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 >
