Doing so is non-portable.
The same is also true of #pragma once, un-named unions/structs, SIMD optimisations, fread/fwrite, graphics API's, sound API's, input API's, wide strings, C++ 0x, C++ 11, GUI code, and more or less everything that most game developers use on a daily basis. This is a game developer forum, not comp.lang.c++. If you want program truly portable games, you're choices are: text adventures, and text adventures. If you have any aspirations beyond that, well you're just going to have to accept that your codebase will contain a number of platform specific headers. Your compiler may vary, as will the implementation of the standard library, hence the caveat I posted above.
Adding a declaration to namespace std is undefined behavior according to the C++ standard, which includes forward declarations of standard library classes.
Yes, technically speaking I could write a compiler in which the std lib is implemented as intrinsics, rather than C++ which is treated as a typical library. I doubt you would use it, and I doubt anyone else would either (me included). If the standard lib provided with your compiler is written in C++, it follows the rules of C++. Since forward declarations are legal in C++, it will obey those rules. Or do you disagree?
Is the worse case scenario (on sane compilers), a failure to compile or is it likely that something harder to detect would result?
Failure to compile is the worst that can happen. Annoying, but fixable.
I hadn't considered the lack of virtual destructors actually, but I hadn't intended to use these polymorphically.
If all you're doing data wise is this:
struct String : public std::string
{
int pod_data_only;
};
there is no problem. If you're doing this:
struct String : public std::string
{
std::vector< std::map< std::string, std::vector<int> > > dynamic_data;
};
Then be afraid! be very afraid!
- If you are worried about compile times, a pre-compiled header should fix that.
Not always an option. You need a compiler that supports them (PS3? Wii?).
- If you are trying to solve circular dependencies... SAY WHAT?
It happens, especially when working in large teams. It shouldn't happen, and there is usually a way to fix them 'properly', but when deadlines are tight, it's usually better to get it out of the door no matter what, than refactor vasts swathes of code (and go through another round of QA/bug-fixing/delayed release).