Writing Bug-Free C/D Code

Daniel Keep daniel.keep.lists at gmail.com
Mon Mar 19 01:46:50 PDT 2007



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.

You do get used to it, and you're right: how exactly could a tool tell
the difference between "accidentally null" and "deliberately null"?

I've found, actually, that with type inference I almost never get this
problem.  Nowadays, I instinctively write the above as "auto myFoo = new
Foo;".  If I get to the end of the line, and haven't actually mentioned
a type anywhere, that's a good signal I've forgotten something :P  It
also helps that you can't declare an auto variable without initialising it.

> 2.)
> Another thing would be easy support for stack traced exceptions.
> I tried flectioned last weak or so (just for this purpose) but it
> didnt want to compile with my code (I think I was still on dmd-1.007 so
> it might have been a bug there). I think STE's are of use
> to many developers so they should be put into phobos or so.

I agree that more informative exceptions would be fantastic.

> 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.

It's unintuitive because you're asking the compiler to perform a
nonsensical operation: multiplication between two partially disjoint sets.

It's a bit like complaining that (3 * "2") doesn't work in D.  In PHP,
it results in 6, in Python, it results in "222".  Which one's right?

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

This is, in my opinion, a really bad idea.  You're basically saying that
the compiler should never complain if an operation *destroys data*.
What's more, it's these sorts of destructive implicit casts that are
very difficult to track down.

The root problem here is that you're trying to mix signed and unsigned
operations together, and expecting a signed result.  My personal rule of
thumb is: never, ever get signed/unsigned types within five kilometres
of each other.  If you think something is signed, but aren't sure,
assert it!

I actually think a better solution would be to add an Integer type to D:
one that actually, really, truly works like an integer, and not a member
of Z_{2^32} :P

> Henning
> 

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/



More information about the Digitalmars-d mailing list