3 ms·
Yes, you're right about delete. I still do it, and will still do it, though. I have my reasons. No, I wouldn't redefine free(), I'd use my own terminology, but
by klingonopera 8y ago
Yes, you're right about delete. I still do it, and will still do it, though. I have my reasons.
No, I wouldn't redefine free(), I'd use my own terminology, but I'd search the code for it and replace it verbatim, and seeing that it apparently is standard practice for both C++ and C to null-check their pointers before deletion, I have all the more reason to do so, because my code assumed that it didn't.
Delete shouldn't null check, it should delete memory at location, no matter what address. It should be up to the implementation to check that pointer is valid.
EDIT: I should maybe add that the next line of code is in my case almost always "pointer = NULL" following "free(pointer)". The null-check is not just a technicality of checking of pointer-validity ("Pointer not null?"), but also code-syntactics ("Has this item not been deleted yet?").
- shaklee3 8y agoWhat are your reasons?
- klingonopera 8y agoThey're in the edit. Precedence of code-flow indicators (I said "code-syntactics" in my original quote, that's wrong, sorry) are more important to me, than keeping away redundancies. What I am advocating for, is "Before you work on a pointer, check its validity", regardless of what follows after. It's just a general guideline, do it, even if you think it's senseless and redundant. Ever since I've adopted those basics, I've virtually reduced my problems with pointers to zero. There's danger in accidentally not null-checking, but none in accidentally double-checking. Therefore, the implementation should take care of this (too), or at least consider implications. I can't really take risks there. The original author of the article is asking me to "stop" this, which could put a lot of things at stake. No, thank you.