You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The standard library specifies free to act as a nop when its argument is a NULL pointer. This gives us programmers a big convenience for error handling and similar situations where we don't need to add so many explicit branches, but rather count on free doing the right thing for us. Point being, my proposal is not exactly something new.
Tackling #182 in particular would create (or, rather, acknowledge) many new error paths that will require these free analogs to be called, and the current implementations also mean explicitly checking for NULL each time on each call place. This can become tedious, error prone and a cognitive load rapidly.
It can also help brevity on existing code.
Counterarguments would probably go around the extra branching: sometimes we simply know for certain our pointer won't be NULL. IMO this case shouldn't matter that much for performance for the following reasons:
Where operation count matters the most is in tight loops, and it's folklore already that you shouldn't allocate too much if you'll be discarding the buffer there. If you allocate it should be because you do need to keep the value afterwards, so how fast the free function is is not the central concern.
Particularly error paths, and specifically those related to memory allocation, should be considered exceptional, and thus have low priority when it comes to performance. You'd rather optimize for the more common case, specially if your trade off is simply an extra branch.
Thoughts?
The text was updated successfully, but these errors were encountered:
The standard library specifies
free
to act as anop
when its argument is aNULL
pointer. This gives us programmers a big convenience for error handling and similar situations where we don't need to add so many explicit branches, but rather count onfree
doing the right thing for us. Point being, my proposal is not exactly something new.Tackling #182 in particular would create (or, rather, acknowledge) many new error paths that will require these
free
analogs to be called, and the current implementations also mean explicitly checking forNULL
each time on each call place. This can become tedious, error prone and a cognitive load rapidly.It can also help brevity on existing code.
Counterarguments would probably go around the extra branching: sometimes we simply know for certain our pointer won't be
NULL
. IMO this case shouldn't matter that much for performance for the following reasons:free
function is is not the central concern.Thoughts?
The text was updated successfully, but these errors were encountered: