| 技术论坛 |
|
|
| ≡技术区≡ ① |
| DELPHI技术 |
| lazarus/fpc/Free Pascal |
| 移动应用开发 |
| Web应用开发 |
| 数据库专区 |
| 报表专区 |
| 网络通讯 |
| 开源项目 |
| 论坛精华贴 |
| ≡发布区≡ ② |
| 发布代码 |
| 发布控件 |
| 文档资料 |
| 经典工具 |
| ≡事务区≡ ③ |
| 网站意见 |
| 盒子之家 |
| 招聘应聘 |
| 信息交换 |
| 论坛信息 |
|||
|
| 导航： | 论坛 -> DELPHI技术 斑竹:liumazi,sephil | |||||
| 作者： |
|
2018/10/30 17:00:05 | ||||
| 标题： |
|
加入我的收藏 | ||||
| 楼主： | DELPHI 10.3 在语言层面引入了 Inline Variables & Type Inference . 古老得语法有了现代气息了，Glad to see that. http://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html ---------------------------------------------- Keep It Simple & Stupid |
|||||
| 作者： |
|
2018/10/30 17:06:38 | ||||
| 1楼： | 这个的确是不错，以前写程序从c++中转代码在delphi中写得总是不一样，特别是循环中用的临时变量，C中在每次循环中用的局部变量都是超生命周期的，但delphi中只有到函数最后才超生命周期，导致转代码要改结构，现在有这个语法那就一致了 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/30 17:30:02 | ||||
| 2楼： | @tiez 确实是不错，开始变得现代了 。 ---------------------------------------------- Keep It Simple & Stupid |
|||||
| 作者： |
|
2018/10/30 17:33:49 | ||||
| 3楼： | 把c语言的宏也抄一下。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/30 17:52:30 | ||||
| 4楼： | 跨行字符串 还没加进去呢。。。 ---------------------------------------------- kittyapp |
|||||
| 作者： |
|
2018/10/30 17:58:15 | ||||
| 5楼： | 这个好. ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/30 18:00:33 | ||||
| 6楼： | 这个可以，如果加上 try except finally end就好了，写一次就够了 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/30 18:57:09 | ||||
| 7楼： | 非常好的特性，有利于从其他语言转过来的人的很快适应。 ---------------------------------------------- Delphi4Linux Delphi三层/FireDAC 技术群：734515869 http://www.cnblogs.com/rtcmw |
|||||
| 作者： |
|
2018/10/30 20:18:59 | ||||
| 8楼： | very good！！！ ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/30 21:01:51 | ||||
| 9楼： | 可以改名DelC++，哈哈。。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/30 22:38:19 | ||||
| 10楼： | EMB 应该大力发展CB。这样即兼顾了DELPHI，又靠近了C++，开源代码结合也方便。 Delphi基本上和开源没半毛钱关系。 ---------------------------------------------- 武汉天气不好 |
|||||
| 作者： |
|
2018/10/31 0:06:31 | ||||
| 8楼： | 了了 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 3:42:57 | ||||
| 11楼： | 我优雅的Delphi代码，渐行渐远。讨好开发者应该从性能和fmx平台上发力吧 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 8:41:18 | ||||
| 12楼： | 吸取精华，弃其糟泊。临时变量等，还是不要完全抄袭C的为好！ ---------------------------------------------- Everyone will to do best! |
|||||
| 作者： |
|
2018/10/31 8:57:49 | ||||
| 13楼： | 有好的改进，但Delphi也因此而越发臃肿了。 ---------------------------------------------- -广袤璀璨的银河,永无止境的梦想(梦无止境游银河) 博客挂了…… |
|||||
| 作者： |
|
2018/10/31 8:57:51 | ||||
| 13楼： | 顶 11 楼。 例如 ARC 的支持，就是没必要的，现在发现问题太多，未来还计划完全取消。当初要是 不去支持这个，能省多少事情。 string 从 0 开始，这种事情，有人说是因为 llvm 也是从 0 开始的。 如果不支持 ARC，把这些时间用来，支持 string 从 1 开始，对 DELPHI 的很多开源项目来说，就是天大的好事。 他们只需要修改对 Unicode 和 TEncoding 的支持就可以完美运行了。 现在却要改太多的地方，凡是 字符串 操作，都要检查。确认兼容，才能用。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/31 9:07:04 | ||||
| 14楼： | 早就应该这样了,写着太方便了,好事情. 出来10.3 项目马上就用 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 9:11:29 | ||||
| 15楼： | Pascal语言语法严谨，层次分明，程序易写，可读性强，是第一个结构化编程语言。 没有原则的改变自己的特有的风格，一味的跟风，必死无疑。Niklaus Wirth只剩下哭了。 ---------------------------------------------- 程序在于业务、流程、思想、风格。 |
|||||
| 作者： |
|
2018/10/31 9:28:11 | ||||
| 16楼： | 大神们 问下啥时候 出10.3啊 等着用 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 9:40:57 | ||||
| 17楼： | To 抱残守缺的人们： Delphi 10.3 具有类型推断和局部范围的内联变量声明为Delphi语言带来了新鲜空气。虽然Pascal源代码可读性仍然是保留的关键原则，但在核心级别对语言进行现代化处理非常重要，可以消除一些生锈（真实或感知）。在内联变量的情况下，偏离传统编码风格有很多优点，价值很明显。 尽管如此，您可以按原样保留代码，并要求您的开发人员坚持使用传统声明：现有代码或样式中没有任何内容是错误的，但内联声明为您提供了新的机会。我已经很难回到旧版本的Delphi了...... Marco Cantu ---------------------------------------------- Delphi4Linux Delphi三层/FireDAC 技术群：734515869 http://www.cnblogs.com/rtcmw |
|||||
| 作者： |
|
2018/10/31 9:47:20 | ||||
| 18楼： | 11月15日，Emb 在法国巴黎，有一个重大产品展示会。会上展示最新版 10.3 Rio ，以及EMB最新的 Roadmap。希望可以尽早也发 iso 出来。值得期待。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 10:15:46 | ||||
| 19楼： | Marco Cantu 不知道他能不能解释一下他发的 DEMO procedure NewTest; begin var MyDictionary := TDictionary (string, Integer).Create MyDictionary.Add ('one', 1); var APair := MyDictionary.ExtractPair('one'); ShowMessage (APair.Value.ToString) end; MyDictionary 会自己销毁吗？ 如果会的话。是不是 ARC 在 桌面 在 10.3 LINUX 上，变相的应用上了。 毕竟 前面有人说 10.3 LINUX 上默认不开启 ARC 了。 还计划 移动开发 也关闭 ARC。 EMB 能不能不要 自相矛盾！ ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/31 10:16:48 | ||||
| 19楼： | 无感，一点语法糖，些许增加点代码书写的方便性。 暂时看不到实质性的意义。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 10:24:33 | ||||
| 20楼： | 我曾经提过一个建议 procedure XXX; var Obj: TOjbect local; begin ... end; 其中，local是关键字，表示Obj在栈上分配内存， 编译器，默认调用构造函数，出作用域，默认调用析构函数。 这样，就可以不使用ARC，但可以在对象上实现泛型运算(生成临时的局部对象)。 （其实就是C++泛型运算的实现方式） 目前看来，有点朝这个方向走的感觉。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 11:00:55 | ||||
| 21楼： | 其实这个好是好，但是看代码有点更费劲。破坏了原来的严谨层次。 现在的 IDE 其实有个功能：在第一个 begin 下一行输入 var ，按下 tab 键，写好变量声明再按一下 tab 就自动上去私有变量区域，但是在别的 begin 地方就没了这个输入功能，改下这个也很好啊，不知道为什么这么久了都不改这个。 ---------------------------------------------- delphi 是兴趣，和工作无关，即使它倒闭。又不靠它 delphi 吃饭，怕甚？ |
|||||
| 作者： |
|
2018/10/31 11:14:34 | ||||
| 22楼： | 真是个好消息，算得上是个里程碑。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 11:41:25 | ||||
| 17楼： | 循环变量那些这样写是方便，如果在函数内随处都是var，也够晕的。 有些可以借鉴让代码更简洁，有些不能借鉴，方便简洁和严谨背道而驰。 ---------------------------------------------- 简单做人，认真做事。 |
|||||
| 作者： |
|
2018/10/31 11:45:15 | ||||
| 23楼： | 终于想通了。准备要摘掉贫困的帽子了？ 以前牛逼的人，还把贫穷落后当一美，各种夸，各种赋。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 14:01:38 | ||||
| 24楼： | 支持 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 14:34:43 | ||||
| 25楼： |  http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html这也是想通了？ 难道 老大 也打算放弃 先进性？ A few years after that planned was rolled out, we still see its advantages and benefits, but we have a much more clear picture of the drawbacks of the ARC model and what its effect will be in making it the default also on Windows and VCL applications. 在推出计划几年之后，我们仍然看到了它的优点和好处，但是我们对ARC模型的缺点以及它在使其成为Windows和VCL应用程序的默认值方面将产生什么影响有了更清晰的了解。 We have long considered ARC memory management to be an improvement over the traditional Delphi model, as it removes and simplifies some of the memory management. However, we have learned when building and maintaining our large libraries and by talking with customers on complex code bases, that while ARC looks great on paper and for local variables and simpler scenarios, it often causes a lot of trouble for complex scenarios. Also the TComponent ownership model all of our libraries are centered on is at odds with ARC, making it complex to ARC-enable existing component libraries. We could have decided to go “full ARC” also on Windows, but that would have caused a significant breakage of existing applications and components, causing far more trouble than the Unicode migration we did in the past -- which was due to external pressure of offering good international support and the fact that the underlying operating systems (starting with Windows) were also Unicode. 长期以来，我们一直认为ARC内存管理是对传统Delphi模型的改进，因为它删除并简化了一些内存管理。然而，我们在构建和维护大型库时以及通过与客户在复杂代码库上交谈，已经了解到，虽然ARC在纸上和局部变量以及更简单的场景中看起来很棒，但是对于复杂场景，它常常会造成很多麻烦。此外，我们所有库所关注的TComponent所有权模型与ARC不一致，这使得启用ARC的现有组件库变得复杂。 我们本可以决定在Windows上进行“完全ARC”，但是这会导致现有应用程序和组件的严重破坏，比我们过去所做的Unicode迁移带来更多的麻烦——这是由于提供良好国际支持的外部压力。下面的操作系统（从Windows开始）也是Unicode。 We had many requests to make ARC optional, but an ARC-enabled object won’t easily coexist with a non-ARC-enabled one, and we would need containers for both flavors of objects and would make it impossible to mix them. This would end up as an extremely complex scenario. Mixing ARC and non-ARC is not a viable solution, but also keeping different memory models on different platforms end up defeating the entire idea of “single source, multi platform” which is a core tenet of today’s Delphi focus both server side (Windows and Linux) and client site on all platforms you can build FireMonkey applications for. 我们有许多要求使ARC是可选的，但是启用ARC的对象将不容易与非启用ARC的对象共存，并且我们需要用于两种类型的对象的容器，并使得无法将它们混合。这将是一个极其复杂的场景。混合ARC和非ARC不是可行的解决方案，但是在不同的平台上保持不同的内存模型最终会打败“单源、多平台”的整个想法，这是当今Delphi将服务器端（Windows和Linux）和客户端站点都集中在所有平台上的核心原则。ORMS，您可以构建FixMax应用程序。 Another significant angle is that ARC has a runtime cost. While things can be optimized and improved, at the end automatic management is not totally free. While Garbage Collection has a (very high) cost when it kicks in, ARC has a cost on objects lifetime and object interaction (unless you cautiously use const for all parameters passing). A positive effect of disabling ARC is a measurable performance improvement. Finally, ARC in Delphi is a bit at odds with the C++ side of the product, which is an integral part of RAD Studio. 另一个重要的角度是ARC具有运行时成本。当事物可以被优化和改进时，最终自动管理不是完全免费的。虽然垃圾收集在启动时具有（非常高的）成本，但是ARC在对象生存期和对象交互方面具有成本（除非您对所有参数传递谨慎地使用const）。禁用电弧的积极作用是可测量的性能改进。最后，Delphi中的ARC与产品的C++端有一定的差异，这是RAD Studio的一个组成部分。 The New Plan: Phasing Out ARC  (using interfaces in Delphi) ith all of these considerations in mind, and after extensive internal discussions, also involving partners and external developers, we have reached the conclusion that the best way forward is to move off the ARC model as a default memory management solution, and compensate for its loss with other alternatives. 记住所有这些考虑，并且经过广泛的内部讨论，也涉及合作伙伴和外部开发人员，我们已经得出结论，前进的最佳方法是将ARC模型作为缺省内存管理解决方案移开，并且与其他寄生动物。 In practical terms, the Linux 64-bit compiler in the 10.3 Rio release is going to offer the traditional Delphi memory management of the Windows platforms, making your Windows and Linux server side code totally equivalent -- at least in terms of Delphi language and memory management. 在实践中，在10.3名力拓发布Linux 64位编译器将提供的Windows平台传统的Delphi内存管理，使您的Windows和Linux服务器端代码完全等价，至少从Delphi语言和内存管理。 The go-forward plan is to not embrace ARC for the coming macOS 64-bit platform (so all desktop platforms are and will remain on the non-ARC model) and to disable ARC also for mobile platforms in the future (most likely around the next major release after 10.3). Notice that in 10.3 Rio the mobile compilers remain with ARC enabled, exactly like in 10.2. 未来的计划是不要为即将到来的macOS 64位平台采用ARC（所以所有桌面平台现在和将来都保持在非ARC模型上），并且在未来为移动平台禁用ARC（很可能在10.3之后的下一个主要版本附近）。请注意，在10.3个里约中，移动编译器仍然启用弧线，完全类似于10.2。 We still think reference counted memory management is relevant, but rather than introducing a new mechanism for it, we prefer to leverage and augment the existing reference counted model that is used by interfaces and strings in Delphi. This has been the case for a long time. Interface references and object references to the same object can cause trouble if not handled properly, but this is something most Delphi developers already know how to handle and there is a lot of documentation on the subject. 我们仍然认为引用计数的内存管理是相关的，而不是引入一种新的机制，我们更喜欢利用和扩充Delphi中接口和字符串使用的现有引用计数模型。这种情况已经持续很长时间了。如果没有正确处理，对同一对象的接口引用和对象引用可能会造成麻烦，但这是大多数Delphi开发人员已经知道如何处理的，并且有很多关于该主题的文档。 nterface references have been recently extended with weak references and even unsafe references. These additional options largely increase the power and flexibility of “ARC for interfaces”. In other words, while we are going to remove ARC for object references, ARC for interface references is a feature of the language that has been and will remain available. 最近的参考文献已经用弱引用和甚至不安全的引用扩展了。这些额外的选项大大增加了“面向接口的ARC”的灵活性和灵活性。换句话说，尽管我们要删除对象引用的ARC，但是接口引用的ARC是已经存在并将继续可用的语言的一个特性。 On top of this, we want to improve and simplify the management of the lifetime (and memory management) of local short-lived objects with stack references. This is a not feature we are going to introduce in 10.3, but something we are actively investigating and can be partially implemented by developers leveraging managed records (a new language feature in 10.3). 除此之外，我们希望改进和简化具有堆栈引用的本地短期对象的生存期（和内存管理）管理。这不是我们将在10.3中介绍的特性，而是我们正在积极研究的，并且可以部分由利用托管记录的开发人员实现（10.3中的新语言特性）。 Wrapping Up  (Memory leaks tracking made simple) While we understand that this change to the plans made a few years back can come as a surprise and affect existing code, developers who were unhappy about the ARC model, supporting multiple models on different platforms, and its loss of performance compared to native memory management, are likely going appreciate the decision. 尽管我们理解几年前对计划的这种改变可能带来惊喜并影响现有代码，但是对ARC模型不满意、在不同平台上支持多个模型、以及与本机内存管理相比性能损失的开发人员很可能感谢你的决定。 Offering alternative ways to further simplify Delphi memory management is in RAD Studio’s roadmap, but the current set of features (interfaces with reference counting and support for weak and unsafe references, the component ownership model, and the standard common practices) already provide a good framework to reduce the worry of manual memory management for Delphi developers. RAD Studio的路线图中提供了进一步简化Delphi内存管理的替代方法，但是当前的特性集（具有引用计数的接口以及对弱和不安全引用的支持、组件所有权模型和标准通用实践）已经提供了一些尝试OD框架减少了Delphi开发人员对手动内存管理的担心。 Ultimately there is no perfect solution for memory management in programming languages, as automatic ones have their drawbacks, and manual ones are (well) manual. Delphi has had a very good balance in the past, which continues today and will only improve in the future. 最终，在编程语言中没有完美的内存管理解决方案，因为自动内存管理有其缺点，而手动内存管理是（好的）手动的。德尔福在过去有很好的平衡，今天继续，将来只会改善。 想当初为了 吸引 所谓的 其他语言的开发人员，做的 ARC 和 下标从0开始。 结果只是害得旧代码完全不兼容而已。 并没有吸引到所谓的别的开发人员！ 正确的事情，我们要支持，例如 跨平台，例如 泛型 匿名 HELPER 。 错误的事情，我们就要毫不留情的骂！ 例如 string 下标 例如 这个 ARC。 骂到他们改为止。 ARC 的战役，我们胜利了，下一步就是 下标问题。 最终的目标 开源世界的 各种 旧代码，只需要 关心一下 国际化，就可以了。 其他的一律不需要修改，就能在新版本上使用，甚至 可以 直接 跨平台！ 骂 DELPHI 的人 有 两种。 一种是 骂 EMB 为主。但是还是很喜欢 DLEPHI 的。 骂 EMB，只是对他们的错误决定，感到愤怒而已。 另一种是骂的是 DELPHI 本身。因为，他们用 DELPHI 找不到工作。工资低。 他们其实是后悔学了 DELPHI 。不是 DELPHI 的问题，还是他们自己的问题。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/31 14:39:42 | ||||
| 26楼： | 支持这个改进，这样写起来顺手，不会进化的语言说明他已死 ---------------------------------------------- MVCXE中国首个DELPHI MVC WEB框架:https://www.mvcxe.com/ |
|||||
| 作者： |
|
2018/10/31 15:15:21 | ||||
| 27楼： | 我也觉得。。。为什么不把C++ BUILDER做好一点。。。 C++ BUILDER比VC做界面方便太多了，就是IDE不太稳定，经常崩。。。 还有lib文件的格式问题，做成和VC一样的多好。。。 这几点能做到的话，桌面开发还有VC什么事。。。。 ---------------------------------------------- C++ builder 用户前来摸鱼。。。 |
|||||
| 作者： |
|
2018/10/31 15:22:58 | ||||
| 28楼： | 支持这个改进，又多一种选择， 不喜欢的人，可以不用。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 17:12:04 | ||||
| 29楼： | 这好像是将delphi 的开发人员引导到用其它语言 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 17:23:20 | ||||
| 30楼： | 我们的代码格式化功能要跟着改进了。 ---------------------------------------------- 欢迎使用CnPack IDE Wizards http://www.cnpack.org/ |
|||||
| 作者： |
|
2018/10/31 18:32:12 | ||||
| 31楼： | 楼上是大神。。。 ---------------------------------------------- 山外青山楼外楼,能人背后有能人弄.. |
|||||
| 作者： |
|
2018/10/31 19:43:30 | ||||
| 32楼： | 我早上看到这个贴子的时候还在想cnpack也要改进了 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 21:37:51 | ||||
| 33楼： | 加上也加上了，也就是说说我们的想法，交流而已。再不交流就又死气沉沉。 对于这个新功能，我没有其他语言的习惯自然觉得没必要。所以我会选择优雅，易读，不会这么去声明变量。 但是个人认为，新的开发者不会因为这个新的功能而转移过来，能吸引他们的只能是性能和fmx。不要说现在的硬件不需要重视性能，如果这样就不会有那么新语言，例如go，直接python搞定。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 22:26:41 | ||||
| 34楼： | 担心fpc跟delphi越来越不相同 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/31 23:10:36 | ||||
| 35楼： | 继续保持原来的写法 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/1 1:08:31 | ||||
| 36楼： | 不用var, 自动判断类型，不是更好， 最好是加入对GPU运算的支持。 ---------------------------------------------- 声明：本人不在论坛询问任何编程问题，请不要将我的帖子当成问题来回答。炒股一天，编程三年，不浪费时间了。 经常在外面,没空,不要找我.. |
|||||
| 作者： |
|
2018/11/1 5:48:05 | ||||
| 37楼： | 这东西真是有个鸟用 ---------------------------------------------- Great! |
|||||
| 作者： |
|
2018/11/1 7:45:46 | ||||
| 38楼： | 楼上这么说话，就不怕Delphi粉们喷死你！ ---------------------------------------------- 武汉天气不好 |
|||||
| 作者： |
|
2018/11/1 9:39:55 | ||||
| 39楼： | 如果安这语法写的代码，意味着不兼容之前的Delphi的版本，如果写给控件或类，以前的版本的Delphi编译不过去 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/1 9:41:15 | ||||
| 40楼： | 我觉得Delphi是少了个优秀的多线程内存管理器 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/1 10:12:03 | ||||
| 41楼： | @hq200306 如果是和近10年涌现的开发平台对比的话，少的东西多了，所以这个改进算是个好事了。语言层面的改进再代码层面是兼容的，原来的 var block 仍然保留。 ARC才是会影响现有代码的罪魁，这当时决策的时候应该是没想清楚，导致了现在移动平台LINUX平台和WINDOWS平台在代码层面的不兼容。从计算平台的角度，一致性是个很关键的因素。 移除ARC的决定我猜，仅仅是猜啊，就是移动平台和LINUX平台目前也没多少用户，积攒的代码也少，直接干掉，在10.4统一起来，后面才会有优秀的内存管理模型成立的可能。 ---------------------------------------------- Keep It Simple & Stupid |
|||||
| 作者： |
|
2018/11/1 10:21:54 | ||||
| 42楼： | for循环里面可以var这个还是可以的 其他的就看个人喜好了，习惯了js之类语法的还是不错吧 ---------------------------------------------- 虽千万人吾往矣！ |
|||||
| 作者： |
|
2018/11/1 10:23:00 | ||||
| 43楼： | 不想要 ARC，又提出狗屁的 内存管理模型。 你们还真不好伺候。 emb 就是被你们搞死的。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/1 10:39:43 | ||||
| 42楼： | http://www.cnblogs.com/findumars/p/9864127.html Delphi中ARC内存管理的方向 随着即将发布的10.3版本，RAD Studio R＆D和PM团队正在制作Delphi在内存管理方面的新方向。 几年前，当Embarcadero开始为Windows以外的平台构建新的Delphi编译器时，就核心语言功能和语言的整体感知而言，有很多讨论新Delphi与当前语言的兼容性。最终出现的决定是保持极高程度的兼容性，并采用一些重要而大胆的步骤来实现更能吸引新一代开发人员的语言。 什么是自动参考计数？ （具有弱引用的交叉链接对象） 其中一个变化就是决定采用新的移动平台内存管理模式，遵循Apple已经推出的iOS内存模式：自动引用计数或ARC。在使用垃圾收集的移动电话这样的内存受限设备上通常被认为是一个问题（因为您最终消耗的内存比严格需要的内存多，并且还会影响电池寿命）并且ARC提供了简化的内存管理模型，更易于使用在简单的场景中，完全确定性和健壮性。 这就是为什么Delphi选择相同的模型，扩展对象引用计数模型已经可用于接口很长一段时间了，使得它更强大的弱和不安全的引用，并将其扩展为普通的对象变量。该模型确实提供了一些显着的优势，其中一个最初的想法是在所有平台上将其扩展为Delphi语言。 ARC缺点 （缠绕弱和强引用） 在计划推出几年后，我们仍然看到它的优势和好处，但我们对ARC模型的缺点以及它在Windows和VCL应用程序中使其成为默认值的效果更加清晰。 。 我们长期以来一直认为ARC内存管理是对传统Delphi模型的改进，因为它消除并简化了一些内存管理。但是，我们在构建和维护大型库时，以及在复杂的代码库上与客户交谈时已经学到了这一点，虽然ARC在纸上看起来很棒，对于局部变量和更简单的场景，但它往往会给复杂场景带来很多麻烦。我们所有库的TComponent所有权模型都与ARC不一致，使得支持ARC的现有组件库变得复杂。 我们本可以决定在Windows上使用“完全ARC”，但这会导致现有应用程序和组件的严重破坏，造成比我们过去的Unicode迁移更多的麻烦 - 这是由于外部压力造成的提供良好的国际支持以及底层操作系统（从Windows开始）也是Unicode的事实。 我们有许多要求使ARC成为可选项，但是一个启用ARC的对象不会轻易与非启用ARC的对象共存，我们需要两种对象的容器，并且无法混合它们。这最终将成为一个非常复杂的场景。混合ARC和非ARC不是一个可行的解决方案，但是在不同平台上保持不同的内存模型最终会击败“单一来源，多平台”的整个想法，这是当今Delphi服务器端的核心原则（Windows和Linux）和所有平台上的客户端站点都可以构建FireMonkey应用程序。 另一个重要的角度是ARC具有运行时成本。虽然可以对事物进行优化和改进，但最终自动管理并非完全免费。虽然垃圾收集在开始时具有（非常高的）成本，但ARC在对象生命周期和对象交互方面有成本（除非您小心地将const用于所有参数传递）。禁用ARC的积极效果是可衡量的性能改进。最后，Delphi中的ARC与产品的C ++方面有点不一致，后者是RAD Studio不可或缺的一部分。 新计划：逐步淘汰ARC （在Delphi中使用接口） 考虑到所有这些因素，经过广泛的内部讨论，还涉及合作伙伴和外部开发人员，我们得出的结论是，最好的方法是将ARC模型作为默认的内存管理解决方案，并弥补其损失与其他选择。 实际上，10.3 Rio版本中的Linux 64位编译器将提供Windows平台的传统Delphi内存管理，使您的Windows和Linux服务器端代码完全等效 - 至少在Delphi语言和内存方面管理。 前进的计划是不接受ARC用于即将推出的macOS 64位平台（因此所有桌面平台都将保留在非ARC模型上）并且将来也禁用ARC用于移动平台（很可能是在10.3）之后的下一个主要版本。请注意，在10.3 Rio中，移动编译器仍然启用了ARC，与10.2完全相同。 现代记忆管理还有什么？ （来源：https：//pixabay.com/photo-1751201/） 我们仍然认为引用计数内存管理是相关的，但我们更愿意利用和扩充Delphi中接口和字符串使用的现有引用计数模型，而不是为它引入新机制。这种情况已经存在了很长时间。如果处理不当，接口引用和对同一对象的对象引用会引起麻烦，但这是大多数Delphi开发人员已经知道如何处理的问题，并且有很多关于该主题的文档。 最近使用弱引用甚至不安全的引用扩展了接口引用。这些附加选项大大增加了“ARC for interfaces”的功能和灵活性。换句话说，虽然我们要删除ARC以进行对象引用，但是用于接口引用的ARC是已经并将继续可用的语言的一个特性。 除此之外，我们希望改进和简化具有堆栈引用的本地短期对象的生命周期（和内存管理）的管理。这是我们将在10.3中引入的一个非功能，但我们正在积极研究这些功能，并且可以由开发人员利用托管记录（10.3中的新语言功能）部分实现。 包起来 （内存泄漏跟踪变得简单） 虽然我们知道几年前对计划的这种改变可能会令人惊讶并影响现有代码，开发人员对ARC模型不满意，支持不同平台上的多个模型，以及与本机内存管理相比性能损失，很可能会欣赏这个决定。 提供进一步简化Delphi内存管理的替代方法是在RAD Studio的路线图中，但当前的一组功能（具有引用计数和支持弱和不安全引用，组件所有权模型和标准通用实践的接口）已经提供了一个很好的框架减少Delphi开发人员对手动内存管理的担忧。 最终，编程语言中没有完美的内存管理解决方案，因为自动编程语言有其缺点，而手动编程语言（手动）也是如此。德尔福在过去一直保持着良好的平衡，这种平衡今天仍在继续，并且将来只会有所改善。 ---------------------------------------------- |
|||||
| 作者： |
|
2018/11/1 10:45:42 | ||||
| 44楼： | ARC 绝对是一块臭肉。 没有吸引到新的人加入 delphi 阵营，反而是将老同志， 一步一步的推向 fpc+lazarus. 起码这么大的改变，应该提供编译选项，让用户决定是否开启 ARC ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/1 11:51:34 | ||||
| 45楼： | 我是习惯传统的内存分配，用就申请，不用就释放，用起来心中有数。出了个arc，用起了有点虚，相同代码，不同的执行效果（新建的局部对象实例，生命周期，和传统内存管理不一致，给自动给释放了），总是有点担心，支持他们去掉 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/1 12:36:56 | ||||
| 46楼： | 语言层面的增强还有Managed Record，这个是自动内存管理的，同时Record有了构造和析构函数（无参） ---------------------------------------------- Keep It Simple & Stupid |
|||||
| 作者： |
|
2018/11/1 13:18:16 | ||||
| 47楼： | 又加了语法糖... ARC去掉，.Net依赖去掉，提高运行效率，想尽一切办法进行编译优化，加快编译速度，跟上主流编译器的步伐，这也许才是我心目中所需要的Delphi... 总之一句话，瞎整乱七八糟的各种糖，不如好好优化编译器，一定要记着你是做编译器的。。。请不忘初心。。。 再多吐槽两句吧：要想吸引到别的开发人员，你得优秀至少10倍以上，一两倍都没用，这么简单的道理总不至于不懂吧？实际开发上，能跟上人家的更新步伐，看到人家的车尾灯都已经算不错了，还指望吸引？ ---------------------------------------------- Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！我去WC吐一会儿去！ |
|||||
| 作者： |
|
2018/11/1 13:32:21 | ||||
| 48楼： | @feiyanm 如果是团队是做编译器的估计早死掉了，现在不是早年卖编译器就能让一个公司活下去的时代了。吸引？ 以我的认知可能性为零。 另外，我不觉得这是语法糖，应该属于语言范式方面的变化。 ---------------------------------------------- Keep It Simple & Stupid |
|||||
| 作者： |
|
2018/11/1 17:09:10 | ||||
| 49楼： | 最简单的 跨行字符串都不支持，搞什么呢 var str :string; begin str := 'single line string'; 俺需要这样的跨行字符串支持： str := 'first-line second_line'; 而不是这样的： str := 'first-line ' +#13#10 + 'second_line'; 用+ 号拼接太丑陋了！ end; ---------------------------------------------- kittyapp |
|||||
| 作者： |
|
2018/11/1 17:19:37 | ||||
| 50楼： | 最佳新秀语言 Python语言 定义一个跨越多行的字符串方法 使用三引号 s = """I'am learning Python"""" ---------- C#语言中，字符串前 加@ 表示强制不转译。 如果你的字符串中有大量的\字符，而不是想用转义，那就写@来取消\转义字符。 还有就是字符串可以换行。 string a=@"hello C# ！"; ---------- 宇宙最佳 php语言 用<<< 来支持跨屏字符串 <?php $xx=<<<html php is good！ html; echo $xx; ?> ---------- groovy语言 用3个单引号来 支持跨行字符串 三重引用字符支持多行字符串，不像简单的用单引号或者是双引号字符串，他们是不支持多行字符串的，比如： str1='''hello Groovy''' println(str1) 至少以上4种语言都支持跨行字符串,其他支持的语言还未统计进来... ---------------------------------------------- kittyapp |
|||||
| 作者： |
|
2018/11/1 18:33:05 | ||||
| 51楼： | delphi 也可以做成 什么新语法都支持。 就是 VCL FMX 没空做。 VCL 还停留在 XP 阶段。 FMX 停留在 XE2 阶段。 然后，DELPHI 和 EMB 就真的死了。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/1 19:30:00 | ||||
| 52楼： | 不能用其他语言语法的个别美来否定Delphi语法的大部分美。 就像换行这个，如果你的字符串够长，Delphi的换行效果还是很好的，至少看起来很整齐。 再说了，在代码里面出现过长并且杂乱无章的字符串似乎算不上是一件什么长脸的事情，可以去看看一些大师定义字符常量的风格，怎么看都不会丑。 ---------------------------------------------- 虽千万人吾往矣！ |
|||||
| 作者： |
|
2018/11/2 14:36:40 | ||||
| 53楼： | 咱们在抱怨。我猜RAD的工程师肯定也在抱怨。 不知道现在RAD总共多少开发工程师。摊子铺的这么大，VCL要做的工作都已经落后了至少十年了。RAD挣不到钱，开发队伍人力短缺，从客户到支持、研发、领导所有人都在抱怨。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/2 15:48:51 | ||||
| 54楼： | 在 delphi7 以前的 win32 时代， DELPHI 确实是靠编译器吃饭。 后面的线路已经很清晰了，EMB 也向 LLVM 靠拢了。基本和竞争对手没有太大的差异了。 只能说靠集成调试环境（IDE+工具链）。 现在的 delphi 对我来说，基本是一个编辑器和代码验证工具。 写完代码，在 delphi 编译通过，验证逻辑正确，然后再用 fpc 编译成各个平台代码， 部署到生产环境中。 EMB 千万不能有： 靠语法增加方言的方式，来甩开竞争对手。 过去的多个大公司， 都是死在这点的。这是愚蠢的想法。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/2 16:13:55 | ||||
| 55楼： | 专心于，IDE + 工具链，也许结果比现在好。 ARC 搞残了跨平台和效率 Unicode 搞残了老系统升级到新版本的可行性 只专心于IDE，不会有ARC，也不会有Unicode，更不会有string[0] 也不会所有对象隐含增加一个锁定域，无论写不写多线程的代码，都要浪费这个域。 同时，还彻底封死了了，C++对象与delphi对象具有相似内存布局，可以相互使用的可能性。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/2 16:32:36 | ||||
| 56楼： | Unicode 必须有。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/2 17:43:04 | ||||
| 57楼： | Delphi7 的时候，就已经有 WideString， 就是 unicodeString 的基础。 根本没有必要把缺省的 string 改成 wideString 。 导致老代码通通完蛋， 老程序员也走了一批。 utf8 , 其实其排列就是 ansiString , 和以前的 string 一样。 只要内核增加 utf8 支持, 然后再优化 wideString, 这样单字节和双字节的 unicodeString , 就都能很好支持了。 后面还搞出一个愚蠢的 string[0], 部分平台1，部分平台0. 更加让人抓狂。 每次升级，应该保持老的不变，兼容历史资产，然后再去增加新的创新。 否则用力过猛，昏招频出，自己把自己搞死。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/2 17:52:46 | ||||
| 58楼： | 去看看老外这么看待这次更新的，大家无不为之欢呼雀跃，和这里的口诛笔伐以及杞人忧天的画面有着天壤之别。 https://plus.google.com/+RafaelDipold/posts/NCnhrFYb7Yi
Delphi4Linux Delphi三层/FireDAC 技术群：734515869 http://www.cnblogs.com/rtcmw |
|||||
| 作者： |
|
2018/11/2 17:54:05 | ||||
| 58楼： | 从商业操作的出发理解： 利用自己的主导地位，为 pascal 语言增加方言，并将增加的差异部分，申请专利或者相关的著作权保护。这样认为的制造不兼容，为竞争设置更高的门槛，拖垮竞争对手。 过去十年，一直和 delphi 保持兼容的、紧跟的，就是 FreePascal (fpc) . 今天的FPC，除了 IDE （lazarus ) 尚不如 delphi 外，其他方面，都已经 超越了 delphi7 等 emb 相关产品。其编译器性能和质量，可圈可点。 EMB 的策略，没有拖垮对手，却把许多老用户，推给了 fpc. 今天的IDE，也不好做了。前些天改用 visual studio code 来写 dephi 代码， 发现体验也是相当不错的。 不如把 delphi7 以前的东西开源吧，换个活法。 EMB ， 靠IDE软件卖钱来维持，够悬的。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/2 20:43:38 | ||||
| 59楼： | 我期待着ARC，我更喜欢在局部定义变量的方式，就是C++那种方式，很赞。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/3 2:12:08 | ||||
| 60楼： | 增加一些实际上是语法糖的语法，结果就是认为形成孤岛效应。ARC是最蠢的。其次是string[0].我只觉得Unicode和匿名函数有用，其它的都没用 ---------------------------------------------- http://blog.sina.com.cn/bmsrnote |
|||||
| 作者： |
|
2018/11/3 12:00:12 | ||||
| 61楼： | ARC的开始时候，老外们不也为之欢呼雀跃，结果呢。 XE2开始，花费6，7年的时间，搞这么个东西， 浪费自己的生命，还浪费用户的生命。 然后这玩意还至少花，2，3年的时间彻底的丢掉。 前后要浪费10年的发展机会，10年的资金投入，用户投入。 当初力排众议，做这决策的人付出代价了吗？ ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/3 12:30:51 | ||||
| 62楼： | 实际开发，ARC和string[0]，编译不同平台时，要小心翼翼的使用，否则会出问题，也就是说给自己下陷进，计算机本来就是实现唯一化的事，弄不同平台，不同写法，把自己弄晕 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/3 12:33:21 | ||||
| 61楼： | @zwjchinazwj (蒲石) var obj : Tobject local; 想法非常好啊，不过是要多写个单词，如果语法变成这样是不是会更方便点 local obj : TObject; ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2018/11/3 12:40:30 | ||||
| 63楼： | 局部对象变量自动释放，是个好主意，局部变量其生命周期和内存开销，估计记录类型一样 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/3 14:36:20 | ||||
| 64楼： | 默认string 为 AnsiString 这个也可以。 但是 UI 上的 String 必须为 UnicodeString 比如 Caption Text 这些属性。 这样 就完美了。 API 也应该默认为 W 版本。 支持 PWideChar(AAnsiStr) 内部先把这个 AAnsiStr 转为 WideString 再转为 PWideChar。 这样，旧 的 ANSI 兼容了。 同时，也完善了 多国语言支持。 可惜好像是从2007 开始就已经默认 Unicdoe 了。 但是 下标 绝对的错误的决定。 ARC 现在他们都后悔了。 什么时候，他们会后悔下标呢？ ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/3 21:38:59 | ||||
| 65楼： | ARC设计得很蠢，unicodeString给升级带来点麻烦，下标的不一致，这些涉及的成本基本可以忽略，无论对于多大的工程。所以这些都是鸡毛蒜皮的事情。 如果delphi十几年前，我说十几年前，坚定走开源路线，现在局面肯定不同。即使现在，把IDE和编译器开源免费，对中国市场更友好，起码也能给delphier带来不少希望。 所以，EMB从来没为中国用户考虑过什么，你们瞎操心什么？！ 早转FPC早超生 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/3 21:51:36 | ||||
| 66楼： | 破坏了 循规蹈矩 还不如在ide上下手 让编写更方便 ---------------------------------------------- [alias] co = clone --recurse-submodules up = submodule update --init --recursiveupd = pullinfo = statusrest = reset --hard懒鬼提速 https://www.cctry.com/>http://qalculate.github.io/downloads.htmlhttps://www.cctry.com/
|
|||||
| 作者： |
|
2018/11/3 22:59:38 | ||||
| 67楼： | 做软件就是做未来，无论是开发工具还是应用系统，看不到未来或者纠缠在现状，对于事情没有价值。 通用编程语言和开发工具，个人认为已经没大的发展可能，反而 平台+DSL 还很有市场。 目前和未来不久，运算力会变得很富余，这是机器自动编程兴起需要的势。如果还不相信，我可以再点出另一个关键点： 要说明这关键点，要用个实例， 同样是面对公式 E=MC2 ， 对于稍有点文化的人，他可能会想到质量 能量 对于想制造武器的武器专家，他可能会想到一些跟公式有关的设计细节 对于一只狗，它可能不会想到什么，但肯定有感觉；如果有人天天穿着印满E=MC2的衣服去喂食它，那狗在看到公式时可能会有亲切的感觉。 对于一只龟，它可能不会想到什么，但肯定有感觉。 对于一块石头，它连感觉都不会有。 什么意思？ 就是说如果把人脑所能思考能表达的所有东西称为确定性信息。 1. 确定性信息对于智能体的意义就在于它能激活哪些神经元的连接。对于任意一智能体，当他看到听到闻到想到任何一个确定性信息都肯定能激活若干个连接，这就是确定性信息对于思考的价值。 2. 确定性的信息是思考的结果，不是思考本身。因此，凡宣称能实现强人工智能的理论，只要理论里牵扯到跟思考无关的确定性信息，比如：数据结构 算法等，那么这理论肯定实现不了。 什么是非确定性的信息？ 比如： 我要你想出在现实世界里画一个圆圈的办法。你是想不出来的，只能想出画一个近似圆的图形的办法。 客观世界里根本不存在 1+1=2、E=MC2、圆等等你所想到的所有东西，这些东西只是你思考的结果。对于不同思考行为的智能体，这些东西肯定有所不同；肯定在某些情况下，这些你所信奉为对的公式就会出错，也就是没有绝对正确的真理，这是由思维规律决定的，不是由客观世界决定的。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/3 23:26:21 | ||||
| 68楼： | 说错了，有些确定性信息是客观存在的，比如：喜欢、爱、恨等情感，凡情感都无法精确描述也没有形状但却客观存在。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/4 0:20:41 | ||||
| 69楼： | 经常看到计算心里阴影的面积，不知道算什么客观存在 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/4 9:49:56 | ||||
| 70楼： | 你说的就是我上面所说的，情感都不能精确描述，情感是智能最奥秘的地方，它既是确定性信息，却客观存在，之所以是客观存在因为它有生理基础，即跟内分泌密切关联。 语言、算法、程序、公式、规律等等所有脑子里能用来思考的，都是思维（或者思考）的结果，而不是思维的本身；它们在大脑里只是以激活某些神经元的连接而存在。 爱因斯坦为什么会想到 E=MC2 ？ 只是他大脑里这公式相关的连接被激活了。 ---------- 作为一台会自主思考的机器（或者叫通用人工智能或者强人工智能），其解决方案里不可能包含跟思维无关的确定性信息（即领域信息），或许它的系统结构里需要算法去提高性能，但解决方案本身不可能包含领域相关的信息。目之所及的系统（包括alphago）和人工智能理论，都不能实现这目标；特别那些宣称模拟人脑推理、分析等能力的理论，根本行不通。 既然我们所想的都是思维的结果，想根据结果通过推测去掌握思维的本质，要100%掌握是不可能的，就像从外部观察研究大象，无论如何都掌握不了大象内部结构与运作。只有一个办法：依靠计算机的探索能力。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/4 11:58:08 | ||||
| 71楼： | 我揭示的这个关键点对于日常生活同样有极大的指导意义。 第一， 如果有人假设人能做到100%理性，那他肯定错了。人只能做到相对理性，而且理性部分并不多。 大脑每时每刻受到来自三方面的作用： 1. 外界的刺激 2. 身体内部生理的作用 3. 大脑这思维系统（图灵机）的运作规律 如果通过脑电图，会看到激活的神经元连接每时每刻都在变化。而激活的连接决定了脑子里想的事情。所以，人的神志（或者意识）是不能控制他下一秒要想什么！！只能引导，不能控制！！ 催^眠、毒^品，逼供的迷^幻^药就是最好的实证。别以为人能控制一切，人连自己想什么都控制不了。 第二， 即使不考虑成本，用软件工程的办法永远无法制造100%满足需求的程序，除非需求属于理论上的需求，比如：数学方程式的求解。 一旦需求跟现实世界关联，永远有需要细化的地方，因为每个用户的需要都有所不同（起码认知上就有差异）。从这一点就可以证明软件必须具备智能，才能100%满足人类的需要。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/4 13:24:34 | ||||
| 72楼： | 可以另外开贴专门讨论了。 @hawke2e ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/4 14:35:35 | ||||
| 73楼： | 有更新说明delphi还活着，还在进步。 期待delphi10.3 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/4 15:11:42 | ||||
| 74楼： | 最古老的C语言跟pascal一样 变量必须声明在函数最开始的位置，因为当吃的处理器差，变量声明在函数刚开始可以确定栈的起始位置。否则编译器要多趟扫描。 当时C++做了革新，让变量可以在任何位置声明。带来了很多好处。比如确定变量的作用域，离开作用域就消除等。 我认为C++都能吸收Pascal的引用参数，发展处引用类型；而Pascal抱残守缺，非要确定变量作用域，只有引用参数，而没有引用类型。等等完全可以吸收现代语言的最先进特性，进行进化。否则就是个活化石而已。 随处声明变量这次10.3做了改良。那么下一步，我觉得最需要的特性就是： 1.引用类型，只有具有真正意义上的引用类型，泛型才具有效率。 2.结构体的默认构造和析构函数。只有这样才能结合操作符重载发展真正的算法库。也才能发展处真正意义上的智能指针。 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2018/11/4 21:54:44 | ||||
| 75楼： | @wr960204 结构体的默认构造和析构函数10.3已经有了，只是构造函数是无参的 ---------------------------------------------- Keep It Simple & Stupid |
|||||
| 作者： |
|
2018/11/4 22:09:23 | ||||
| 75楼： | 重新分析了一下这个特性，我觉得，是在类似C语言的宏定义中有用，如果宏定义中需要使用临时变量，原来Pascal就搞不定，所以Pascal没有宏定义，只有inline函数。 而这次，加了这样的特性，却没有宏定义，那就本末倒置了。还不如只让宏定义中支持局部变量，直接写代码可以先不支持。 ---------------------------------------------- Great! |
|||||
| 作者： |
|
2018/11/4 22:53:30 | ||||
| 76楼： | 最后，我想指出：“var Obj: TOjbect local;” 是个馊主意。理由： 1. 过程或函数所占栈的空间大小在编译时就得确定。 为什么object pascal编译速度比C++的快很多很多，就因为在编译某个类时不需要考虑其它类的大小。 2. 栈内元素的访问速度要比访问堆内的要快，缺点就是栈大小要比堆小很多。在栈内分配类实例空间的做法本来就不提倡。 object pascal没必要学习C++语义上的完美主义，保持自身优势最要紧。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/5 10:53:34 | ||||
| 77楼： | 至少在Windows平台上，Delphi添加Unicode的支持是有必要的。 首先是基于Unicode的app能够更方便的支持同时使用多语种文字。 另外，现在的Windows版本都是基于NT内核。NT从设计一开始就已明确内核代码中字符串全部以Unicode（具体而言是UTF-16标准）表示。这样，Windows API的ANSI版本通过ntdll.dll或者win32u.dll调用相应的内核态例程时，必须先将ANSI字符串转换为相应的UTF-16字符串，内核态返回的字符串也需要做反向的转换。而Windows API的Unicode版本不需要这种转换。在需要频繁调用Windows API的app中，这两者的性能差异是能够测试到的。 当然是否有更好的支持方式，比如添加Unicode的支持后不终止对基于ANSI的RTL/VCL等类库的支持，我认为可以探讨。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/5 10:54:22 | ||||
| 78楼： | https://quality.embarcadero.com/browse/RSP-21464 10.3 内测版 把这个 BUG FIX 掉了。 够快的。 不到 2 天时间 BUG OPEN 不到 2 周时间 BUG FIX 。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/5 11:15:58 | ||||
| 79楼： | @hawke2e (hawke2e) 1.“过程或函数所占栈的空间大小在编译时就得确定” “var Obj: TOjbect local”编译期就可以确定,参考InstanceSize 构造函数并不是用来给对象分配内存的，更多的只是初始化对象，建立虚方法表 具体内容可以参考以前的一个用法： P := GetMem(TSomeObject.InstanceSize); TSomeObject(P).Create 其中local影响GetMem部分，这在编译期，通过InstanceSize就已经确定。 运行期，只需要在begian开始处执行TSomeObject(P).Create btw: 其实运行期确定，我也不觉得有什么问题,无非是改ESP大小， 获取大小废点时间 2.至于栈大小及空间限制，不成为有力的反驳理由，这个就不讨论 (编译器完全可以检测出来，并给予编译错误和报告或者警告)。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/5 11:23:49 | ||||
| 80楼： | @ wr960204 (武稀松) >> 1.引用类型，只有具有真正意义上的引用类型，泛型才具有效率。 这个不会做的，给你看个链接，我提的建议，被Close了 https://quality.embarcadero.com/browse/RSP-16505 >> 2.结构体的默认构造和析构函数。只有这样才能结合操作符重载发展真正的算法库。也才能发展处真正意义上的智能指针。 这个他们似乎正在往这个方向靠。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/5 11:40:40 | ||||
| 81楼： | 还有个我以为非常合理的建议，被否了，即使我说的理由充分， 他们也没有拿出足够的理由反驳。 最终被关闭的原因是：Marco Cantù 说： "The more I look into this request, the more I don't like it. " https://quality.embarcadero.com/browse/RSP-16268 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/5 11:51:57 | ||||
| 81楼： | 相反， 我认为应该是多用栈空间。 我就是比较喜欢用栈空间。每个线程有 1M，不够还可以修改编译设定。 特别是服务类的程序，用好栈空间，可以有效的减少堆内存的碎片化。 函数过程用到的局部变量，能用栈的，应该考虑尽量在栈上分配。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/5 12:38:38 | ||||
| 82楼： | 如果论坛里有人对我说的感兴趣，希望能认真去阅读，不懂可以跟帖问我。我从小到大养成的习惯，跟人交流不怎么看他怎么说而是看他为什么这么说，所以即使对方说得乱七八糟对我的理解影响很少。所以我自己也不注重表达方式，加上语文不咋地，有时一不注意就表达不清晰。 ---------- @ zwjchinazwj (蒲石)：你没理解我的意思。 为什么C++编译这么慢？因为如果类A使用到类B，那么在编译类A前必须先编译类B，所以一旦某个类修改了，就得相关联的类全部都要编译一遍。 为什么要这样？其中一个原因就是因为允许在类A的函数里在栈上定义类B的实例。因为函数占用多少栈空间，在编译类A时就要确定，所以要先计算类B占多少空间。 object pascal没有这问题。 至于第2个理由，情况就摆在那里，要看程序的嵌套调用深不深，类大不大，确实没有必须这么做的理由。不过，我倒想说一件事： 在编程时，有些语言特性最好先不要考虑进去，比如：用不用inline，record是否4字节对齐等。因为你要把注意力集中的设计上，否则考虑这考虑那，效率就低了；这些可以留到后面优化再考虑不迟。 所以，你就把类实例都放到堆上就行，不需要过早精益求精。 特别是系统复杂时，你根本不可能会去考虑嵌套调用深不深。 至于服务类程序控制堆内存的碎片化，尽量用栈也解决不了，所以不是多用栈的理由。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/5 12:51:03 | ||||
| 83楼： | 如果能开启不显示楼上的发言，这种功能。 可能也会有人选择 把楼上 和 我的 ，一起不显示了。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/5 13:01:29 | ||||
| 84楼： | 其实我的耐心已经耗得差不多，应该以后都不会怎么发言 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/5 14:03:10 | ||||
| 85楼： | @hawke2e 在我看来，不存在多用栈，或者少用栈的绝对理由。 栈上分配内存，回收内存，效率之高，是任何内存管理都无法比拟的。 适合的场景用适合的方式去做，是我认为合理根据。 这是我反对把string全部统一成utf16的原因所在，这个世界本来就是多样的 需要尊重客观规律和事实，utf8 utf16 ansc 甚至utf32 都大量存在，就该有与之适配的工具去使用和表达。 具体到栈和堆，也是一样的。不应特别排斥栈或者堆，过尤不及。该用就用。 另外，你有点曲高和寡，你的智能编程，这里多数人，包括我，跟不上你的节奏。 很多事情就是这样，没有具体的案例，理论上再合理也无用。 所以，依我的理解，你不能只停留在理论层面，必须有说服力的案例支撑你的理论。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/5 23:54:13 | ||||
| 86楼： | 想起常看到的一句话： Show me your code ! ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/6 11:40:13 | ||||
| 87楼： | @zwjchinazwj (蒲石) 结构体的泛型用结构体指针固然能够达到不需要几次复制的目的。但是毕竟不方便。如果能增加引用类型，那么用起来就会方便流畅，可读性也会好一些。 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2018/11/6 11:44:23 | ||||
| 88楼： | 另外关于栈的问题，我觉得java是太激进了，所有对象都是堆对象。统一由垃圾回收做处理。而C#在这方面我觉得做得非常好，引入了struct类型。 这样如果仅仅是在局部使用的struct就可以高效的回收了。 C#比java诞生的的晚，针对性的解决了很多Java的问题。并且C#又是安德尔斯这样的语言、编译器大家设计的，自然会更加高效和优美。去除C#身上的微软的标签，各方面都比Java要优美和高效。 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2018/11/6 13:14:12 | ||||
| 89楼： | @wr960204 (武稀松) 我那个建议其实就是增加引用类型，但可能和你希望的还有差距，然而被否定了。 另外，类的嵌套声明，最初我还是比较接受的， 但是看了TParallel的代码，我难受了， 我现在开始怀疑，嵌套类声明也是个不好的东西， 至少这么个写法让读代码的人很难受 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/6 15:38:49 | ||||
| 90楼： | 作为一个delphi最终产品使用者，对emb反复在语法改进（内联、匿名、泛型）上用力谈点感受： 当发展到web时，delphi有了intraweb，理念先进，使用方便，但emb不肯在iw上投入时间精力，只有几个寒碜的组件，没办法做真正的web，结果输给了java； 当发展到android/ios时，delphi有了FMX/datasnap，理念先进使用方便，但emm仍然把倚天剑屠龙刀隐于江湖，做起app来依然问题多多，再次输给了java。 我说emb，你能否做点靠谱的事，抓重点补短板强弱项，向你的前辈borland学习，在CS时代与.net/java三分天下甚至号令江湖，让使用delphi的人有点道路自信？ ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/6 23:28:25 | ||||
| 91楼： | 精简下臃肿的RTL吧，XE4以后的RTL已经绝望了，继续坚守XE2 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/7 9:29:25 | ||||
| 92楼： | 真不明白，慢就慢一点吧，有什么大不了的。 -by emb 老板。 我也想改啊，没空啊，不过 10.3 的 RTL 稍微快了那么一点点。 -by rtl 开发。 另外 臃肿 也不一定就慢。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/7 10:06:12 | ||||
| 94楼： | 说起服务端稳定以及内存碎片，我倒想说一个挺无敌的思路： 设立监控进程（或叫守护进程）和服务进程。 服务进程响应客户端请求，处理。 守护进程职责： 1. 负责分发转发客户端请求到服务进程 2. 以一定策略（比如：定时 比如：判断服务进程的碎片严重程度），重新启动一个服务进程，把原来转发到原服务进程的请求都转发新进程那 3. 等原服务进程没有请求处理了就杀掉它。 这种架构跟内置垃圾回收碎片整理的服务端的优势： 1. 对服务端开发的要求以及开发成本都低了很多。 无需研究复杂的垃圾回收机制，现在C# JAVA的垃圾回收也不见得很满意 内存泄露也无需过于紧张 2. 稳定性提高了很多。真正实现7*24甚至永不宕机。 3. 这框架的开发也不难。 劣势：有些应用不适用。 但我觉得不适用的案例很少。 有哪位感兴趣的研究下，做出来大家共享下。 如果CG EMB一早推出这架构，估计WEB也会有delphi的一席之地。 其实这思路所用策略是借鉴生物的，系统靠内在调节保持稳定很难而且成本很高，干脆死了算，靠新生来重新适应。 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/7 10:27:34 | ||||
| 95楼： | 现在delphi和FPC做服务端的障碍主要在于稳定性不足，没有个优秀的内存管理。 有着这框架就解决了，虽然性能上有些欠缺，现在硬件这么便宜，可忽略。 你也不需要考虑是栈分配还是堆分配、不需要引入struct类型、不需要造对象池、不需要过于紧张有没有释放。 100个好 ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/7 11:33:49 | ||||
| 96楼： | 要求那么多干啥？D只要不瞬间爆炸立即驾崩就不错了，还要啥自行车？ 多年前OI都已经放弃Pascal了，还想啥？ 最后为了安慰一下某些心胸狭隘的小心肝，我们再来喊一遍Slogan: Delphi威武，千秋万代，一统江湖！ ---------------------------------------------- Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！我去WC吐一会儿去！ |
|||||
| 作者： |
|
2018/11/7 19:58:01 | ||||
| 97楼： | Delphi与其抱残守缺，在慢慢萎缩中死去。不如大刀阔斧改进，吸收各种语言的优点，在拼着爆发一回。 加入随意声明变量是很好，但我觉得仅仅加入这个特性还是不够的。完全可以更加激进。 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2018/11/7 21:23:22 | ||||
| 98楼： | 完全可以重新发明一个新的语言。 有 LLVM 做基础，搞一个新语言，现在门槛很低了。 以 Pascal 为蓝本，把一些想改革的，一部到位。另外保留一些该有的过度， 让 delphi/pascal 的老程序员，方便的过度过去。 这样没有历史包袱，又能留住老客户。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/8 8:47:55 | ||||
| 99楼： | @linsigong，这个值得讨论，也更应该深思！ 1.语言也仅仅是工具，工具！新语言是为了解决新问题而产生的，有没有想过要解决什么问题？ 2.解决问题与门槛高低无关，如同AI一样，无论门槛多高，都会投入大量人力物力去解决。 3.历史不是包袱，历史只能是经验教训，提醒我们吸收精华去其糟粕，退一步讲，人类的每一次进步，都是站在历史这个巨人肩膀上的飞跃。 4.Pascal这门语言本身没有任何问题，发展得好就会和c、c++一样前途无量，发展不好，就会走下坡路，被人玩死。被某些人恶心死（吐槽无能啊）！ ---------------------------------------------- Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！我去WC吐一会儿去！ |
|||||
| 作者： |
|
2018/11/8 9:20:02 | ||||
| 100楼： | 不求一统江湖，但愿三分天下。delphi的下一个版本，我觉得重点不要放在语言特性更新上，没泛型一样做复杂的系统，前辈们就做得很好，譬如，delphi尽管有指针，由于语言特性好，其实最终用户在很多场合并不需要操作指针而高效率达到目标。我觉得一下个版本，最重要的使用是做好android/ios和三层的平台开发。在三层，已经有datasnap，我已经能够把并发访问做到15000个线程，绝大部分都够用了，如果datasnap的低层能够弃用indy而使用http.sys（这个对emb并不是难事，只须改几个核心底层单元文件），速度稳定易用性将大幅提升，5万并发不在话下。如果能够以设计vcl的精致设计好fmx，则可以吸引大量app设计者。 总之，delphi的命脉在于datasnap/FMX，它好则delphi好它废则delphi败。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/8 10:04:40 | ||||
| 101楼： | 第5种支持跨行字符串的语言： JavaScript 语言 用反引号（tab上面那个键）支持跨行字符串 JavaScript ECMAScript 6.0(以下简称ES6)支持 template string $("#result").append(` I am Javascript! `); 第6种支持跨行字符串的语言： CoffeeScript 使用三个引号（""" 或 '''） html = """ I am coffeescript！ """ 第7种支持跨行字符串的语言 TypeScript 用反引号 支持字符串模板 console.log(`<div> <span>I am <span>TypeScript! </div>` ) ---------------------------------------------- kittyapp |
|||||
| 作者： |
|
2018/11/8 10:16:08 | ||||
| 102楼： | 第8种 通过插件支持 跨行字符串的语言 Java语言： 通过一个叫 Monalisa 的Eclipse插件，来支持跨行字符串 在大花括号内输入输入要拼接的字符串: String lines = ""/**~ { SELECT * FROM user WHERE name="zzg" }*/; System.out.println(lines); https://github.com/11039850/monalisa-orm/wiki/Multiple-line%20syntax Monalisa 插件好像是中国人写的 第9种 支持跨行字符串的语言 Ruby语言： 用 << 来支持 多行字符串 heredoc 基础的用法 def print_heredoc puts <<EOF this is the first line this is the second line EOF end 第10种支持跨行字符串的语言 强大的Golang语言 声明一个多行字符串的变量 使用反引号 ` 来包含即可。 package main import ( "fmt" ) func main() { str := `hello go lang! ` fmt.Println(str) } 第11种 支持跨行字符串的语言 Perl语言 heredoc 语法支持跨行字符串 $str = <<"EOF"; hello, Perl! EOF 第12种 支持跨行字符串的语言 开发android app的新秀语言 kotlin语言，用3个"""支持跨行字符串 var s2 = """ hello kotlin！ """ 第13种 支持跨行字符串的语言 dart语言，用'''来支持跨行字符串 Flutter是谷歌的移动端跨平台UI框架，支持开发iOS和Android App。 Flutter基于dart语言！ void main() { var str = ''' hello, dart! '''; print(str); } 第14种 支持跨行字符串的语言 LUA 定义多行字符，用[[ ]] LUA 是开发游戏最喜爱的语言! str= [[ I am Lua! ]] print(str) ---------------------------------------------- kittyapp |
|||||
| 作者： |
|
2018/11/8 10:55:34 | ||||
| 103楼： | 其实我是支持arc的，传统的开发人员还是有释放的习惯，在释放时改用freeandnil就可以了，保留了自己的习惯也不影响arc；现在的硬件成本这么低，真没必要太考虑资源消耗的问题；真在乎运行效率的话，就转向纯C的解决方案了，说到底就是怎么去衡量开发效率的问题。 a:= TObject.Create(); try finally FreeAndNil(a);//a.Free; end; ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/8 10:59:42 | ||||
| 104楼： | 楼上的，WIN 等桌面平台，你可以说 硬件够用。 但是 偏偏 桌面 不开 ARC。 只有手机平台开 ARC了。 很多人的 FMX APP ，经常被杀，就是因为他们占内存，还懒得销毁。 毕竟 ARC 也只能等你 对象生命周期到了，才销毁。你全局的，就不会主动帮你销毁了。 一些局部的，你运行时间很长。也和全局的差不多了。 不用了主动销毁，无论是不是 ARC 都是应该做到的。 否则 手机 杀你 没商量。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/11/8 11:14:24 | ||||
| 103楼： | 第15种 支持跨行字符串的语言 苹果公司的Swift语言，开发Ios App的新语言 Swift 3不支持跨行字符串，但是Swift 4 已经支持把字符串写在一对 """ 中，这样字符串就可以写成多行。 let str = """ hello, Swift! """ print(str) ---------- to zwjchinazwj (蒲石)大侠: 您向delphi官方反映一下吧，希望添加 跨行字符串 的功能 至少已经有 10多种语言都支持跨行字符串， 支持跨行字符串 是 语言界的 大势所趋，人心所向！ 希望delphi官方从小事做起，先把 最简单的跨行字符串 功能加上，然后再搞其他高大上的东东。 勿以善小而不为。 海不择细流,故能成其大;山不拒细壤,方能就其高 试问一个新手学习一门语言，定义一个跨行字符串都这么困难， 他还愿意试用其他功能么？ ---------------------------------------------- kittyapp |
|||||
| 作者： |
|
2018/11/8 14:32:58 | ||||
| 105楼： | @bigboy2050 你高看我了。 一来，我对EMB完全没有影响力， 二来，跨行字符串对我来说还真的是没什么特别感觉，对于Web开发，经常要输出html字符串文本的需求来说，诸如php等，有跨行字符串是很重要的，甚至字符和代码混排。但对于原生开发，似乎没有这么强烈的需求。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/8 18:25:50 | ||||
| 106楼： | 没感到跨行字符串有啥用，从来没用过，需要的话放到资源文件里，用stringlist加载即可 ---------------------------------------------- Great! |
|||||
| 作者： |
|
2018/11/9 10:46:25 | ||||
| 107楼： | 一间公司的策略是很关键的。 几乎所有工具的发明和发展都是为了减少成本和提高效率，软件开发工具也不例外。 在软件工程的理论下，减少成本提高效率就得提高复用率，而最能提高复用率的方法就是 平台+DSL 。 通用语言跟DSL其实是相对的，PHP相对C来说就是DSL，C就是通用编程语言。所以一旦特定领域里出现 平台+DSL，比如：开发web出现PHP，那delphi就处于劣势。随着类似的竞争者越多，delphi就得退出舞台。这就是规律。 那么delphi的主要用途在哪，个人认为就是用来搭建平台。从一开始就应该集中力量优化编译器，像FPC那样在各个硬件上都能用，开源，通过社区吸引大量开发人员去做好基础的事情；而不是搞jbuilder 全生命周期开发工具那些。object pascal编译比C++快这么多，没发展起来其实是非常非常可惜。 现在路在哪？ 个人浅薄，无法回答。感觉已无路可走，即使现在开源，优化编程语言讨好开发人员也改变不了当前的局面。EMB可以看哪个热门就做哪个，比如 现在无人机热门，EMB也可以提供技术支撑，但最后还是逃不出被淘汰的命运。而且把战线拉得太长，本身就是很愚蠢的行为。 还是那句话，做软件就是做未来，谁都知道只要钱够delphi重振雄风一统天下指日可待，但关键就是： delphi还有什么价值值得花那么多钱？！ ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/9 11:33:05 | ||||
| 108楼： | @hawke2e，理性的声音总是让人忍不住点赞！ 但是，从“劣币驱逐良币”这个角度来看，无数的劣币总是令人恶心加呕吐！仔细想一下的话，其实更多的劣币在加速着旧秩序的倒塌、灭亡！毕竟，大家会用脚投票来表述自己的心情和愿望。 从惋惜这个角度来看的话，“早si早超生”未必就不是一件好事，共勉吧。 ---------------------------------------------- Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！我去WC吐一会儿去！ |
|||||
| 作者： |
|
2018/11/9 20:52:51 | ||||
| 109楼： | 我就说那非常非常可惜的地方。 假设公司想开发一款类似PHP的开发工具，运行平台需要在C C++ 还是object pascal三者中选，又假设这三者在跨平台性、类库丰富程度以及质量、有关的技术支持等这些条件都差别不大，那公司会选哪个语言？ 傻子都会选object pascal，因为它编译速度比C++的快一数量级，C是结构化语言，在问题分析以及模块复用上都比面向对象要弱。 反过来说，为啥当初的borland不把这编译速度优势发挥到淋漓尽致： 1. 学习Eclipse，自动增量编译，敲完代码就立即可以运行（完全可行）。 2. 调试模式下，可以像动态语言那样，在运行状态下修改代码。这个就很强大了，系统可以边用边改。（不一定可行） 3. 加上方便开发DSL的支持（语法定义、调试等）。 4. 开源编译器和VCL。 这么搞下去，还有C和C++什么事？！这不是白白把天下让给别人吗？！ 现在就好比降央卓玛的经纪公司偏偏给她唱的歌都要飚高音，白白浪费她绝好的中音音色。 现在好了，机会彻底没了！！ ---------------------------------------------- 软件是什么，相信很多人都说不清。 |
|||||
| 作者： |
|
2018/11/10 9:46:28 | ||||
| 110楼： | @hawke2e，再次点赞！ 理论上讲，编译器的重要性毋庸置疑（可惜，总有夏虫看不到），同样，编译器如果都无法做出核心竞争力来，其它技术就可想而知了。对于D来说，如果连编译器这一项拳头优势都没法卖了，那其它技术还有啥意义？不恰当的例子是，编译器更像是生产钢筋水泥的工厂，只有你生产出的钢筋水泥质量更好、速度更快、效率更高，才能吸引到更多的建筑工程企业愿意用你的钢筋水泥构建高楼大厦或者超级工程！否则，你懂的。。。。。 就这样吧，长篇大论就不说了，再次为hawke2e点赞！理性的声音总是让人感动常在！ ---------------------------------------------- Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！Delphi威武！千秋万代，一统江湖！我去WC吐一会儿去！ |
|||||
| 作者： |
|
2018/11/10 17:06:57 | ||||
| 111楼： | @hawke2 第 2 点，就是现在许多动态语言的实现目标和价值所在。 Delphi 完全可以做到这点，但是却一直裹足不前。 我们做的 PWP， 已经部分做到了一些小目标，实践中确实对开发效率提升明显。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/11 8:43:00 | ||||
| 112楼： | http://www.cnpack.org/downbuilds.php?lang=zh-cn CnPack IDE 专家包最新的每日构建版949的代码格式化专家里已经支持了Inline var/const，欢迎下载试用，有什么问题都可以反馈给我们。 ---------------------------------------------- 欢迎使用CnPack IDE Wizards http://www.cnpack.org/ |
|||||
| 作者： |
|
2018/11/12 15:38:50 | ||||
| 113楼： | cnpack 厉害！！！ ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/22 0:52:54 | ||||
| 114楼： | 吵什么呢，你们都这么厉害了，怎么不写一个IDE呢，比如cnpack那么牛B。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/22 9:55:56 | ||||
| 115楼： | cnpack 不用不习惯型 ---------------------------------------------- 还可以更好 |
|||||
| 作者： |
|
2018/11/22 13:30:14 | ||||
| 116楼： | 都能侃！ 支持Delphi 10.3！ 支持Delphi 10.3！ ---------------------------------------------- 学Delphi来Delphi 学习大师 海量视频教学课程 http://www.XueXiDaShi.Vip |
|||||
| 作者： |
|
2018/11/22 13:30:39 | ||||
| 117楼： | 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ 支持Delphi 10.3！ ---------------------------------------------- 学Delphi来Delphi 学习大师 海量视频教学课程 http://www.XueXiDaShi.Vip |
|||||
| 作者： |
|
2018/11/22 13:38:11 | ||||
| 116楼： | CnPack IDE 专家包只是依附于 Delphi IDE的一套工具，技术上并没有 IDE 或编译器那么牛，大家谬赞了。 ---------------------------------------------- 欢迎使用CnPack IDE Wizards http://www.cnpack.org/ |
|||||
| 作者： |
|
2018/11/23 9:15:22 | ||||
| 118楼： | 若大的中国，却没有人会写个IDE...哎... ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/23 9:58:57 | ||||
| 119楼： | IDE好写，编译器不好写 ---------------------------------------------- 虽千万人吾往矣！ |
|||||
| 作者： |
|
2018/11/23 10:18:09 | ||||
| 120楼： | 那就先调用DELPHI编译器好了 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/23 10:18:33 | ||||
| 121楼： | 然后再慢慢写自己编译器 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/26 14:08:45 | ||||
| 122楼： | Borland C++ Compiler 5.5 编译器免费开源 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/26 18:22:21 | ||||
| 123楼： | 其实C++Builder的编译器一直都是BorlandC++ 5.X。这么多年都没改进。 估计人都走光了，也没人维护。所以BCB WIN64部分是LLVM重写的，支持C++11到17的各种新语法。而BCB WIN32的编译器一直没换，所以只能支持老的C++语法。这次10.3不知道老掉牙的Borland C++ WIN32换掉没有。 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2018/11/26 18:52:33 | ||||
| 124楼： | Borland C++ Compiler 5.5 编译器免费开源 CnPack可以在这人基础上研究一下自己的IDE，CnPack应该有这个实力，不要整天写什么附助. ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/26 19:12:17 | ||||
| 125楼： | to 武稀松： 在C++Builder 10.3中，新建工程后32位编译器也缺省是LLVM的了。当然仍提供了使用老编译器的“classic”选项。 另外这几年32位老编译器也在一些细节上有改进，例如提高与较新版本的Boost库的兼容性等等，当然因为人力，C++近年许多新增加的语法仍不支持。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/26 19:15:03 | ||||
| 126楼： | 用了下10.3 1、找半天 managed records ，没找到相关资料，在看了Marco Tech Blog才知道推迟了 Deferring Delphi Managed Records Support Due to some standing issues, we decided to disable the managed records Delphi language feature in the coming 10.3 release and postpone it to 10.4 2、另外inline var 的IDE上Error insight也没做好，都红色波浪线 3、不习惯RAD的Theme，关闭RAD的Theme,在Win7上启动RAD,工具条位置每次启动都乱了，根本不靠左，要把win7设置经典方式才显示正确 4、在win7下，每次打开工程，都会丢几十个GDI 5、按RAD默认的android的sdk、ndk版本，配好路径，编译一个空窗口的Android程序，要16秒，换回上一版本的RAD所配的SDK、ndk目录，编译只要7秒，估计sdk或ndk又做大了 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/11/26 20:11:33 | ||||
| 127楼： | 期望的三个新功能:inline var、managed records、去掉Arc，看来要等等 ---------------------------------------------- - |
|||||
| 信息 |
| 登陆以后才能回复 |
