Anonymous user
Talk:Sokoban: Difference between revisions
→The Long C Version
(+ notes on long C version) |
|||
Line 29:
2) In some declarations "s" could be declared as pointing to const: <lang c>inline int deadlocked(state_t *s)
void unqueue_move(state_t *s)</lang>
: 1) You originally had <code>board = calloc(...); assert(board);</code>. This was done probably so it still runs with <code>cc -DNDEBUG</code>, but that's the wrong thing to do. <code>calloc</code> will return 0 if and only if there's no memory left, so you are asserting that allocation succeeded, which is a run time check as opposed to verifying contracts during debugging. If the runtime check is meaningful and should be performed, then <code>NDEBUG</code> shouldn't be set at all; if it ''may'' be set, then the valid check should have been <code>if (!board) {...}</code> instead of <code>assert</code>. I put the <code>assert</code> there to make <code>assert</code>ive people happy, personally I don't want it there at all. A failed alloc returns 0, which segfaults when you deref it, so you don't have the risk of putting data behind wrong pointers.
:2) For a library routine, putting <code>const</code> in front of a var gives some hint about the interface; init code may put <code>const</code> in read-only memory. Outside those two, <code>const</code> does absolutely nothing for the code. For routines used only locally, I don't really want to bother. Plus, <code>unqueue_move(state_t *)</code> can decl a const pointer, but not a pointer to const: it modifies data inside the struct. --[[User:Ledrug|Ledrug]] 20:29, 14 May 2012 (UTC)
| |||