We cannot know if null is valid output or not. The first quick win I wish you to have is to change your coding conventions so null is not a valid input or output to a function. Or, at least when you decide that null is a valid output, use the Option type.
There are some tools which can help to enforce this convention like ReSharper and NullGuard. I would love to know what you think. Are you going to embrace this convention? And if not, why? If you encounter a scenario in which you think returning null is the right design choice, or the patterns I suggested are not good, I would love to know. If this article was helpful, tweet it. Learn to code for free. Get started.
Forum Donate. The reason: developers use nulls too often. So where do all those NULLs come from? A bug can cause them never to be reassigned. Hierarchical models In hierarchical models, we usually can navigate up and down. Find functions When we want to find an entity by criteria in a collection, we return null as a way to say the entity was not found.
What are the problems with using nulls? It will blow up. Eventually… The code in which the NullPointerException is raised can be very far from where the bug is. I am happy now but I will blow up eventually.
It also makes the code branched and ugly? Missing non-nullable reference types in C and Java In C and Java reference types can always point to null.
So what should we do? Listen to Uncle Bob Robert C. But how? Using the option type The option type is a different way to represent an optional value. A straightforward approach is to replace a reference that can be null by logic with this type: Splitting the function into two Each function that returns null will be converted to two functions.
Nice one!!! Nish let me ask something more about pointer. Sarath- uuuuuuuhhhh yeah. While the standard dictates that you can delete a null pointer with no ill side effects, if you pass something other than NULL to delete or delete[]- those functions will attempt operate on that value, even if means letting the smoke out of all the chips on your motherboard.
IOW yes, you have to set the pointer to NULL after calling delete if you plan on randomly passing that pointer to delete again. The laws are of course, tounge in cheek. Used properly, smart pointers can make a world of difference. The coming additions in TR1 should be a boon once the community knowledge has embraced them. Thanks alot for a reply. You are commenting using your WordPress. You are commenting using your Google account. You are commenting using your Twitter account. You are commenting using your Facebook account.
Improve this answer. Note that there still can be several other pointers pointing to the same object even if you set one to NULL on deletion. In most cases in my code, the pointer goes out of scope once it's been deleted. Much safer than merely setting it to NULL. A very god practice is not setting the pointer to NULL after delete. Setting a pointer to NULL after deleting it masquerades memory allocation errors, which is a very bad thing.
A program that is correct does not delete a pointer twice, and a program that does delete a pointer twice should crash. Alice: It is irrelevant what the standard says in that respect. The standard defined deleting a null pointer being valid for some absurd reason 30 years ago, so it is legal most likely a C legacy. But deleting the same pointer twice even after changing its bit pattern is still a serious program error. Not by the wording of the standard, but by program logic and ownership.
As is deleting a null pointer, since the null pointer corresponds to no object , so nothing could possibly be deleted. A program must exactly know if an object is valid and who owns it, and when it can be deleted. Damon However, despite these abrogations of your draconian ownership rules, lock free structures are provably more robust than lock based ones.
And yes, my co-workers do indeed love me for the enhanced execution profile these structures provide and the rigorous thread safety they maintain, which allow easier to reason about code great for maintenance. However, none of this nor your implied personal attack have to do with any definition of correctness, validity, or ownership.
What you propose is a good rule of thumb, but it is not a universal law nor is it enshrined in the standard. Show 27 more comments. Chubsdad Chubsdad I would really like this answer for its citations if it didn't intentionally introduce inefficiency in non-optimized code.
As the accepted answer states, deletion of a null pointer is a no-op. Therefore, checking if a pointer is null before deleting it is completely extraneous. Add a comment. Yes it is safe. Jonathan Leffler Jonathan Leffler k gold badges silver badges bronze badges. I had to read that a few times to make sense of it.
You must mean initializing them to zero at the top of the method, or during it, not at the tail, surely? Otherwise you would just remove both the zeroing and the delete. I've not shown any block structure or jumps, but the delete[] operations at the end are safe because of the initializations at the start.
If something jumped to the end after x1 was allocated and before y1 was allocated and there was no initialization of y1 , then there'd be undefined behaviour — and while the code could test for nullness of x1 and y1 before the deletions, there is no need to do so. It's nice to know it is safe.
0コメント