Re:Const all the things?
by nemetroid on Monday January 24, 2022 @07:07AM
(#30056628)
It'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.
[ Parent
| on HN ]
> 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.
> 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.
Re:Const all the things?
by stevenhuang on Monday January 24, 2022 @08:41PM
(#30066791)
But 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.
> it's more important to have these null checks on a library's public interfaces
No it isn't.
Re:Const all the things?
by stevenhuang on Thursday January 27, 2022 @05:34AM
(#30098698)
Library authors and users would disagree with you.