[cfe-commits] r146959 - in /cfe/trunk: include/clang/AST/ include/clang/Analysis/Analyses/ include/clang/Basic/ include/clang/CodeGen/ include/clang/Driver/ include/clang/Frontend/ include/clang/Lex/ include/clang/Sema/ include/clang/StaticAnalyzer/Core/ include/clang/StaticAnalyzer/Core/BugReporter/ include/clang/StaticAnalyzer/Core/PathSensitive/ lib/AST/ lib/Analysis/ lib/Basic/ lib/CodeGen/ lib/Driver/ lib/Frontend/ lib/Lex/ lib/Parse/ lib/Sema/ lib/StaticAnalyzer/Core/ utils/TableGen/

[Chris Lattner]

On Dec 19, 2011, at 9:57 PM, Ted Kremenek wrote:

> On Dec 19, 2011, at 9:48 PM, Rafael Ávila de Espíndola wrote:
> 
>> On 19/12/11 11:33 PM, Ted Kremenek wrote:
>>> Hi David,
>> When building with gcc 4.6, the sum of the size of every .o goes from
>> 81926520 to 82165328 (so the patch saved a bit) and the clang binary
>> goes from 36017976 to 35894528.
> 
> Beyond the file size, my main concern is why do we need an anchor() methods at all?  Can't we just move more methods to have out-of-line definitions in .cpp files and accomplish the same thing?  I'm completely willing to admit that I'm missing some key idea, but if so can someone please point it out to me?  No offense David (as I really appreciate you spear heading this effort), but they really look like turds in the codebase to me.

If there is a simple virtual method that can be moved out of line without impacting performance, then that is clearly preferable to adding an explicit anchor method.  The main advantage of this patch IMO is that we could turn on the warning flag in the build to catch future cases that should have an anchor.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111220/a76fc0d0/attachment.html>