Verified answer

You don't want efficient storage, so you want "poor storage" that will permit multiple very fast ways of accessing stuff.

There is a relatively new (less than 20 years old) type of database access technology used for generating business reports by having bunches of things already pre-computed and stored. It is called data warehousing.

This means that as soon as a chess piece is moved or placed somewhere else, you pre-compute what other board pieces are threatened by that move and place the results into multiple hash tables or struct arrays with various sorting applied to them to keep the query times fast for those pre-computed storage systems.

Your system could use some kind of sparse array access method. Obviously sparse arrays and file systems exist. If already available, you could use such a sparse array file system to access your chess pieces. Now you then have to decide whether you are going to develop the sparse access algorithms & storage system or use some operating system existing method. Windows NT (and newer versions of windows) has sparse files, and an API for their access. I do not know if this is true for Linux.

Consider also a object oriented system using call-back functions--it would act like a Microsoft windows control that would activate one or more objects based on a kind of "content addressable memory" scheme--or a neural network to trigger other neurons, etc.

For this system of neurons and content addressing you would develop stimulus messages that would trigger other objects. In the old days the windows messages would go into a queue, and only windows objects that were stimulated would respond to the message and either consume the message or keep the message still in the queue.

If these objects were "made aware" of the moves of the other pieces, they could "report on whether or not they were threatened" by a newly placed opponent piece.

The pieces might possibly track where each other were situated, and which ones were threatened by another--in some kind of fast access dynamic array.

Move chess piece action would say what position & which piece was moving, then trigger its unique set of threat towards (characteristic of the category of chess piece it was) and threat from update (callback tables) messages.

Potential long line threat message would say line equation from position X, Y--what pieces intercept this at all, then sort those to determine the nearest one--or somehow "know" this ahead of time? In the know this ahead of time, a labeled call back could be triggered by a piece with open positions for that slope & intercept (line).

Potential Knight threat message would say object threatens localized position A,B from position X, Y.

Limited one position threat line message usable for King & pawns. (King with more directions available).

Any piece would "know" that it could be potentially threatened from 4 diagonal directions (45, -45, 135, -135 degrees) & 2 horizontal (0, 180) & 2 vertical (90, 270) directions. The object's call back function address for threats in these directions could be sorted by angle, and intercept (or whatever unique property).

Similarly for potentially threatening other pieces in a set of other callback or whatever type tables with the same angles, and intercepts as above.

Consider using C++ STL algorithms & vector storage classes etc. Lots of neat stuff.