I am loving cross-platform development with Qt, it’s robust and logical and leads to amazing native desktop apps. Before getting started, I expected that there would be lots of platform-specific hackery required, and going cross-platform would slow down the end product by 20-30%. But Qt is so reliable, and well-laid-out, and provides so much more than just lowest-common-denominator functionality, that I’m finding it to be much faster than, e.g., developing a desktop app with C# or Java.
Another reason it is giving me leverage: [n] compilers are better than one.
I just hit a bug in Visual Studio with some STL code. My comparison operator was throwing up because one of the objects in the array I was searching had bad data. But you wouldn’t know it from Visual Studio, giving me an iterator error in their STL code, with no stack trace:
__thiscall _Lockit::~_Lockit()
{ // unlock the mutex
if (_Locktype < MAX_LOCK)
_Mtxunlock(&mtx[_Locktype]); <- HERE
}I spent some time trying to isolate the upstream cause - I could have spent hours - until I had an inspiration: this kind of unhelpful compiler error information happens in just about every compiler I've used, about 5% of the time - but it happens in different ways in different compilers. So I fired up the code in Qt Creator in OS X, and gcc showed me the error along with the line of code where the array search had begun. Bingo. Then I started looking through the values in the debugger, to find the bad data. But again, I realized that Visual Studio has much better unwinding of debug variables in its debugger, so I looked up the line of code there, set a breakpoint, stepped over it and confirmed that was where I was getting the error - yep! Then I could easily dig way down into my debug variables in style.
Moral is: don't forget to take full advantage of each of your tools. Save the headbanging for concerts.
For such issues, download symbols in Visual Studio, I was having the same exception, I downloaded the symbols and was able to identify the exact point of error
Thanks Saba, good point. I thought I already had the debug symbols in place – the code you see above is Microsoft’s – but it’s excellent general advice. Always better to have more information when debugging. I’ll have to double check that.
I didn’t have a deep stack trace on this one because it was one of those very shallow (and cryptic) STL type errors the compiler hits when running through template code. They are typically a challenge for all compilers to report to the developer in a useful way. Again, more information is always better, and multiple compilers can give that to you! 🙂