辅助类 - 私有嵌套类与声明类和声明类仅在实现文件中定义
我正在编写一个基本的 SQLite 包装器。在执行此操作时，我注意到我经常手动打开和关闭 SQLite 数据库，使用 SQLite 的 API 创建和销毁 SQLite 编译的语句结构。手动创建/销毁这些资源。当函数发生错误时必须提前返回时，我正在学习的内容会变得有点混乱。
我想到处理这个问题的更多 C++ 方法是让堆栈上对象的生命周期管理这些 RAII 风格的东西。这样，每当我从函数返回时（是否由于错误而提前返回），这些清理任务将在堆栈展开时由析构函数处理。
我的问题是，对于这些辅助 RAII 类（例如 SQLiteDBHandle、SQLiteStatementHandle），其使用与较大的 SQLite 包装器类相关，最好将它们声明为 SQLite 包装器内的私有嵌套类，或者简单地声明 & 。在 SQLite 包装器的实现文件中定义它们，没有 header 和 header 。自己的实现文件？
我倾向于将它们作为独立的类放在 .cpp 文件中。
仅声明 & 有缺点吗？将它们定义隐藏在我丢失的较大包装器的 .cpp 文件中？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
不，那很好。
如果某些类或函数仅在一个 .cpp 文件中使用，则在该文件中定义它们是有意义的。
另一方面，如果它们很大（无论这意味着什么），或者可以在其他地方使用，那么最好将它们放在单独的源文件中。但如果需求发生变化，也可以稍后修复。
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.