Remarkably, the MinGW port of g++ 3.4.5 compiles your example without errors even with -Wall. The Comeau online compiler finds it okay too.
Printable View
Remarkably, the MinGW port of g++ 3.4.5 compiles your example without errors even with -Wall. The Comeau online compiler finds it okay too.
Then stuff all common includes in one header and include it in your projects. Problem fixed.
Well, it goes to show that the problem is not MS specific.Quote:
Actually, I only tried this particular example on VC++, but I remember seeing a problem like this where I was missing some C headers...
Allowing '>>' in template declarations seems like a simple enough requirement, but the amount of work required in the compiler's parser would be ridiculous in comparison to the benefit of allowing it, which is practically zero.
And the idea of a standards body is to formalize and enhance existing practice, not to subject implementers to onerous, pointless requirements. It's not, "We create the standard and now you have to do it this way," it's practically the exact opposite.
Of course, now that compiler vendors have had time to make the necessary changes to handle >>, they will be changing the next standard to allow it.
In this case, not allowing >> is odd and forcing compiler vendors to support it makes sense once they have enough time to do so.
MSVS 6, 2003, and 2005 all have had this 'auto-include' of headers for quite some time. The problem comes when it demands you must include some headers but yet does not enforce you including others that the code clearly needs. It has something to do with your project options and which 'common' libraries/headers, if any, you wish to use. By default MSVS knows where the standard libraries are as well as the headers. Once you install Platform SDK and integrate it into VS it usually also knows where to find the Platform SDK files. There are times when you can get away with not including Platform SDK headers and it will still compile.
However what is very odd in VS is Intellisense. Often it shows functions, variables, etc, that look to be accessible and yet often when you compile it complains of unresolved externals or undefined symbols. Intellisense often does not match exactly what is 'visible' at the current location in your code. Often times it shows functions and methods that are clearly not accessible yet it appears they are. This is extremely annoying. Other times Intellisense just completely fails to show anything, does not update correctly when you alter headers, or gets corrupted.
That behavior was changed in MSVC8 (aka 2005). It actually needs the proper headers to be able to see the functions.
Yes, IntelliSense support is quite old by now, though I've heard they'll be updating it for the next version. Thank the gods for that; it's quite a mess right now.Quote:
Other times Intellisense just completely fails to show anything, does not update correctly when you alter headers, or gets corrupted.