【问题标题】:Should app using VCL migrate?使用 VCL 的应用程序应该迁移吗?
【发布时间】:2011-02-11 05:15:14
【问题描述】:

VCL 已经死了,还是有未来作为 GUI 库?随着 CLX 的结束,未来版本是否有机会提供跨平台支持?

我不得不对使用 Borland 的 VCL(BCB6) 的旧版应用程序做一些工作。现在必须实施新功能,因此有必要重新评估替代方案。是坚持使用 VCL 还是迁移到其他一些库/框架。

我从来没有读过 Embarcadero(Borland) 工具领域发生的事情。至少在 SO 中似乎只有几个 VCL 标记的问题,而且谷歌也没有太多运气。

【问题讨论】:

    标签: user-interface c++builder vcl


    【解决方案1】:

    VCL 正在持续发展。 跨平台在current roadmap。 embarcadero forums 仍然是宝贵的资源。

    【讨论】:

    • 感谢大卫的回答。但是,我仍然不相信。我很难相信 Embarcadero 的未来。阅读stackoverflow.com/questions/819942/the-future-of-c-builder 后,我认为我并不孤单。似乎走这条路(即坚持使用 VCL)只会导致更多的锁定,而对未来没有强有力的保证。
    • VCL 与 Windows 密切相关,一直如此,可能永远如此。这不会很快改变。 CLX 基于 QT,因此可以在非 Windows 平台上运行(当时仅支持 Linux)。 VCL 的许多功能都转换为 QT 的模型,但也有很多没有。这正是试图将特定于操作系统的框架转换为与操作系统无关的框架的本质。现在,即将推出的框架将再次基于(更成熟的)QT,但我认为它不会再次基于 CLX。 Mac 将成为第一个受支持的非 Windows 平台,而不是 Linux。
    • 所以,我们只能等着看这一次的效果如何。它还没有发布。
    • Mike Rozlog 本周刚刚更新了路线图。一定要再看看。
    • Delphi 的下一个版本应该有一个与 VCL 相当兼容的跨平台新框架。因此,在此之前使用 VCL 可能是您未来兼容性或移植的最佳选择。
    【解决方案2】:

    是继续在您的项目中使用 VCL,还是迁移到替代方案在很大程度上取决于您的要求。 VCL 框架功能强大且成熟,具有许多 3rd 方组件,因此值得考虑。替代方案一直在迅速改进,要指出一个作为最终选择确实需要您仔细考虑您的要求,并验证不同框架的优缺点。

    考虑到跨平台已在路线图中,我提醒您,64 位支持已经有一段时间了。我们可能会看到跨平台支持,可能会按计划进行,也可能会延迟,就像我们在以前的许多功能中看到的那样。我想相信它的到来,因为我真的很喜欢 VCL 框架,但我总是对 RAD 工作室系列的官方路线图有一个自然的怀疑——对不起,大卫。 ;)

    如果您研究了不同的替代方案,并发现 VCL 是与您的项目相关的最佳选择,那么我会考虑使用 VCL 框架,特别是如果它是您熟悉的框架。学习一个新框架可能——虽然通常是一个好主意——是一项耗时的工作。因此,即使 可能 存在框架无法保持活力的风险(任何替代方案都会存在),但如果是使用熟悉框架的框架,您可能会节省大量工作最适合您的项目。

    如果你确实考虑使用 C++ Builder 和 VCL,你可能会发现 C++ Builder Journal 是一个有价值的信息来源,他们有一个相对安静的论坛,但里面有一些有趣的帖子,还有一些免费的提示他们的网站:www.bcbjournal.com。

    当然还有 embarcadero 论坛和这个网站,搜索 Delphi 论坛和类别可能是个好主意,因为这些论坛和类别似乎有更多的活跃用户,而且帖子也更多。不过,一件好事是,在 VCL 相关问题中从 Delphi 到 C++ 的转换非常简单。

    【讨论】:

    • 跨平台无疑是 Delphi 和 C++Builder 下一版本的主要关注点之一。他们将无法在不延迟整个产品的情况下延迟它。
    • 看着新发布的XE,我再次看到缺少承诺的主要功能;)我猜他们毕竟能够推迟它。 :)
    【解决方案3】:

    作为 VCL 的用户,我必须说您的观察是真正正确的。 VCL 可能会吸引您,但与 QT 和其他工具包相比,可用资源至少很差,尤其是。在 SO。我们的团队还在他们的组件中发现了几个错误,并且不止一次地修补了组件以使我们的应用程序稳定。对我来说,迁移的主要原因仍然是 VCL 将您锁定在一组开发工具中。我必须承认,如果您有资源进行迁移,我很难找到任何真正好的理由继续使用它。

    鉴于 bcc32 及其库也有很多错误,锁定变得更加严重,在过去的几个月里,我和我的团队花费了更多时间来修复由编译器引起的问题,而不是实际开发功能。对我来说,这是一个如此严重的障碍,以至于它的成本超过了它的好处十倍。不幸的是,迁移的成本对我们来说是如此之高,以至于我们至少现在不得不忍受它的痛苦。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2022-01-15
      • 1970-01-01
      • 1970-01-01
      • 2016-04-14
      • 1970-01-01
      • 1970-01-01
      • 2020-03-17
      • 1970-01-01
      相关资源
      最近更新 更多