Andreas Huber wrote:
"Michael Marcin" <mmarcin@method-solutions.com> wrote in message
Anything else is rude.
The code is open to your inspection and the permanent suppressions can be found very easily as Steven has shown. If you really do care so much about these warnings then turn them back on after including the headers. This approach is more work for you, but makes live easier for the vast majority of users.
I happen to agree with Michael here. Suggesting to re-enable them is beside the point here. The point is that a library shouldn't change compiler settings for the user. Period. It doesn't matter whether that warning has any value at all or it's completely useless. What's important is that the user has the right to assume that he gets to decide the compiler settings, in whatever method he chooses (out of the methods the compiler vendor provides). The user can re-enable the warning, yes, but that's forcing him to a specific way, which will make users angry, and rightfully. Don't try to fix Visual Studio, and force your fix on the users. Let them decide what they consider important and what not, what they want to fix in VS and what not, even if you're certain you know better. Anything else is rude.