C++ Core Guidelines

It is great to have such a collection of rules and I hope they will be integrated into some easy-to-integrate static code analysis tool (as mentioned in the introduction). Maybe this will help people to transition to more modern C++ and to avoid some pitfalls (e.g. forgetting the &quot;noexcept&quot; for move constructors&#x2F;assignments).<p>However, in some respect this list also shows what is wrong with C++: The fact that you even need such a huge set of rules to write safe and efficient code is somewhat unsettling. I&#x27;d rather hope a new version of the language standard would at least allow to hide deprecated constructs behind a &quot;safe&#x2F;unsafe&quot; pragma.

I&#x27;m only a bit in but I&#x27;ve already found myself disagreeing with some of these<p>for example<p><pre><code> drawline(int,int,int,int); &#x2F;&#x2F; obscure drawline(Point,Point); &#x2F;&#x2F; clearer </code></pre> this is only &quot;clearer&quot; until you find yourself at the very common case where you use several libraries where each defines its own &quot;Point&quot;.<p>Now you&#x27;re writing something like<p><pre><code> drawline(Point(vec.x1, vec.y1), Point(vec.x2, vec.y2)) </code></pre> Pretty ugly!<p>And of course drawline(Point, Point) isn&#x27;t clearer at all imo. What&#x27;s the coordinate system? What are the units? Any performance notes on this function? Etc. I&#x27;ll be checking the documentation the first time anyway.<p><pre><code> void do_something(vector&lt;string&gt;&amp; v) { string val; cin&gt;&gt;val; &#x2F;&#x2F; ... int index = 0; &#x2F;&#x2F; bad for(int i=0; i&lt;v.size(); ++i) if (v[i]==val) { index = i; break; } &#x2F;&#x2F; ... }</code></pre> this is shown to be inferior to the find() version. Again, it&#x27;s only inferior until the very common case where you&#x27;re doing something else with the index, which is pretty common during debugging. Then you&#x27;ll be rewriting the above &quot;bad&quot; version anyway.<p>Similar problems other higher order functions like for_each().

All these guidelines are good for those who have been in C++ trenches for a while. For others, it will become another list, a list similar to what non-native English speakers have to learn by rote in order to predict the pronunciation of English words.<p>We have Scott Meyer&#x27;s effective c++, more effective c++, effective STL, effective STL, modern effective c++.<p>I have read Bjarne&#x27;s &quot;A tour of C++&quot;, which is a good one to read. Also read his &quot;design and evolitution of C++&quot;, which gives rationale for what we see the ugliness of C++.<p>I think we need a small book that describes the history of C++ until now, such a book can help us to remember &quot;C++ core guidelines&quot;. This is similar to how great vowel shift in the history of Enlgih langauge helps us to see deeper patterns in English pronunciation.<p>I hate a bunch of guidelines, without historical explanations, because such guidelines are very hard to pin to one&#x27;s brain unless one is working in hardcare C++ everyday. Maybe, this sounds like playing Piano scales:)

It&#x27;s amazing how many people get these core principles wrong. I recently visited a C++ shop who hasn&#x27;t even heard of RAII and don&#x27;t use smart pointers or standard containers. What a nightmare.<p>It&#x27;s great to see C++ getting an ecosystem and Bjarne&#x27;s excellent writings help a lot.

The more I develop in C++, the more I wish I had a very restructure transpirer that would remove some of its most silly constructs or switch ite base defaults around.<p>Some examples: - making all constructors explicit and adding an implicit keyword instead for that rare case - automatically generated !=, &lt;=, &gt;= etc from == and &lt; (with an explicit override when you want to be silly) - removing some of the redundant syntaxes (const positioning, typedefs vs using etc - removing the class keyword

&gt;This document is a very early draft. It is inkorrekt, incompleat, and pµøoorly formatted.<p>It&#x27;s the little things in life that make it so great.

I must confess I am tired of all these guidelines. I mean I have learned C++ once, gone through the ordeal of learning all the best practices, memorizing all the gotchas etc. And now the language just got bigger. New features arrived along with new unexpected gotchas. Scott Meyers has written a new book and all is well. Except that the more C++ I write the more I yearn for something simpler with less arbitrary rules to memorize.

It&#x27;s posts like these that remind me how hard it is to write idiomatic&#x2F;correct C++, when compared to something like Python or Java.

I wonder how many of these could be implemented in clang tidy:<p><a href="http:&#x2F;&#x2F;clang.llvm.org&#x2F;extra&#x2F;clang-tidy&#x2F;index.html" rel="nofollow">http:&#x2F;&#x2F;clang.llvm.org&#x2F;extra&#x2F;clang-tidy&#x2F;index.html</a>

most of this is stuff Herb (and others) has been promoting for years...and It&#x27;s great to see it codified in one place.

I first started looking at this when Cfront by AT&amp;T Bell Telephone Laboratories came out. Let me know when the language stabilizes and maybe I&#x27;ll take a look at it again.

That&#x27;s what I really value about Go: gofmt and very good linting that embraces best practices. I know C++ is way more complex but for someone starting out it seems impossible to code in the &quot;right (tm)&quot; style.

started losing me at exceptions. the philosophy bit is quite nice, but seeing auto in the example... not for me. not even close.<p>its a shame we are ruining C++. can&#x27;t we just have something better... :&#x2F;

P.4 mentions using variant, but I couldn&#x27;t find any information on this. Does standard C++ have a built in variant now?<p>If so, could someone link me to a resource?