Writing Bug-Free C/D Code

[janderson]

Henning Hasemann wrote:
> I just start a few little things.
> 
> 1.)
> Most of the bugs I had when starting with D where that I simply forgot
> to initialise members in the c'tor:
> 
> class Foo {
>   void foo() { ... };
> }
> 
> class Bar {
>   Foo myFoo;
>   void bar() {
>     myFoo.foo();
>   }
> }
> 
> Of course, because here myFoo is default initialised to null this always gives
> a segfault where myFoo is first being used in such a way,
> so it is very easy to track down (if you use a debugger at least).
> 
> But sometimes I'd find it nice if there was a way to tell D:
> Warn me at compile time if it is clear that some class instance members
> will be null.
> 
> Of course you must be able to tell D exceptions to this, as you will want
> to have a few members be null until later.
> 
> I have no good idea what this tool would syntactically look like or
> if it would make sense to have it a compiler switch or whatever.
> Probably the idea is almost bullsh*t nevertheless, because you get
> used to initialise your members after a short while.

C# will warn you if a variable is private and never used or never 
initialized.  Some C++ versions have warnings (which I always set as 
errors) that tells you if a variable in a function is never initialized.

That's a start at least.  Perhaps D could do the same.  In effect the 
private keyword becomes the checker for you.

[snip]

> 3.)
> Please change the implicit integral casting rules to be more c-like.
> This has been discussed here and I cant remember a good argument
> against casting only in such a way data doesnt get lost.
> (ie: int->float is okay, but float->int, or int->uint is not)
> I had errors that where very hard to track down, because somthing like
> (-1 * 4u) yields the unsigned int representation of -4 which is
> 4294967292, which is rather unintuitive when there is no explicit cast.

int->float, I don't agree this is ok however int->double is in my books. 
  Anything that has potential for data loss, you should have to 
explicitly cast.

I generally agree though.

> 
> I know, changing this might break some code, but I cant help considering
> code that relies on such implicit casting rules broken nevertheless.

Agreed.

> Henning
>