<html><head></head><body bgcolor="#FFFFFF"><div>How is it conceptually different than the Objective-C modernizer? Why not have both in one tool?<br><br><div>-Chris</div></div><div><br>On Jun 29, 2012, at 2:48 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><br><div><div>On Jun 29, 2012, at 2:47 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">FWIW, I'm a bit hesitant about lumping *all* migrations into a single tool... My preference is for a tool that is at least somewhat focused on a migration domain -- in this case, C++11.</blockquote><div><br></div><div>I completely misread the post I replied to. Yes, I agree with Chandler: the tool should be a C++11 migration tool, so it has a specific, coherent purpose. It should have options for adopting specific C++11 features.</div><div><br></div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br><blockquote type="cite"><div class="gmail_extra">
<div class="gmail_quote">On Fri, Jun 29, 2012 at 2:39 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">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 Jun 29, 2012, at 12:42 PM, Sam Panzer <<a href="mailto:panzer@google.com">panzer@google.com</a>> wrote:<br>
<br>
> Thank you for giving a concrete proposal!<br>
><br>
> One other feature to add would be a degree of confidence for any given change (Certain success, will probably work, risky), so that a command-line flag could control how aggressive any transformations are.<br>
<br>
</div>I don't think that we should admit any transformation unless we know that the resulting code type-checks. The tooling/refactoring stuff should provide that for us, and we'll need to be careful with some transformations (like the for-range loop transformation) that could break the semantics of the program if we're not careful. Migration tools aren't useful if they're going to break my code without telling me.<br>
<div class="im"><br>
> To be more specific, one option is modeling the tool after diagnostics:<br>
> - Transformations are grouped in a new tool, source-migrate<br>
> - Each transformation should be named, so it can be turned on/off, such as -range-for-loop or -noconst-expr<br>
> - Each transformation should be grouped, so that all C++11 transformations could be enabled or disabled in one go, e.g. -Tnocxx11<br>
> - Each transformation should have some way to specify compiler requirements, such as requiring C++ mode.<br>
><br>
> I think this is a good starting place for a code migration framework - I will try setting up a tool with proper command-line flags.<br>
<br>
</div>Yes, this seems completely reasonable.<br>
<div class="HOEnZb"><div class="h5"><br>
- Doug<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>cfe-dev mailing list</span><br><span><a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a></span><br><span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a></span><br></div></blockquote></body></html>