I’m writing a basic SQLite wrapper. While doing this I noticed I’m frequently manually opening and closing SQLite databases, creating and destroying SQLite compiled statement structs using SQLite’s API. Manually creating/destroying these resources. Which I’m learning gets kind of messy when a function has to return prematurely when an error occurs.
It occurred to me that the more C++ way of handling this would be to let the lifetime of an object on the stack manage these things RAII style. That way whenever I return from a function (early due to error or not), these cleanup tasks will be handled by the destructors as the stack unwinds.
My question is, for these helper RAII classes (SQLiteDBHandle, SQLiteStatementHandle for example) whose use is tied to the larger SQLite wrapper classs would it be better to declare them as private nested classes within the SQLite wrapper, or to simply declare & define them in the implementation file of the SQLite wrapper, without header & implementation files of their own?
I’m inclined to just put them as stand alone classes in the .cpp file.
Is there a drawback to just declaring & defining them hidden away in the larger wrapper’s .cpp file that I’m missing?
No, that’s perfectly fine.
If some classes or functions are only used in one .cpp file, it makes sense to define them in that file.
On the other hand, if they are of significant size (whatever that means), or could be used elsewhere, you would be better of putting them in a separate source file. But that can also be fixed later, should the requirements change.