为其他人生成C ++静态或动态库时的最佳实践?

时间:2015-07-16 03:23:54

标签: c++ conventions

我正在为我公司的其他客户提供Microsoft C ++库(静态和动态)。我的库有一些类依赖于常见Windows DLL中的函数,默认情况下,导入库包含在项目链接设置中。

每次像这样的新依赖项出现时,我认为在封装依赖项方面会更好(而且更多一些自我),而不是在我的库的每个构建配置的链接器部分添加一个新的导入库名称。 -documenting)如果我在类的.cpp文件中使用#pragma comment(lib, ...)依赖于这样一个DLL的函数,例如:

Foo.cpp中:

#include <SomeWinLib.h>

#pragma comment(lib, "somewinlib.lib")

... implementation of Foo class ...

...但我发现如果他们也在使用SomeWinLib,这会导致我的库的客户端出现链接警告/错误。在对该主题进行一些阅读之后,似乎推荐/最佳实践是让在我的库中链接的客户端也链接到它所依赖的库中。

我仍然希望这对客户端尽可能自动/无痛,所以不要只是在readme.txt文件中放入所需的导入库列表(然后坐下来等待不可避免的电话来自沮丧开发人员),我只是将#pragma comment放在Foo.h 头文件中。这样,如果客户端包含需要它的类的头文件,客户端将自动链接到所需的库。

foo.h中:

#pragma comment(lib, "somewinlib.lib")

public class Foo
{

然而,当我构建我的库时,Foo.cpp显然包含了Foo.h,所以看起来我需要在头文件中的#pragma comment行周围需要某种预处理器“guard”,这样它才是唯一的当客户端包含我的头文件时,由预处理器看到。

foo.h中:

#if !defined(building_my_library)
  #pragma comment(lib, "somewinlib.lib")
#endif

public class Foo
{

所有这些似乎都是每个库必须要做的事情,但是当我谷歌的其他开源Windows库时,我没有看到这样的例子。这让我怀疑我在某个地方遗漏了什么。

有没有人知道我是否正确理解这些问题,如果是的话,我是否过度复杂化了解决方案?

谢谢!

2 个答案:

答案 0 :(得分:1)

您可能没有考虑过的解决方案是通过LoadLibraryGetProcAddress使用与DLL的运行时链接,从而消除对 somewinlib.lib 的依赖。

答案 1 :(得分:1)

你的最后一个选项或多或少是boost标题的作用,除了它们还提供了一个预处理程序指令,以便在你想自己控制事物的情况下明确地关闭自动链接:

#if !defined(building_my_library) && !defined(no_auto_link_stuff)
    #pragma comment(lib, "somelib.lib")
#endif