|
A Postmortem of Game Programming with Digital Mars’ D Programming Language
by Jonathan Breuer
Beginning work : Dir2
I started by grabbing the “hello world” or “word count” app, I forget which. I copied it from \samples to \projects, changed the documentation to reflect that I was now its author and started work.
I’ve wanted a nice directory diff tool for a while now. I realize that there are many of these available, but I’ve always been busy when I needed one, I’m too cheap to spend the $20 for a commercial one and too lazy to search for a good open source one. Besides, not finding a good tool has left me this opportunity to write one. When I got to the hotel, I immediately copied my 1000 crappy 80’s games CD on to the computer and Windows copy barfed after 975 of them. This left me with no good way of knowing which of the 100,000 files the problem was, but I tried to manage. This is a perfect illustration of one application of my directory diff tool. I want to be able to repair large directory copies, not merely delete and retry.
The first job is to write a tool which can list all files recursively across a folder and report the findings. D has a function with this functionality; listdir. I immediately encountered the unacknowledged recursive NTFS listdir bug. In the D archives, there’s a complaint that listdir doesn’t always recurse. The response is the classic “It works on my machine." On the hotel computer, I had this same problem. I don’t know why, but I had to write a listdir which could recurse. (I later encountered a copy-file problem: std.file.write( out_filename, std.file.read(in_filename)); worked fine, but copy_file(out_filename, in_filename); didn’t. Ah, turns out that the parameters are SRCPATH, DESTPATH – no wonder the file didn’t exist.)
Complaint #3: The D compile errors are obscure, occasionally incorrect, and happen in a multi-pass manner.
It’s probably a good thing that the D compiler is a multi-pass thing. There are no header files and no predeclerations. However, because the compiler is multi-pass, it tends to barf on an early pass before moving on to a next pass. I think there are 3ish compile passes and 1 link pass. If your code is significantly messed up, you will bring your number of errors down past 1 several times only to see new sets of errors crop up. (It could also be that I just caused more errors by fixing one) The errors usually refer to the line that failed, but not always. Factoring out code and block-commenting code seemed to be required. I had a problem with using an anonymous enum which reported the error on the declaration line, not on the usage line.
Complaint #4: The D run time errors are obscure.
When debugging in MSVC++, you get the line, call stack and all other information you could want about the failing code. When the program crashes, it would be nice to get a line number, a function name, or the option to debug the problem. D just dies to the command line with an error message and no context. The same problem applies to the asserts. MSVC++ asserts are continuable, possibly an implementation failure, since asserts should be fixed. It would be nice to be able to continue past asserts to get a comprehensive list of failures, but I recognize the point.
Being able to toss strings and arrays of objects around as parameters and return values without worrying about the memory leaks is really nice. In C++ you must always be aware of whose responsibility an object is. D is really nice about allowing you to pass references (low overhead on function calls) around without worrying about later releasing the objects or performing expensive copies.
DERELICT game library
|
Gen Con Australia
