Warnings in Standard Includes

Quote:

Original post by Anonymous Poster The best way I've found is to create a local "warningfree_mmsystem.h" that looks like this: #pragma warning(push, 3) #pragma warning(disable: 4201) #include #pragma warning(pop) Then include "warningfree_mmsystem.h" instead of in your code.

Mnyeah. As I said in my original post, I would rather avoid using #pragma warning. I may end up using a variation on this, or I might just try and tolerate the extra warnings if another solution is not found.
Thanks for the suggestion though.


jfl.

Well technically, mmsystem.h is not a 'standard' include. Also, i'm using VC8 and I don't get that warning from including mmsystem.h. Do you have the latest Platform SDK?

In the compiler options for the C++ compiler, there should be a "ignore specific warnings" option, where you can add the number 4201 (without the C). That should shut up that particular warning.

Quote:

Original post by RDragon1 Well technically, mmsystem.h is not a 'standard' include. Also, i'm using VC8 and I don't get that warning from including mmsystem.h. Do you have the latest Platform SDK?

Yeah, I know. I meant library includes that are not directly part of a project or that I don't want to "debug". I do have the latest PSDK, and you are not seeing this warning probably because you did not specify Warning Level 4.

Quote:

Original post by hplus0603 In the compiler options for the C++ compiler, there should be a "ignore specific warnings" option, where you can add the number 4201 (without the C). That should shut up that particular warning.

Well, this is not exactly what I'm looking for. I would rather a way to ignore *all* warnings on specific files or folders that I have no interest in (possibly through a compiler option, and not through preprocessor directives or other code modifications). I may want to see warnings in my files, but not in certain library include files.


jfl.

[Edited by - jflanglois on January 8, 2006 1:27:39 PM]

Actually, most windows api functions that are declared in mmsystem.h have this line in their documentation:

Header: Declared in Mmsystem.h; include Windows.h.

This means, while the function is declared in mmsystem.h, you should actually include windows.h.

Quote:

Original post by RDragon1 Actually, most windows api functions that are declared in mmsystem.h have this line in their documentation: Header: Declared in Mmsystem.h; include Windows.h. This means, while the function is declared in mmsystem.h, you should actually include windows.h.

Which I did. The warning, however, is caused by code in mmsystem.h.
I'm starting to think that the functionality that I am looking for does not exist in VC8.

I find it extremely annoying that Microsoft's header files generate warnings (at level 4). I even get them in the standard library header files. I turn off the warnings in my PCH (wrapping all the headers with "#pragma warning( push, 3 )" and "#pragma warning( pop )"). Unfortunately, I still get warnings (which I can't seem to turn off) in the whole program optimization step.

c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\atltrace.h(188) : warning C4512: 'ATL::CTraceFileAndLineInfo' : assignment operator could not be generated
c:\program files\microsoft visual studio .net 2003\vc7\include\vector(856) : warning C4702: unreachable code

There's nothing stopping you from modifying your standard library header files and disabling the warnings directly within them. Push the warning state and disable the warnings you don't want at the top of the file and then pop the state at the bottom. Shouldn't adversely affect anything.

Quote:

Original post by Shinkage There's nothing stopping you from modifying your standard library header files and disabling the warnings directly within them. Push the warning state and disable the warnings you don't want at the top of the file and then pop the state at the bottom. Shouldn't adversely affect anything.

That's something else I had thought about. Doesn't seem very kosher to me, but I guess that would be the best solution as it stands. I wonder what this does in terms of EULA, though.

Quote:

Original post by JohnBolton I find it extremely annoying that Microsoft's header files generate warnings (at level 4). I even get them in the standard library header files. I turn off the warnings in my PCH (wrapping all the headers with "#pragma warning( push, 3 )" and "#pragma warning( pop )"). Unfortunately, I still get warnings (which I can't seem to turn off) in the whole program optimization step. c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\atltrace.h(188) : warning C4512: 'ATL::CTraceFileAndLineInfo' : assignment operator could not be generated c:\program files\microsoft visual studio .net 2003\vc7\include\vector(856) : warning C4702: unreachable code

It drives me nuts too. Maybe it's because I'm slightly obsessive/compulsive, but I want clean builds, damn it!
As for your problem, is it possible that you are including something elsewhere than your PCH that would eventually get to atltrace.h? Unfortunately, I don't have atltrace.h to check it out, but I'm pretty sure you can list included files during compilation in VC7.1.


jfl.

Quote:

Original post by jflanglois Quote: Original post by Shinkage There's nothing stopping you from modifying your standard library header files and disabling the warnings directly within them. Push the warning state and disable the warnings you don't want at the top of the file and then pop the state at the bottom. Shouldn't adversely affect anything. That's something else I had thought about. Doesn't seem very kosher to me, but I guess that would be the best solution as it stands. I wonder what this does in terms of EULA, though.

As long as you don't redistribute modified source/include files it should be OK, within fair use.

I agree there's something wrong here though...I shouldn't need to muck around with warnings in other people's code (especially if I _paid_ for it...), that just reeks of bad software...

Quote:

Original post by jflanglois That's something else I had thought about. Doesn't seem very kosher to me, but I guess that would be the best solution as it stands. I wonder what this does in terms of EULA, though.

Does absolutely nothing to the EULA. It's not like library header files are some sacred beings that are not to be touched upon pain of death. They're just tools, and sometimes tools require a little modification to meet the builder's needs. I modify third party header files all the time when I need to do something like this, just don't redistribute them.

Alright, thanks to all for your suggestions. I ended up modifying the includes themselves.


jfl.