I’ve just purchased a license for Deleaker by Softanics. I found out about the tool from Bartek’s coding blog where he writes about the tool here.
I downloaded the trial edition and it found quite a few subtle issues in some of my unit test code. Nothing too serious, but stuff that other tools have missed. The run-time overhead doesn’t appear to be that great, my server tests still run at a reasonable speed and nothing fails because of the instrumentation.
I’ve been trying various static analysis tools on the C++ code of The Server Framework. I’ve now been using Resharper C++ quite regularly for over a year and I still use the Gimpel PC-Lint Plus Beta on a regular basis. I haven’t used CppDepend as much, mainly because once I’d fixed the issues that it raised, and that I decided I needed to fix, I pretty much left it alone. This is possibly because I run it as an external tool and I run both Resharper and PC-Lint as fully integrated Visual Studio extensions.
This is one of those ’note to self’ postings…
I have a VMWare box that uses bridged networking and has a static DHCP address that I use for a specific client’s testing as a db server. Every so often the virtual machine fails to connect to the network properly and ends up with a bogus ip address. I then spend ages trying to work out what’s going wrong…
This link, may help.
Enabling FILE_SKIP_COMPLETION_PORT_ON_SUCCESS on a handle associated with an I/O completion port can improve performance and reduce context switching by allowing the thread that calls the API that can complete asynchronously to handle the completion “inline” if the call can complete synchronously. This is especially useful for TCP reads when there’s already data in the network stack’s buffers, or writes when there is space in the buffers. Whilst there are design issues that must be taken into consideration before simply enabling this flag (beware recursion!
I’ve been looking at Resharper C++ by JetBrains for a while now and the trial period has finally run out. I immediately bought a license which shows how my feelings have changed about the product during the trial.
Initially I found that the tool got in my way too much, I still find it a little sluggish at times but I think that my initial tests were hurt by the fact that I was running multiple copies of Visual Studio (as is my way) with multiple large projects and generating code inspection reports in all of them at the same time… Well, that’s how I’d want to use it… Anyway, when limiting myself to one or two concurrent instances things were better.
I’ve been trying various static analysis tools on the C++ code of The Server Framework. So far I’m using Resharper C++ and the Gimpel PC-Lint Plus Beta on a regular basis and I’ve now added CppDepend into the loop.
Full disclosure. I have been given a CppDepend license.
As I’ve said before, whilst CppDepend is easy to get hold of, easy to install and “just works” I don’t find it that useful.
Previously on “Practical Testing”… Having just resurrected this series of blog posts about testing a non-trivial piece of real-world C++ code I’ve fixed a few bugs and done a bit of refactoring. There’s one more step required to bring the code in this article right up to date.
The timer queue that is the focus of these blog posts is part of The Server Framework. This body of code has been around since 2001 and has evolved to support new platforms and compilers.
I’ve been looking at Resharper C++ by JetBrains for a while now and I expect I’m nearing the end of the trial period. Initially I found it got in my way but slowly I think it’s training me to ignore the niggles and I’m finding the functionality quite compelling.
At present, I’m most interested in the “code inspection” report from Resharper. Comparing it to the similar functionality in PC-Lint and CppDepend, etc.
Previously on “Practical Testing”… I’ve just fixed a new bug in the timer queue and in doing so I updated the code used in the blog posts to the latest version that ships with The Server Framework. This code included two fixes that had been fixed some time ago and which I hadn’t documented here. They also lacked unit tests… Last time, I wrote tests for, and fixed, the first bug.
Previously on “Practical Testing”… I’ve just fixed a new bug in the timer queue and in doing so I updated the code used in the blog posts to the latest version that ships with The Server Framework. This code included two fixes that had been fixed some time ago and which I hadn’t documented here. They also lacked unit tests… In this episode I find and fix the first of these issues by writing a unit test that triggers the issue.
