zakarya/puzzles
1
0
Fork 0
mirror of git://git.tartarus.org/simon/puzzles.git synced 2025-04-20 23:51:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

grid.c: allocate face/edge/dot arrays incrementally.

Browse Source 
Previously, the 'faces', 'edges' and 'dots' arrays in a grid structure
were arrays of actual grid_face, grid_edge and grid_dot structures,
physically containing all the data about the grid. But they also
referred to each other by pointers, which meant that they were hard to
realloc larger (you'd have to go through and rewrite all the pointers
whenever the base of an array moved). And _that_ meant that every grid
type had to figure out a reasonably good upper bound on the number of
all those things it was going to need, so that it could allocate those
arrays the right size to begin with, and not have to grow them
painfully later.

For some grid types - particularly the new aperiodic ones - that was
actually a painful part of the job. So I think enough is enough:
counting up how much memory you're going to need before using it is a
mug's game, and we should instead realloc on the fly.

So now g->faces, g->edges and g->dots have an extra level of
indirection. Instead of being arrays of actual structs, they're arrays
of pointers, and each struct in them is individually allocated. Once a
grid_face has been allocated, it never moves again, even if the array
of pointers changes size.

The old code had a common idiom of recovering the array index of a
particular element by subtracting it from the array base, e.g. writing
'f - g->faces' or 'e - g->edges'. To make that lookup remain possible,
I've added an 'index' field to each sub-structure, which is
initialised at the point where we decide what array index it will live
at.

This should involve no functional change, but the code that previously
had to figure out max_faces and max_dots up front for each grid type
is now completely gone, and nobody has to solve those problems in
advance any more.
This commit is contained in:
Simon Tatham
2023-07-06 12:50:49 +01:00
parent 6b5142a7a9
commit e6cdd70df8
6 changed files with 253 additions and 376 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
loopgen.c
View File

@ -83,7 +83,7 @@ static bool can_colour_face(grid *g, char* board, int face_index,
enum face_colour colour)
{
int i, j;
grid_face *test_face = g->faces + face_index;
grid_face *test_face = g->faces[face_index];
grid_face *starting_face, *current_face;
grid_dot *starting_dot;
int transitions;
@ -348,7 +348,7 @@ void generate_loop(grid *g, char *board, random_state *rs,
* to check every face of the board (the grid structure does not keep a
* list of the infinite face's neighbours). */
for (i = 0; i < num_faces; i++) {
grid_face *f = g->faces + i;
grid_face *f = g->faces[i];
struct face_score *fs = face_scores + i;
if (board[i] != FACE_GREY) continue;
/* We need the full colourability check here, it's not enough simply
@ -430,7 +430,7 @@ void generate_loop(grid *g, char *board, random_state *rs,
del234(darkable_faces_sorted, fs);
/* Remember which face we've just coloured */
cur_face = g->faces + i;
cur_face = g->faces[i];
/* The face we've just coloured potentially affects the colourability
* and the scores of any neighbouring faces (touching at a corner or
@ -456,7 +456,7 @@ void generate_loop(grid *g, char *board, random_state *rs,
if (FACE_COLOUR(f) != FACE_GREY) continue;
/* Find the face index and face_score* corresponding to f */
fi = f - g->faces;
fi = f->index;
fs = face_scores + fi;
/* Remove from lightable list if it's in there. We do this,
@ -517,7 +517,7 @@ void generate_loop(grid *g, char *board, random_state *rs,
enum face_colour opp =
(board[j] == FACE_WHITE) ? FACE_BLACK : FACE_WHITE;
if (can_colour_face(g, board, j, opp)) {
grid_face *face = g->faces +j;
grid_face *face = g->faces[j];
if (do_random_pass) {
/* final random pass */
if (!random_upto(rs, 10))