Problem
Database::Instance() returns const Database&, yet the mutating operations Save, SaveAutoIncrement, Update, and Delete (include/database.h) are declared const and are callable on that const reference even though they modify the underlying database.
Impact
Mechanically harmless (the SQLite handle is mutated through a sqlite3* member, which const doesn't protect), but the API misrepresents intent: a const reference appears read-only while it can mutate persistent state. This is a design/maintainability smell and can mislead callers reasoning about thread-safety and aliasing.
Suggested direction
Either make the mutators non-const and have Instance() return a non-const reference for write access (possibly a separate const accessor for read-only use), or, if the const-singleton pattern is intentional, document the rationale explicitly.
Problem
Database::Instance()returnsconst Database&, yet the mutating operationsSave,SaveAutoIncrement,Update, andDelete(include/database.h) are declaredconstand are callable on that const reference even though they modify the underlying database.Impact
Mechanically harmless (the SQLite handle is mutated through a
sqlite3*member, whichconstdoesn't protect), but the API misrepresents intent: aconstreference appears read-only while it can mutate persistent state. This is a design/maintainability smell and can mislead callers reasoning about thread-safety and aliasing.Suggested direction
Either make the mutators non-
constand haveInstance()return a non-const reference for write access (possibly a separate const accessor for read-only use), or, if the const-singleton pattern is intentional, document the rationale explicitly.