3 ms·
> Using pointers is terrible because now you have to add a check for null inside your function, as its API contract says "I can accept null values", while refer
by quotemstr 5y ago
> Using pointers is terrible because now you have to add a check for null inside your function, as its API contract says "I can accept null values", while references make it clear that it does not make sense to call if you don't have a correct object to pass it.
You need no such NULL check. Specify as part of the function's contract that a pointer be non-NULL: if a caller breaks the contract, behavior is undefined. An unexpected NULL is just like any other violation of the function's contract: a programming error.
Spell out the contract in the function's documentation. A contract is more than the signature. There is absolutely no need for a runtime check (certain special cases aside) to enforce function contracts.
In some cases, assert()ing that a parameter that is expected to be non-NULL is in fact non-NULL can be useful --- but you don't need such checks for correctness of the program, and use of assertions in general ought to be a matter of taste and discretion.
Knee-jerk, automatic checking by random internal functions of a module of pointer parameters for NULL in every single place suggests that the author doesn't fully comprehend the concept of interface contracts generally.
- nemetroid 5y agoIt's wildly useful to have interface contracts that can be verified by the compiler. In my experience this benefit of using pointers (vs references) only when the argument is optional way outweighs the drawback of not seeing an '&' at the call site.
- quotemstr 5y ago> In my experience this benefit of using pointers (vs references) only when the argument is optional way outweighs the drawback of not seeing an '&' at the call site. Maybe so. Reasonable people differ on this subject. My point is different: it's just not true that if a parameter is a pointer, then as a general requirement you have to check at runtime whether that pointer is non-NULL. It drives me nuts when I see these checks sprinkled throughout a codebase.
- nemetroid 5y ago> My point is different: it's just not true that if a parameter is a pointer, then as a general requirement you have to check at runtime whether that pointer is non-NULL. It drives me nuts when I see these checks sprinkled throughout a codebase. My point is that if you only ever use pointer arguments to indicate that the argument is optional, then the checks are required.
- stevenhuang 5y agoBut it is a reasonable rule, hence it being a general requirement in a lot of places. More nuanced, it's more important to have these null checks on a library's public interfaces than a library's private interfaces. Private interfaces can do with asserts for null check.
- quotemstr 5y ago> it's more important to have these null checks on a library's public interfaces No it isn't.
- stevenhuang 5y agoLibrary authors and users would disagree with you.
- bigbillheck 5y ago> Spell out the contract in the function's documentation The sibling subthread is all about people not wanting to read the function's documentation.
- bluGill 5y agoI would love to have compiler enforced contracts. However I'm not sure how to make that happen or even if it is technically possible. The current contracts proposal is a step in the right direction, but just barely a step and I'm not sure if it can go far enough. Until then I avoid adding undefined behavior to my code for good reasons.