代码之家  ›  专栏  ›  技术社区  ›  dajobe

增强C++开源项目的依赖性?

  •  29
  • dajobe  · 技术社区  · 16 年前

    提升是注定的 这个 标准的非标准C++库,每个C++用户都可以使用。假设它对于开源C++项目是可用的,还是太大的依赖性是合理的吗?

    10 回复  |  直到 11 年前
        1
  •  44
  •   Konrad Rudolph    11 年前

    基本上,你的问题归结为AYY,是否有合理的(自由库XYZ)作为C++开源项目的依赖项。

    现在考虑一下stroustrup的以下引用,答案真的很简单:

    没有一个好的图书馆,最有趣的任务很难完成。 但是,只要有一个好的库,几乎任何任务都可以很容易地完成。

    假设这是正确的(在我的经验中是这样),然后编写一个合理大小的C++项目。 没有 依赖是完全不合理的。

    进一步发展这一论点, 在开发人员的客户端系统上合理地预期C++依赖(除了系统库)是Boost库。 我 知道 他们不是,但对于一个软件来说,这不是一个不合理的假设。

    如果一个软件甚至不能依靠Boost,它就不能依靠Boost 任何 图书馆。

        2
  •  28
  •   Anders Hansson    16 年前

    看一看 http://www.boost.org/doc/tools.html . 特别是 BCP 如果您希望将Boost依赖项嵌入到项目中,实用程序将非常有用。网站摘录:

    “bcp实用程序是提取boost子集的工具,对于希望将库与boost分开分发的boost作者以及希望将boost子集与应用程序一起分发的boost用户来说,它非常有用。

    BCP还可以报告增强代码的哪些部分依赖,以及这些依赖项使用了哪些许可证。”

    当然,这可能有一些缺点——但至少你应该意识到这样做的可能性。

        3
  •  12
  •   Diomidis Spinellis    16 年前

    我曾经非常谨慎地向系统引入依赖关系,但现在我发现依赖关系并不是什么大问题。现代操作系统附带的包管理器通常可以自动解决依赖关系,或者至少使管理员很容易安装所需的内容。例如,Boost在Gentoo Postal下作为dev libs/boost提供,在freebsd ports下作为devel/boost提供。

    现代开源软件在其他系统上构建了很多。在一个 recent study 通过跟踪freebsd包的依赖关系,我们确定freebsd 4.11系统中的12357个端口包总共有21135个库依赖关系;即,它们需要一个库,而不是作为基本系统一部分的52个库才能编译。库依赖项由688个不同的库组成,而单个项目使用的不同外部库的数量在1到38之间变化,模式值为2。此外,5117个项目至少使用了一个外部库,405个项目使用了10个或更多。

    最后,您的问题的答案将来自成本效益分析。重新使用一个成熟的、广泛使用的、经过审查和测试的库(比如Boost)的好处是否大于依赖的低成本和降低成本?对于Boost设施的任何非日常使用,答案是应该继续使用Boost。

        4
  •  4
  •   jeramiah    16 年前

    这要看情况而定。如果在boost中只使用头文件定义的类模板,那么可以继续使用它,因为它不吸收任何boost共享库,因为所有代码都是在编译时生成的,没有外部依赖关系。版本化问题对任何共享的C++库都是一种痛苦,Boost也不能免于此,所以如果你能完全避免这个问题,那是件好事。

        5
  •  4
  •   Robert Gould    16 年前

    kde也依赖于提升。

    然而,这主要取决于你的目标,甚至更多的取决于你的目标受众,而不是你的项目范围。例如,TinyJSON(非常小的项目)几乎是100%的增强,但这很好,因为它提供的API类似于增强,并且针对需要JSON绑定的增强程序员。然而,许多其他JSON库不使用boost,因为它们面向其他读者。

    另一方面,我不能在工作中使用Boost,我知道很多其他开发人员(在他们的日常工作中)都在同一条船上。所以我想你可以说,如果你的目标是开源,并且是一个使用Boost的团队,那就继续吧。如果您以企业为目标,您可能需要仔细考虑并复制粘贴Boost中的必要部分(并致力于它们的支持),以使您的项目能够工作。

    • 编辑: 我们不能在工作中使用它的原因是我们的软件 可携带到7个不同的位置 平台和跨4个编译器。所以 我们不能使用Boost,因为它没有 已证明与 我们所有的目标,所以原因是 技术一。(我们对 OpenSource和Boost许可证部分, 当我们用Boost在 时代)
        6
  •  3
  •   Simon Steele    16 年前

    在编写C++代码时使用Boost的好处在于它们显著地超过了分发开源代码的额外复杂性。

    我工作 Programmer's Notepad 代码依赖于Boost进行测试、智能指针和Python集成。由于这个要求,已经有了一些投诉,但是如果他们想处理代码的话,大多数人会继续处理。我从来没有后悔过接受这种依赖。

    为了稍微降低其他人的复杂性,我为Boostpython提供了版本化的预构建库,这样他们所需要做的就是在其include目录中提供Boost。

        7
  •  3
  •   Peter Mortensen icecrime    15 年前

    我会说是的。两个 Mandriva ( Red Hat 基于)和Ubuntu( Debian 基础上)有提振libriaries的软件包。

        8
  •  2
  •   Drew Stephens    16 年前

    我认为Boost提供了广泛的功能,正如你所说的,它是标准的非标准C++库,证明它是依赖关系。

        9
  •  1
  •   David    16 年前

    不幸的是,对于Ubuntu来说,它们是现成的,但是对于RHEL4&5,我几乎总是用tarballs来制造它们。他们是很棒的图书馆,只是非常大…就像使用铁轨钉,有时你真正需要的只是一个图钉。

        10
  •  1
  •   David    16 年前

    这完全取决于你使用Boost的方式。正如迪奥米迪斯所说,如果你要使用一些非琐碎的设施,只要继续。使用图书馆不是犯罪。

    当然,有很多人不喜欢使用Boost,因为引入新的依赖关系总是有一些缺点和额外的担心,但是在开源项目中……在我看来,如果你只是想学习它们或者提高它们的技能,使用它们甚至是可以的。