将类包装在 DLL 中的优点
我刚刚完成了项目的一个阶段,在该阶段中,我编写了一个小型基础设施来执行特定任务,该基础设施由一个核心类和几个辅助类组成。 C++ 的特性非常基础——单继承、一些 STL 容器,仅此而已。 无线程 - 客户端运行该节目。
我现在想做的是将其全部包装在一个 DLL 中,对其进行版本控制,然后使用 它作为一个独立的单元。我想要这种分离,以便跟踪更改和 更好地发展,也许对于其他项目也是如此。
由于我没有 DLL 中的类的经验,我想听听你的: 你对这个问题的解决方法是什么?
具体来说:
- 值得这么麻烦吗?
- 你经常这样做还是根本不这样做?
- 兼容性问题(例如使用不同编译器编译的客户端)怎么样?
我并不是真的要求进行辩论(尽管这是可能的结果),而是寻求经验的建议。
感谢您抽出时间。
I've just finished a phase in my project where I wrote a small infrastructure to carry out a certain task, made of a core class with several auxiliary classes.
The C++'ness is quite basic - single inheritance, some STL containers, that's it.
No threads - client runs the show.
What I would like to do now is wrap it all up in a DLL, version it, and use
it as a standalone unit. I'd like that seperation in order to track changes and
development better, and perhaps for other projects as well.
As I don't have experience with classes in DLLs, I would like to hear yours:
What's your approach to this problem?
Specifically:
- Is it worth the trouble?
- Do you do that often or not at all?
- What about compatibiliy issues (like clients compiled using a different compiler)?
I'm not really asking for a debate (though that's the probable outcome), but rather an advice from experience.
Thanks for your time.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我发现很难看出这有什么好处。我可以看到很多问题:
仅当您能确定好处大于坏处时才进行此更改。
I find it hard to see any benefit with this. I can see plenty of problems:
Only make this change if you can identify benefits that outweigh the negatives.
C++ 代码在编译器之间不是二进制兼容的,创建公开 C++ 类的 DLL 通常是没有用的,这些类不是作为使用它们的项目的一部分构建的。
如果您想创建一个具有定义良好的面向对象接口的 Windows DLL,供世界其他地方使用,请将其设为 COM inproc 服务器。
C++ code is not binary compatible between compilers, it's generally no use creating DLLs exposing C++ classes that aren't built as part of the project that uses them.
If you want to create a Windows DLL with a well-defined object-oriented interface that the rest of the world can use, make it a COM inproc server.