Why you should always dispose DataGridViews

Because your application can crash otherwise, that’s why. While it’s always a good idea to explicitly dispose everything that is disposable, we can usually get away without disposing UI controls because a. Complex controls aren’t created often – a single instance is often reused. b. The finalizer kicks in and saves the day. If you’re creating multiple instances of a System.Windows.Forms.DataGridView, however, watch out, because (b) doesn’t happen at all if you don’t call Dispose or otherwise cause the control to be destroyed. When debugging a software crash dump recently, I found that the crash occurred because there was an … Continue reading Why you should always dispose DataGridViews

When a C++ destructor did not run – Part 2

In the previous post, we saw that linking a C++ static library compiled with /EHs to a mixed mode application prevented the destructor from running when an exception is thrown. Here’s the sample project that demonstrates the behavior, in case you aren’t convinced. This is the code inside the library. 1: C::C() 2: { 3: cout << "Constructed" << endl; 4: } 5:  6: C::~C() 7: { 8: cout << "Destructed" << endl; 9: } 10:  11: void SomeFunc() 12: { 13: C c; 14: throw std::exception("Gone"); 15: } And this is the code consuming the library. 1: int main(array<System::String … Continue reading When a C++ destructor did not run – Part 2

When a C++ destructor did not run – Part 1

Consider this piece of C++ code. 1: using namespace std; 2:  3: class C 4: { 5: public: 6: C() 7: { 8: cout << “Constructed”; 9: } 10: ~C() 11: { 12: cout << “Destructed”; 13: } 14: }; 15:  16: void SomeFunc() 17: { 18: C c; 19: throw std::exception(“Gone”); 20: } If you know any C++ at all, you’ll know that when SomeFunc returns, both “Constructed” and “Destructed” will be printed to the console. That is because C++ guarantees that the destructor of an object created on the stack will always run when control leaves the scope, … Continue reading When a C++ destructor did not run – Part 1

When what you set is not what you get : SetEnvironmentVariable and getenv

Mixing SetEnvironmentVariable and getenv is asking for trouble, as we recently found to our dismay (and exasperation!). It took some serious debugging to figure out the actual problem – let’s see if you can figure it out. Here’s some C++/CLI code that uses getenv to read the value of an environment variable and print it to the console. 1: public ref class EnvironmentVariablePrinter 2: { 3: public: 4: void PrintEnv(String ^key) 5: { 6: IntPtr ptr = Marshal::StringToHGlobalAnsi(key); 7: const char *ckey = (const char *)ptr.ToPointer(); 8: const char *cval = getenv(ckey); 9: string val = cval == NULL ? … Continue reading When what you set is not what you get : SetEnvironmentVariable and getenv