<story><title>Modern C for C++ peeps (2019)</title><url>https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.html</url></story><parent_chain><item><author>WalterBright</author><text>&amp;gt; Enable all warnings!&lt;p&gt;The trouble I&amp;#x27;ve run into with that is different compilers have different warnings, sometimes they are mutually contradictory, so it is not possible to have portable code that doesn&amp;#x27;t trigger warnings in one compiler or another.&lt;p&gt;I.e. the general problem with warnings is the language gets balkanized into multiple competing and incompatible dialects.&lt;p&gt;What &lt;i&gt;should&lt;/i&gt; happen is to carefully examine the warnings, and adopt the best into the language Standard as errors.&lt;p&gt;For example:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if (a &amp;lt; b &amp;lt; c)
&lt;/code&gt;&lt;/pre&gt;
That is pretty much 100% a bug in the code. Just make it illegal already. D does.&lt;p&gt;For another:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    for (i = 0; i &amp;lt; 10; ++i);
    {
        ...
    }
&lt;/code&gt;&lt;/pre&gt;
Long ago, an expert C programmer came to me once and said he&amp;#x27;d spent all day trying to figure out why his loop only executed once. I pointed to the semicolon. He sighed. I put a warning for that in the compiler. I noticed that other compilers eventually did, too.&lt;p&gt;In D, it&amp;#x27;s an error.&lt;p&gt;A third example:&lt;p&gt;In the Joint Fighter coding standard, it says don&amp;#x27;t use `l` as an integer suffixe, as in `124l`, because in many fonts it looks like `1241`. Solution: D does not allow `l` as a suffix. There&amp;#x27;s is no reason to support that suffix. No reason to put it in coding standard. Do the world a favor, just make it illegal. Done!</text></item></parent_chain><comment><author>pornel</author><text>The warnings problem is nicely solved in Rust:&lt;p&gt;• There&amp;#x27;s a built-in way to silence specific warnings for specific portions of the code. When the compiler is wrong, instead of obfuscating the code to hide it from the compiler, you can directly mark &amp;quot;I know what I&amp;#x27;m doing&amp;quot;. &lt;i&gt;Standard&lt;/i&gt; C can&amp;#x27;t do it, and compiler-specific #pragmas are much more clunky.&lt;p&gt;• Builds of dependencies automatically suppress lints, so builds with a -Werror equivalent won&amp;#x27;t break on someone else&amp;#x27;s code (that you may not be able to fix), just because your compiler has added new lints.</text></comment>
<story><title>Modern C for C++ peeps (2019)</title><url>https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.html</url></story><parent_chain><item><author>WalterBright</author><text>&amp;gt; Enable all warnings!&lt;p&gt;The trouble I&amp;#x27;ve run into with that is different compilers have different warnings, sometimes they are mutually contradictory, so it is not possible to have portable code that doesn&amp;#x27;t trigger warnings in one compiler or another.&lt;p&gt;I.e. the general problem with warnings is the language gets balkanized into multiple competing and incompatible dialects.&lt;p&gt;What &lt;i&gt;should&lt;/i&gt; happen is to carefully examine the warnings, and adopt the best into the language Standard as errors.&lt;p&gt;For example:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    if (a &amp;lt; b &amp;lt; c)
&lt;/code&gt;&lt;/pre&gt;
That is pretty much 100% a bug in the code. Just make it illegal already. D does.&lt;p&gt;For another:&lt;p&gt;&lt;pre&gt;&lt;code&gt;    for (i = 0; i &amp;lt; 10; ++i);
    {
        ...
    }
&lt;/code&gt;&lt;/pre&gt;
Long ago, an expert C programmer came to me once and said he&amp;#x27;d spent all day trying to figure out why his loop only executed once. I pointed to the semicolon. He sighed. I put a warning for that in the compiler. I noticed that other compilers eventually did, too.&lt;p&gt;In D, it&amp;#x27;s an error.&lt;p&gt;A third example:&lt;p&gt;In the Joint Fighter coding standard, it says don&amp;#x27;t use `l` as an integer suffixe, as in `124l`, because in many fonts it looks like `1241`. Solution: D does not allow `l` as a suffix. There&amp;#x27;s is no reason to support that suffix. No reason to put it in coding standard. Do the world a favor, just make it illegal. Done!</text></item></parent_chain><comment><author>tialaramex</author><text>&amp;gt; (a &amp;lt; b &amp;lt; c)&lt;p&gt;On the other hand the intention (assuming numerical types) is clear, if people keep doing this, what machine code is emitted by common compilers for the &amp;quot;best&amp;quot; way to express this? And how about for the idiomatic way to express it? Perhaps the insight, if it&amp;#x27;s common, is that we should provide a nice way to do this which emits efficient machine code.&lt;p&gt;Rust says &amp;quot;chained comparison&amp;quot; is forbidden, so it knows what we&amp;#x27;re going for here, and indeed it suggests you might want (a &amp;lt; b) &amp;amp;&amp;amp; (b &amp;lt; c) which is how I&amp;#x27;d write this, but of course the opposite could be faster, as perhaps could ((a+1)..c).contains(&amp;amp;b) and either may make more sense in context of the usage.</text></comment>