David Millington(高级产品经理),Atanas Popov(开发人员工具总经理),Kyle Wheeler(C ++总经理)
在过去的一年中,我们有很多客户询问我们在C ++ Builder中继续跨平台多设备支持的计划。我们想提供我们计划的最新信息。
平台概述
我们将C ++ Builder的VCL工作优先于FMX,这使我们对平台支持的支持落后。当前,C ++ Builder 10.4支持:
- Windows 32和64位VCL和FMX
- FMX中的iOS 64位
- FMX的Android 32位
受影响最大的人应该已经了解以下内容,但必须清楚:8月1日,Google的32位应用程序的截止日期将生效,如果您想继续在Play商店中更新应用程序,则需要重新编译它们作为Android 64位。C ++ Builder当前不支持该平台。我们不会在8月1日之前提供Android 64位支持,也不会在C ++ Builder 10.4.1(2020.)中提供该支持。
值得注意的是,32位Android应用程序仍然可以正常运行-实际上,几天前我们发布了10.4修补程序,用于解决C ++ Android 32位异常处理问题。Android设备仍支持32位应用程序;只有Play商店具有64位限制,这意味着内部应用程序或旁加载的应用程序仍然可以正常运行。
我们也没有计划在2020年支持macOS 64位。如果这样做,我们可能会直接迁移到支持ARM(苹果芯片)的位置。
如果Android 64位对您很重要,那么带有Delphi的RAD Studio是完全兼容的。请九齿耙采集器网络爬虫软件立即与我们联系以讨论折扣并进行转换。
客户反馈和平台
在2019年3月,我们发出了客户调查。在该调查中,来自C ++ Builder客户的总体反馈是要求我们关注Windows和Windows的质量:编译器质量,STL和IDE(包括代码完成)。
我们的大多数C ++ Builder客户都使用VCL仅针对Windows。之所以这样做,是因为VCL的性能,本机控件以及我们提供的新控件。此外,Microsoft带来了升级到Windows 10的压力,我们的Windows 10支持对于那些正在迁移的应用程序或那些正在寻找适用于Windows 10的高质量UI应用程序环境的人来说非常有用。
我们采用的策略很明确:在其他平台上工作之前,专注于Windows并确保它满足您的期望。出于这个原因,我们从路线图中删除了对macOS Catalina的支持,并且从那时起,我们就一直在致力于Windows质量上的工作,而不是Android 64位支持。
Windows质量
我们非常清楚,自从2018年11月对Clang进行升级以来,我们一直不想提供Windows的质量(包括IDE工具)。
那我们的计划是什么?我们要解决什么?
我们在代码完成,链接器,某些STL类和某些编译器ICE方面存在长期的问题。此外,我们希望提供IDE生产力功能,以确保C ++ Builder在生产力方面超越其他IDE。Windows的目标如下:
为了质量:
- 提供功能齐全的代码完成功能和其他Code Insight功能
- 为了完全解决所有链接器问题,可能通过一个全新的链接器
- 解决STL问题
- 为了与常见的C ++库提供出色的C ++兼容性,这意味着我们与其他工具链具有出色的兼容性。
对于功能:
- 为了通过集成Visual Assist提供进一步的代码工具(例如重构),这意味着C ++ Builder将拥有比Visual Studio更强大的生产力工具。
- 提供C ++ 17或更高语言支持
- 提供更大,更快的编译速度,尤其是对于大型项目
此处的最终目的是确保(a)一切按您的期望和期望工作,并且(b)我们既与通用C ++兼容(这对您有所帮助),又在生产力方面超过其他工具。我们的库(如VCL)是世界领先的-在该级别上具有IDE生产力也将使C ++ Builder发挥重要作用。
虽然我们还没有到位,但是该策略说明了我们的关注点以及自调查以来我们提供的服务。让我们用上面的注释来解释我们已经交付的内容和计划的内容。
改进措施
自调查以来,我们已经交付了:
- Windows 64位C ++ 17,这意味着您可以使用现代C ++定位Windows 32位和64位
- 现代版本的Boost(直到那时,我们才交付Boost 1.55):今天,Boost 1.68的价格是10.3,Boost 1.70的价格是10.4。
- 整个工具链都有大量的编译器稳定性,RTL方法,STL修复,链接器修复等,包括与经典编译器的兼容性,这意味着从旧的经典Clang升级到现代的Clang比以前容易得多。
- GetIt上许多流行的开源库。除了使这些工具易于使用之外,它们也是查找RTL或我们与其他工具链不兼容的其他区域的绝佳测试案例。(即使在Windows上,我们的标头中经常使用POSIX方法或方法;而且,常见的C ++库中的许多标头都是为假定特定的编译器而编写的。)其中包括libsimdpp,Eigen,NemaTode,SDL 2等,并解决了许多兼容性通过该工作解决问题,为您提供更大的功能来引入外部C ++库和源代码
- 更新了CMake支持,以改善资源链接等功能,以及自动为我们的工具链处理其他编译器的配置-再次提高了兼容性
- 一个用于Windows 64位的全新调试器,都解决了Clang的调试问题,这是一类通常调试C ++的常见问题。这使得使用Clang进行调试与使用Win64经典版进行调试相当。
将来,我们计划交付:
- 链接器修复程序,包括对调试格式存储和链接的更改,可减少链接调试版本时的内存负载。正在研究中的是对链接器的较大更改。
- Visual Assist for C ++ Builder,向IDE添加了重构和其他工具
- 更新了STL,删除了STL错误
- IDE中的CMake集成
- 修复了C ++的代码完成
- 并行编译,根据可用的CPU数量减少了构建项目所需的时间-即4倍,8倍甚至更快
摘要
我们的C ++ Builder客户要求我们专注于Windows和质量,这就是我们正在做的事情。我们致力于为您提供高质量的Windows开发,尤其是关注IDE生产率以匹配我们现有的UI生产率,以及解决重要问题。这确实意味着我们在短期(6-9个月)内将不支持Android 64位或macOS。但是,我们正在努力并已经交付了Windows的一些重要改进。诸如Visual Assist集成之类的更多项目对于使C ++ Builder领先于其他IDE的生产力而言令人兴奋。我们了解,这种优先顺序可能会对您中的某些人产生负面影响,对此我们深表歉意。我们认为,专注于质量和Windows是当今正确的事情,以确保我们为您提供所需的产品。
一旦我们对Windows开发的质量增强和功能集充满信心,我们将重新评估环境并采取适当的步骤来解决其他平台和功能。请随时关注即将发布的版本,并与其他反馈或请求保持联系!
注意:这些计划和路线图代表了我们截至目前的意图,但是我们的发展计划和优先级可能会发生变化。因此,我们无法提供任何承诺或其他形式的保证,即我们将最终按计划的时间表或所描述的顺序或根本不发布任何或所有上述产品。这些开发进度表或“产品路线图”的一般说明不应解释或解释为任何形式的承诺,并且我们的客户对升级,更新,增强和其他维护版本的权利仅在适用的软件许可协议中阐明。 。