(I would encourage folks to at least keep STL on the to-line, or mail him directly as he may not read cfe-dev as closely as others...)<br><br><div class="gmail_quote">On Wed, Jun 6, 2012 at 2:40 AM, Dallman, John <span dir="ltr"><<a href="mailto:john.dallman@siemens.com" target="_blank">john.dallman@siemens.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Instead of asking them to get rid of it, why don't you ask them to fix it?<br>
> Having a compiler option that disables nonstandard extensions is generally<br>
> desirable.<br>
<br>
</div>Hear, hear. Saying "Fix the warnings at /W4 to get compliance" is all very well,<br>
but keeping them from compiling in the first place works a lot better in a large<br>
programming team with people working on many platforms.</blockquote><div><br></div><div>The common problem is that standard library headers shipping with the compile *should* have access to the extensions. They're "implementation details" that can be relied upon within the standard library, or any other part of the toolchain.</div>
<div><br></div><div>FWIW, Clang, GCC, and others handle this with a two-pronged approach:</div><div><br></div><div>1) Make a special warning mode that warns (perhaps promoting warnings to errors) on all extensions.</div><div>
2) Suppress warnings (even if they might be promoted to errors) when they come from system headers.</div><div><br></div><div>This allows the compiler to warn (or error) on extensions in the user code, without turning off entire features, some of which may be in use.</div>
<div><br></div><div>Note that this does require the extensions to be correctly attributed to the system header even when templates macros and other devices are used. Sometimes this is problematic.</div><div><br></div><div>
<br></div><div>Anyways, this is all a bit off-topic for Clang development. The right approach is for Clang to not set flags when being built by Visual Studio that are flaky or problematic. People experimenting or developing on Clang shouldn't have a degraded experience when first hacking on the code. Hopefully one of our Windows developers can send a patch my way for the CMake builds? I'm happy to review it, but I don't have windows to really test it out on...</div>
</div>