search for: cppguid

Probably this has come up before... but have we considered just adopting the Google style guidlines and maybe modifying it in some places? They have a nice script for c++ which will check for many things. http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py

...de which changes behavior depending on whether the full or forward decl are available (which, then, may be an ODR-violation). Effectively the same reasons why the standard forbids users from forward-declaring std:: names apply to doing so to user-defined names. https://google.github.io/styleguide/cppguide.html#Forward_Declarations lists some of the issues, and a recommendation not to do so. Of course you do have the upside is that it can improve compile time. Which is certainly of value, and perhaps that's a worthwhile trade-off when the implementation and forward-declare are both within a sin...

...pending on whether the full or forward decl are available > (which, then, may be an ODR-violation). > > Effectively the same reasons why the standard forbids users from > forward-declaring std:: names apply to doing so to user-defined names. > > https://google.github.io/styleguide/cppguide.html#Forward_Declarations > lists some of the issues, and a recommendation not to do so. > > Of course you do have the upside is that it can improve compile time. > Which is certainly of value, and perhaps that's a worthwhile trade-off when > the implementation and forward-decla...

...rything that is bad about trying to "parse" C++ with regular expressions and python hacks, built up w/o any overarching design or cohesion over years. I await the day we can kill it off and use a real Clang-based tool instead. > > http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml > > http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > --------...

...from here to there, but rather, if there is a better place to be. My arguments for the change are: 1. No other popular C++ coding style uses capitalized variable names. For instance here are other popular C++ conventions that use camelCase: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml http://www.c-xx.com/ccc/ccc.php http://geosoft.no/development/cppstyle.html And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t capitalize variable names. In addition, all the common C derived languages don’t use capitalized variable names (e.g. Java, C#, Objective-C)....

...8#t=12m12s - https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s Other coding guidelines already embrace this: - http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-signed - http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-unsigned - https://google.github.io/styleguide/cppguide.html#Integer_Types It is rare that overflowing (and wrapping) an unsigned integer won't trigger a program bug when the overflow was not intentionally handled. Using signed arithmetic means that you can actually trap on over/underflow and catch these bugs (when using fuzzing for instance). Ch...

...Google/LLVM/Mozilla/Webkit/Chromium - Samples present in repo <https://github.com/nigelbabu/clang-format-sample>. *NOTE*: Samples generated with indent as 4 spaces. - Google Style Guide <https://google.github.io/styleguide/cppguide.html> - LLVM Style Guide <http://llvm.org/docs/CodingStandards.html> - Mozilla Style Guide <https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style> - WebKit style guide <https://webkit.org/code-style-guideline...

Hi Michael, On Thu, Dec 7, 2017 at 3:16 AM, Michael Zolotukhin <mzolotukhin at apple.com> wrote: > > Nice to IWYU developers here:) I wonder how hard it would be to run IWYU on > LLVM/Clang (or, if it’s supposed to work, I wonder what I did wrong). There are known problems with running IWYU over LLVM/Clang -- Zachary Turner made an attempt a while back to get it up and running.

...ed by >>> reference must be labeled const. [...] it is a very strong convention in >>> Google code that input arguments are values or const references while > output >>> arguments are pointers." > (http://google-styleguide.googlecode.com/svn/trunk/ >>> cppguide.xml#Reference_Arguments ) >> >> I haven't seen much of that around here. >> >>> I see that LLVM Coding Standards document doesn't touch this subject at > all. >>> Should we use this opportunity to add to it that in LLVM, the choice > between >...

...e to be. >> >> My arguments for the change are: >> >> 1. No other popular C++ coding style uses capitalized variable names. >> For instance here are other popular C++ conventions that use camelCase: >> >> http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml >> > This does not use camelCase for variable names. http://www.c-xx.com/ccc/ccc.php >> http://geosoft.no/development/cppstyle.html >> >> And, of course, the all-lower-case conventions (e.g. C++ ARM) don’t >> capitalize variable names. In addition, all...