StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<h2>Remember the <code>if(NULL == p)</code> pattern ?</h2> <p>There are a lot of people who will tell a "you must write code like this":</p> <pre><code>if(NULL == myPointer) { /* etc. */ } </code></pre> <p>instead of</p> <pre><code>if(myPointer == NULL) { /* etc. */ } </code></pre> <p>The rationale is that the first version will protect the coder from code typos like replacing "==" with "=" (because it is forbidden to assign a value to a constant value).</p> <p>The following can then be considered an extension of this limited <code>if(NULL == p)</code> pattern:</p> <h2>Why const-ing params can be useful for the coder</h2> <p>No matter the type, "const" is a qualifier that I add to say to the compiler that "<i>I don't expect the value to change, so send me a compiler error message should I lie</i>".</p> <p>For example, this kind of code will show when the compiler can help me:</p> <pre><code>void bar_const(const int & param) ; void bar_non_const(int & param) ; void foo(const int param) { const int value = getValue() ; if(param == 25) { /* Etc. */ } // Ok if(value == 25) { /* Etc. */ } // Ok if(param = 25) { /* Etc. */ } // COMPILE ERROR if(value = 25) { /* Etc. */ } // COMPILE ERROR bar_const(param) ; // Ok bar_const(value) ; // Ok bar_non_const(param) ; // COMPILE ERROR bar_non_const(value) ; // COMPILE ERROR // Here, I expect to continue to use "param" and "value" with // their original values, so having some random code or error // change it would be a runtime error... } </code></pre> <p>In those cases, which can happen either by code typo or some mistake in function call, will be caught by the compiler, which is a <i>good thing</i>.</p> <h2>Why it is not important for the user</h2> <p>It happens that:</p> <pre><code>void foo(const int param) ; </code></pre> <p>and:</p> <pre><code>void foo(int param) ; </code></pre> <p>have the same signature.</p> <p>This is a good thing, because, if the function implementer decides a parameter is considered const inside the function, the user should not, and does not need to know it.</p> <p>This explains why my functions declarations to the users omit the const:</p> <pre><code>void bar(int param, const char * p) ; </code></pre> <p>to keep the declaration as clear as possible, while my function definition adds it as much as possible:</p> <pre><code>void bar(const int param, const char * const p) { // etc. } </code></pre> <p>to make my code as robust as possible.</p> <h2>Why in the real world, it <i>could</i> break</h2> <p>I was bitten by my pattern, though.</p> <p>On some broken compiler that will remain anonymous (whose name starts with "<i>Sol</i>" and ends with "<i>aris CC</i>"), the two signatures above can be considered as different (depending on context), and thus, the runtime link will <i>perhaps</i> fail.</p> <p>As the project was compiled on a Unix platforms too (Linux and Solaris), on those platforms, undefined symbols were left to be resolved at execution, which provoked a runtime error in the middle of the execution of the process.</p> <p>So, because I had to support the said compiler, I ended polluting even my headers with consted prototypes.</p> <p>But I still nevertheless consider this pattern of adding const in the function definition a good one.</p> <p>Note: Sun Microsystems even had the balls to hide their broken mangling with an "<i>it is evil pattern anyway so you should not use it</i>" declaration. see <a href="http://docs.oracle.com/cd/E19059-01/stud.9/817-6698/Ch1.Intro.html#71468" rel="noreferrer">http://docs.oracle.com/cd/E19059-01/stud.9/817-6698/Ch1.Intro.html#71468</a></p> <h2>One last note</h2> <p>It must be noted that Bjarne Stroustrup seems to be have been opposed to considering <code>void foo(int)</code> the same prototype as <code>void foo(const int)</code>:</p> <blockquote> <p>Not every feature accepted is in my opinion an improvement, though. For example, [...] the rule that void f(T) and void f(const T) denote the same function (proposed by Tom Plum for C compatibility reasons) [have] the dubious distinction of having been voted into C++ “over my dead body”.</p> </blockquote> <p>Source: Bjarne Stroustrup<br /> <b>Evolving a language in and for the real world: C++ 1991-2006</b>, <i>5. Language Features: 1991-1998</i>, p21.<br /> <a href="http://www.stroustrup.com/hopl-almost-final.pdf" rel="noreferrer">http://www.stroustrup.com/hopl-almost-final.pdf</a></p> <p>This is amusing to consider Herb Sutter offers the opposite viewpoint:</p> <blockquote> <p><b>Guideline:</b> Avoid const pass-by-value parameters in function declarations. Still make the parameter const in the same function's definition if it won't be modified.</p> </blockquote> <p>Source: Herb Sutter<br /> <b>Exceptional C++</b>, <i>Item 43: Const-Correctness</i>, p177-178.<br /></p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload