That makes sense. Someone should stick it in the coding standards? it's just thankless work Absolutely, but since slow compile times (can) nuke my productivity, I may move some code out of headers. Sincerely, Alexander Riccio -- "Change the world or go home." about.me/ariccio <http://about.me/ariccio> If left to my own devices, I will build more. ⁂ On Wed, Feb 10, 2016 at 7:13 PM, Reid Kleckner <rnk at google.com> wrote:> Some parts of Clang are very careful about keeping implementation details > out of headers, and others aren't. Consider RecordLayoutBuilder, for > example, whose class definition is in the .cpp file. > > In general I would say that we are in favor of hiding as many > implementation details as we can, it's just thankless work to refactor > headers to sink code code into .cpp files, prune transitive includes, and > fix the resulting build errors. > > On Wed, Feb 10, 2016 at 4:07 PM, <Alexander G. Riccio> via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> While investigating compile times, I noticed that there's no information >> in the LLVM coding standards about code in headers. Many LLVM/Clang headers >> have lots of complex code in headers - I'm specifically looking at the >> Static Analyzer projects (seemingly slowest compile times, biggest >> hinderance to my productivity) - that probably doesn't need to be there. >> Nobody likes slow compile times. >> >> What's the LLVM policy on code in headers? >> >> If there is none, the Chromium "C++ Dos and Don'ts" >> <https://www.chromium.org/developers/coding-style/cpp-dos-and-donts> >> page offers a good starting point. >> >> >> Sincerely, >> Alexander Riccio >> -- >> "Change the world or go home." >> about.me/ariccio >> >> <http://about.me/ariccio> >> If left to my own devices, I will build more. >> ⁂ >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/164bf90c/attachment.html>
> Someone should stick it in the coding standards?I'm happy to give this a shot. George On Wed, Feb 10, 2016 at 4:45 PM, <Alexander G. Riccio> via llvm-dev < llvm-dev at lists.llvm.org> wrote:> That makes sense. Someone should stick it in the coding standards? > > it's just thankless work > > > Absolutely, but since slow compile times (can) nuke my productivity, I may > move some code out of headers. > > Sincerely, > Alexander Riccio > -- > "Change the world or go home." > about.me/ariccio > > <http://about.me/ariccio> > If left to my own devices, I will build more. > ⁂ > > On Wed, Feb 10, 2016 at 7:13 PM, Reid Kleckner <rnk at google.com> wrote: > >> Some parts of Clang are very careful about keeping implementation details >> out of headers, and others aren't. Consider RecordLayoutBuilder, for >> example, whose class definition is in the .cpp file. >> >> In general I would say that we are in favor of hiding as many >> implementation details as we can, it's just thankless work to refactor >> headers to sink code code into .cpp files, prune transitive includes, and >> fix the resulting build errors. >> >> On Wed, Feb 10, 2016 at 4:07 PM, <Alexander G. Riccio> via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> While investigating compile times, I noticed that there's no information >>> in the LLVM coding standards about code in headers. Many LLVM/Clang headers >>> have lots of complex code in headers - I'm specifically looking at the >>> Static Analyzer projects (seemingly slowest compile times, biggest >>> hinderance to my productivity) - that probably doesn't need to be there. >>> Nobody likes slow compile times. >>> >>> What's the LLVM policy on code in headers? >>> >>> If there is none, the Chromium "C++ Dos and Don'ts" >>> <https://www.chromium.org/developers/coding-style/cpp-dos-and-donts> >>> page offers a good starting point. >>> >>> >>> Sincerely, >>> Alexander Riccio >>> -- >>> "Change the world or go home." >>> about.me/ariccio >>> >>> <http://about.me/ariccio> >>> If left to my own devices, I will build more. >>> ⁂ >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>> >>> >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/ce9adc33/attachment.html>
> On Feb 10, 2016, at 7:34 PM, George Burgess IV via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > Someone should stick it in the coding standards? > > I'm happy to give this a shot.My 2c: I don’t think that we can agree to abstract code guidelines without knowing what it means in practice for the codebase. If you’re interested in this, please include a diff that shows the impact to the headers, and we should also measure what happens to the performance of the generated compiler. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160210/04d26df4/attachment.html>