<div class="gmail_quote">On Thu, Oct 13, 2011 at 5:32 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.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"><br>
On Oct 5, 2011, at 3:35 PM, Jeffrey Yasskin wrote:<br>
<br>
</div><div class="im">> Hi clang folks,<br>
><br>
> I'm working on migrating a certain large codebase to C++0x, and we're<br>
> looking for a way to turn on C++0x mode but make sure people don't use<br>
> C++0x features before we're ready for them.<br>
><br>
> * We need to turn on -std=gnu++0x for the whole codebase at once<br>
> because C++98 and C++0x have different ABIs.<br>
<br>
</div>Summarizing side discussion: libstdc++ has a different ABI in C++98 vs. in C++11, libc++ does not.<br></blockquote><div><br></div><div>Just to clarify why I think this is relevant even though libc++ avoided the problem: I would like to preserve the ability to use Clang productively in C++11 mode with libstdc++; doing so appears to require a codebase-wide switch due to ABIs.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> * Some of our code needs to be portable to a bunch of compilers we<br>
> don't control, so it needs to be as C++98-compatible as we can make<br>
> it.<br>
<br>
</div>And you can't tell libstdc++ to use the C++0x ABI even in C++98 mode?<br></blockquote><div><br></div><div>I'll let Jeffrey comment here, but I believe we looked into this and it was very non-trivial... I'd be interested in his thoughts here.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">This seems more like you're enforcing a coding style ("use only the C++11 features that we like") rather than providing a generally useful feature. I don't think we should be using the warning mechanism to enforce a coding style, for a number of reasons:</blockquote>
<div><br></div><div>I really *really* don't want to restart this discussion. I actually think we're in agreement here. If it comes down to style, the compiler has *no* business doing this in a warning. However, I'm not yet convinced this comes down to style...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'd like to hear more opinions on whether others consider the proposed warnings to be coding style enforcement, or whether they are generally useful. It's clearly not as obvious as if we were proposing -Wbraces-on-new-line or -Wmethods-names-start-with-a-verb.<br>
</blockquote><div><br></div><div>Emphatically agree on the last sentence here. If that's were this ends up, it doesn't belong.</div><div><br></div><div><br></div><div>Ok, so why don't I think this is a style issue? First, let's separate two aspects of the discussion which may simplify things.</div>
<div><br></div><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><br></div><div>I think getting into this situation is inevitable for both open source and corporate codebases. That's one of the primary reasons developers will use "-Wc++11-compat" when in "-std=c++98" mode. Not offerring the complementary set of warnings means that those developers or users working with C++11 builds must (if they modify the library) constantly build twice to ensure they haven't introduced an incompatibility. Sure, "-Wc++98-compat" may never be perfect (any more than "-Wc++11-compat" is perfect), but it simplifies the developer experience when there is some external need or pressure to have a body of code which is valid in both modes.</div>
<div><br></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><br></div><div><br></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, so maybe we can start by discussing nothing more than a single "-Wc++98-compat" flag. No selection, no preferences, just a compatibility warning.</div>
</div>