On Monday, 13 June 2016 at 08:49:55 UTC, Guillaume Piolat wrote:
This thing helps with getting rid of such bugs.
I suppose. The real cause of the bugs is not destructors I think, but memory corruption. Since frees (and double-frees) are deferred so long, it's just impossible to even guess at where the double destruction happened, or when you dereferenced a null pointer and D didn't catch that... again.
For those bugs, it would really help to know which objects are being freed, so you can check whether you accidentally forgot to initialize them or whatnot. Debugging their destructors is not the issue, and if it were I could just add a break inside the destructor itself.
Having a non-trivial destructor called by the GC, and relying on it, is imho an error at best, should always be manual.
I'd tend to agree. The reason I was using destructors at all is because I was using an SQL database. Those things like to act like whole global environments, where it's cheaper for you to create two tables within the same database than to have two databases open simultaneously, so usually when working with SQL I will make the database a global object, initialized on demand. Since there is *always* a database object, you can write code that can be optimized at compile-time, instead of code that runs conditionally at runtime, on the worthless check of whether it gets passed a database object or not.
So, the only problem is if the database is guaranteed to be open and usable anywhere in your code, when do you close it?
What I do is explicitly close it, then add a close() in the destructor with a warning. And then I run into GC errors... despite the only destructor in my entire program finishing without error.
