Richard Hale Shaw writes on and his conclusion is “it’s too confusing” and “I’d suggest not even using using statements”. I think that position is a little harsh, but I think that the main problem is that using tries to provide support for “scoped locals” and it doesn’t do it well enough.
Richard refers to this C# idiom for deterministic resource release.
using(MyObj obj = new MyObj()) { obj.DoStuff(); } The point being that although the memory that MyObj uses will not be reclaimed until the garbage collector runs other resources that MyObj uses could be released at a precisely defined point via an implementation of IDisposable.
Jeff Darcy over at “Canned Platypus” writes about “How to add locking to a program”. He laments the lack of a reasonably priced deadlock detection tool. I assume, from his backgrond, that he’s interested in an Linux tool, so my deadlock detection tool wont help him much but it’s good to know that it’s not just me that thinks such a tool would be useful…
Jeff links to some expensive static code analysis tools that do deadlock detection.
Ned Batchelder has written about the code he uses to get a call stack out of a windows program (thanks for the link Barry). I’ve added a snippet of the code I use as a comment to his post.
Note: the deadlock detector mentioned in this blog post is now available for download from www.lockexplorer.com.
I started looking into working with windows call stacks a while ago when I was working on my deadlock detection tool.
It seems that Jay Allen has shutdown both MT-Blacklist and the ‘master blacklist’ due to bandwidth problems caused by either a denial of service attack or inconsiderate developers.
Jay hosted a regularly updated file of regular expressions that powered the MT-Blacklist comment spam blocking add-in for Movable Type 2.x. He also published a changes feed that made it easy for others to update their own black lists using the master feed.
Jeff Darcy over at “Canned Platypus” has written a nice piece on specifications and how Linus has got it wrong.
Any post that contains the phrase: "… who wouldn’t know good code if it got into a robot and literally bit them …" has to be worth a read, and as Jeff says, there’s a vast difference between a truly good specification and a bad one. Good specs are worth their weight in gold and can be a joy to work from.
Noel Llopis over on “Games from Within” has written a nice rebuttal to my Asserts are evil post and the follow up.
I think it’s probably about time to wrap this up ;) So, here’s what I’ve learned…
[Updated: 24th October - there is an interesting discussion still going on over in the comments on Noel’s post…]
The reasons that I stated for disliking the use of assert in C++ were as follows:
A collection of blog posts that I flagged for follow up this week.
Aaron Margosis has a blog which explains why you shouldn’t run as an Admin user on Windows systems and how to work around the problems that you might face when you start running as non admin. This table of contents post is a good jumping off point if you’re interested in running as a normal user.
Jeff Darcy on designing interfaces.
I’m sure you’re all getting bored on my views on using Assert in modern C++ code by now, I’ll try and make this the last one. Last time, I asked if anyone had what they’d consider to be an example of the use of assert in C++ where the usage was valid given my objections to assert. Mark updated this recent posting on the subject to include a link to Raymond Chen’s blog where Raymond is discussing COM object destruction and uses an assert… Given that everyone knows that Raymond is a seriously good programmer doesn’t his use of assert validate the position of those who disagree with me.
Mark responded to Barry’s response to my post on Assert. Barry then responded to Mark and Kim and I added a little more in the comments. I did have some more to say, but Barry’s said most of it…
Anyway, so far only Vagn Johansen and the guru’s over on comp.lang.c++.moderated disagree with us… Anyone else fancy joining in? What I’d like to see is for someone who’s defending to show a situation where the alternatives that we’re proposing don’t work; but lets try and stay out of the realms of “what if the compiler is broken” and “what if there’s a hardware fault” if we can…
Alexis Smirnov has just written a piece on why you shouldn’t try and use STL’s map::operator[] to find out if a map contains a particular element. It’s probably common knowledge for most people using STL, but it’s worth repeating for those new to the std::map interface.
