• bearophile (22/55) Jun 11 2012 An article, "Eight C++ programming mistakes the compiler won't
• Iain Buclaw (17/68) Jun 11 2012 This is a valid case that should be easy enough to detect. Though I

"bearophile" <bearophileHUGS lycos.com> writes:

An article, "Eight C++ programming mistakes the compiler won't 
catch":
http://pixelstech.net/article/index.php?id=1333893320

Its Reddit thread:
http://www.reddit.com/r/cpp/comments/s0o99/eight_c_programming_mistakes_the_compiler_wont/


Some quotations from the article, valid for D too:

 2) Integer division
 
 Many new programmers attempt to do the following:
 
 int nX = 7;
 int nY = 2;
 float fValue = nX / nY;  // fValue = 3 (not 3.5!)
 
 The underlying assumption here is that nX / nY will result in a
 floating point division because the result is being assigned to
 a floating point value. However, this is not the case.

GCC with -Wconversion finds that problem, but maybe with too much 
noise:

int main() {
     float fX = 7.0;
     int nY = 2;
     float fValue = fX / nY;
     return 0;
}

...>gcc -Wconversion test.c -o test
test.c: In function 'main':
test.c:4:5: warning: conversion to 'float' from 'int' may alter 
its value [-Wconversion]



 4) Mixing signed and unsigned values
 
 int nX;
 unsigned int nY;
 
 if (nX - nY < 0)
     // do something

GCC with -Wconversion finds it.
There are more interesting cases with mixing short with uint, etc.



 6) Side effects in compound expressions or function calls
 
 int foo(int x)
 {
 return x;
 }
 
 int main()
 {
     int x = 5;
     std::cout << foo(x) * foo(++x);
 }
 
 A good rule of thumb is to put any operator that
 causes a side effect in it’s own statement.

Bye,
bearophile

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 11 June 2012 12:59, bearophile <bearophileHUGS lycos.com> wrote:
 An article, "Eight C++ programming mistakes the compiler won't catch":
 http://pixelstech.net/article/index.php?id=3D1333893320

 Its Reddit thread:
 http://www.reddit.com/r/cpp/comments/s0o99/eight_c_programming_mistakes_t=

he_compiler_wont/
 Some quotations from the article, valid for D too:

 2) Integer division

 Many new programmers attempt to do the following:

 int nX =3D 7;
 int nY =3D 2;
 float fValue =3D nX / nY; =A0// fValue =3D 3 (not 3.5!)

 The underlying assumption here is that nX / nY will result in a
 floating point division because the result is being assigned to
 a floating point value. However, this is not the case.


 GCC with -Wconversion finds that problem, but maybe with too much noise:

 int main() {
 =A0 =A0float fX =3D 7.0;
 =A0 =A0int nY =3D 2;
 =A0 =A0float fValue =3D fX / nY;
 =A0 =A0return 0;
 }

 ...>gcc -Wconversion test.c -o test
 test.c: In function 'main':
 test.c:4:5: warning: conversion to 'float' from 'int' may alter its value
 [-Wconversion]

This is a valid case that should be easy enough to detect.  Though I
will not be able to say for definite without looking under the hood.


 4) Mixing signed and unsigned values

 int nX;
 unsigned int nY;

 if (nX - nY < 0)
 =A0 =A0// do something


 GCC with -Wconversion finds it.
 There are more interesting cases with mixing short with uint, etc.

This was something that was done in early gdc D1. But the frontend
codegen now actually makes this impossible to detect in the backend
with the implicit cast()'s it puts in.

There was a pull request for this that was accepted, then taken out
because it broke too much of existing code left and right.


 6) Side effects in compound expressions or function calls

 int foo(int x)
 {
 return x;
 }

 int main()
 {
 =A0 =A0int x =3D 5;
 =A0 =A0std::cout << foo(x) * foo(++x);
 }

 A good rule of thumb is to put any operator that
 causes a side effect in it=92s own statement.


Generally, compound statements and function parameters are evaluated
from left to right as the prime order of evaluation.  extern(C)
functions parameters are a notable exception of this and may not
follow the same convention, ie, in code like:  foo( bar(), baz() );
baz() may be evaluated first.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';