<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>Consider just a single warning flag: "-Wc++98-compat", designed for use in "-std=c++11" mode. The goal is to warn about obvious code patterns that break backwards compatibility. Why is this flag useful from a strictly functional perspective? Because developers may need to have non-trivial amounts of code compiled in both C++98 and C++11 contexts. Imagine some libraries are<span style="background-color:transparent"> expected to work with projects whose compilers do not yet support C++11, *and* projects which actively use C++11.</span><span style="background-color:transparent"> Because of libstdc++ issues, all of the code may need to be compiled as C++11 in the latter case.</span><span style="background-color:transparent"> Even without this, headers will leak across the TU boundary and thus be compiled in both modes.</span></div>
</div></blockquote><div><br>In this case, the library authors would maintain & develop in C++98, presumably - relying on forward compatibility warnings (-Wc++11-compat) to help guide them. Then for release they'd build both 98 and 11 versions of their binaries. Targeting your LCD makes a fair bit of sense to me. <br>
<br>Is there a particular case where one would be compelled to work in C++11 when developing and maintaining a library designed for backwards compatibility? I suppose the use case you're describing is where the library author is actively consuming the library in a C++11 context & tweaking the C++98 library day-to-day as they work on their C++11 consumer of that library. Possible, if somewhat inefficient, perhaps (that their build system is actively building both libs all the time if the C++98/11 lib is such a commonly used/general tool - I'd expect it to be built authoritatively, perhaps)<br>
<br>Not to say that I don't see your point - certainly that scenario is possible & the developer working on a C++11 library that depended on a backwards compatible C++98 library that was compiling as C++11 in  his/her project could benefit from such warnings being turned on for those files.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div></div><div>This argument may be invalid, there may be reasons why it's not worth doing (although unless other problems / options arise, it seems to be worth our time at Google), but I don't this is style related.</div>
</div></blockquote><div><br>Not exactly 'style', no. Perhaps, let's say, "situational", and I think that's what Doug's getting at - if it's not on-by-default, clang developers aren't really paying much attention to it (I'm not sure I necessarily agree with this method - but it's possibly a reality I can't change). The idea being that people who have particular interest in particular situational warnings would be better off maintaining a tool designed for them so they don't get drowned out by the larger issues of just getting the clang compiler to do its main job. (not to mention all that extra situational stuff adds a burden to clang developers trying to do the hard job of writing a C++ compiler)<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="gmail_quote">
<div></div><div>Now, a somewhat separate issue is the detailed warnings for individual features of C++11. I have some vague ideas as to why these may be functionally necessary for codebases migrating from C++98 -> C++11, or ways that they might ease such a migration. But I'll be the first (ok, the second?) to say that they both introduce a lot more concerning questions (does C++11 make sense sans features X, Y, and Z? I don't know...) and are much closer to style issues</div>
</div></blockquote><div><br>I imagine these are real issues for cross platform code. For example: I wouldn't mind if LLVM could adopt the use of 'nullptr', possibly the simplest of C++11 features. This would maintain portability across all practical compilers that I know of without getting into the realm of some of the less consistently implemented C++11 features at this time. (I don't cite this as a totally practical example, but at least one use case)<br>
<br>But that's a different scenario from the previous one, yes. <br></div></div>