Word Search with Threads

I built Word Search to learn C++ threading. The instructor supplied a puzzle file; I wanted to solve it and find out whether dividing a small search problem among threads would be useful. That gave me two problems to work through: how to divide the comparisons, and how to return their results to the main thread.

Turning the puzzle into strings

A word can run in eight directions, but opposite directions cover the same letters in reverse. The solver extracts four families of lines: rows, columns, and the two diagonals. Comparison then accounts for words running either way along a line.

Each extracted string keeps its starting coordinates and direction. A match at an offset within that string can therefore be translated back into cells in the puzzle. That positional information matters to the display, which needs to highlight the letters rather than simply announce that a word exists.

Rows and columns are straightforward; diagonals need more care because their lengths vary and their starting positions move around the puzzle’s edges. The directional scans use a shared routine, with parameters controlling the start, direction, boundary condition, and move to the next line.

Giving each task useful work

The target words and extracted lines are grouped by length. A six-letter word only needs comparisons against lines of six letters or more. That excludes impossible comparisons before starting worker threads.

A task compares one group of target words with a suitable group of lines. It collects matching words and their puzzle locations into a vector. This keeps the result format useful to both the search and the interface: the collector gets complete match records rather than having to reconstruct positions afterward.

Bringing the answers back

Each task has a promise and its associated future. Task creation moves the promise into the worker, which supplies the vector of matches. The collector joins the thread, obtains that vector through the future, appends the matches to the display’s result list, and releases the task data.

Learning how to transfer the promise was a substantial part of the exercise. It gave move semantics and the future/promise relationship a concrete purpose. The accompanying article walks through the code I used to return those results.

What the experiment leaves open

I expected little benefit from threading a workload this small. No preserved timing results establish how it compared with a sequential version. The original instructor-supplied puzzle is also missing from the available project files.

The custom string comparator has false-positive cases in a later isolated check using compatibility wrappers. That check did not run the historical GUI application, but it does mean the comparator needs attention before treating the solver as generally correct. The project remains useful as a record of the grid-scanning approach and my first work with thread result collection.