inputHistory.hpp File Reference

Abstract interface for how a search remembers the sequence of inputs ("path") that produced each state. More...

#include "../inputSet.hpp"
#include <jaffarCommon/deserializers/base.hpp>
#include <jaffarCommon/json.hpp>
#include <jaffarCommon/serializers/base.hpp>
#include <map>
#include <memory>
#include <string>

Go to the source code of this file.

Classes
class	jaffarPlus::InputHistory
	Abstract strategy for remembering the input path that produced each search state. More...

Detailed Description

Abstract interface for how a search remembers the sequence of inputs ("path") that produced each state.

The rest of JaffarPlus only ever talks to this base class; concrete strategies (none / raw bit-packed / shared prefix trie) live in their own headers and are selected from the .jaffar config. See inputHistoryFactory.hpp for construction.

Two groups of operations live on this one interface:

• per-runner "cursor" ops (pushInput, (de)serialize, toString): each Runner owns an instance and advances it as it explores.
• "manager" ops on stored cold-slot bytes (initColdSlot, releaseColdSlot, captureColdToFull, sizes): these only use the shared backing (e.g. the trie), so the StateDb calls them on a reference instance.

Cold vs full: the StateDb stores a compact "cold" representation in each state slot; standalone snapshot buffers (best/worst/win, player initial state) hold a self-contained "full" representation. For raw/none the two coincide; for the trie the cold form is a 4-byte node id while the full form is a reconstructed, self-contained copy.

Definition in file inputHistory.hpp.