Banking Framework

A C++ comparison of hash-table collision-resolution strategies, applied to a toy banking database (accounts keyed by name, with balances and transactions).

What it does

The same BaseClass interface (create account, add transaction, get balance, get top-K balances, etc.) is implemented five different ways, each backed by a different hash table strategy:

• Chaining — separate-chaining hash table
• Linear Probing — open addressing, linear probe sequence
• Quadratic Probing — open addressing, quadratic probe sequence
• Cubic Probing — open addressing, cubic probe sequence
• Comp — a comparison/reference implementation

main.cpp runs the same test suite (testDatabase) against all five implementations via the shared BaseClass* interface, asserting identical behavior (balances, top-K, existence checks) regardless of the underlying collision strategy.

Structure

Banking_Framework/
├── BaseClass.h           # shared interface (pure virtual)
├── Chaining.h/.cpp
├── LinearProbing.h/.cpp
├── QuadraticProbing.h/.cpp
├── CubicProbing.h/.cpp
├── Comp.h/.cpp
├── main.cpp              # shared test suite run against all five
└── run.sh

Running it

./run.sh

or open Banking_Framework.xcodeproj in Xcode and run.

Why

Built to compare collision-resolution strategies concretely: same interface, same test suite, different hash-table internals, so the tradeoffs (clustering behavior under linear vs. quadratic vs. cubic probing, memory overhead of chaining) show up directly in identical code paths rather than in theory.