| 技术论坛 |
|
|
| ≡技术区≡ ① |
| DELPHI技术 |
| lazarus/fpc/Free Pascal |
| 移动应用开发 |
| Web应用开发 |
| 数据库专区 |
| 报表专区 |
| 网络通讯 |
| 开源项目 |
| 论坛精华贴 |
| ≡发布区≡ ② |
| 发布代码 |
| 发布控件 |
| 文档资料 |
| 经典工具 |
| ≡事务区≡ ③ |
| 网站意见 |
| 盒子之家 |
| 招聘应聘 |
| 信息交换 |
| 论坛信息 |
|||
|
| 导航： | 论坛 -> DELPHI技术 斑竹:liumazi,sephil | |||||
| 作者： |
|
2016/10/21 14:35:35 | ||||
| 标题： |
|
加入我的收藏 | ||||
| 楼主： | Sync status from internal system, internal issue closed on Oct 11, 2016 by Marco Cantù with comment: No plan to remove ARC for mobile, as discussed a few times. We plan to add ARC on desktop, instead. ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/21 15:00:46 | ||||
| 1楼： | 对ARC on Desktop, 持中立态度，我都不知道有没有成功案例，更不要说delphi的桌面版主要是存量系统了。 ---------------------------------------------- UniKeeper V10.40 -- 您最贴心的个人数据管理助手 |
|||||
| 作者： |
|
2016/10/21 15:20:07 | ||||
| 2楼： | 我高兴的是，很多人可以不必纠结了，可以安心的放弃并解脱了 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/21 15:22:52 | ||||
| 3楼： | 我很高兴的是，终于可以跟进了，欢呼吧 ---------------------------------------------- 他们总是取笑失败者，以酷似智者；他们也总是为成功者喝采，以取得赏金。 |
|||||
| 作者： |
|
2016/10/21 16:22:33 | ||||
| 4楼： | 祝你好运，但愿贵公司的项目也能跟得上 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/21 17:38:23 | ||||
| 5楼： | 我公司的产品说不定又要伤筋动骨，尽管现在代码都不是Free而是Dispose，但是谁知道到时候会发生什么。 我倒是希望Lib中的DCU能有两份，一份是开了ARC的一份是关掉ARC的。编译选项可以选 如果有可能再分成带RTTI和不带RTTI的 因为有时候情况比较复杂，我需要手动掌握释放，有时候需要极小的可执行文件。 而现在的情况是尽管代码中有ARC和RTTI的开关，但是我们自己很难编译自带的RTL，Delphi把这块做僵了。 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2016/10/21 17:43:06 | ||||
| 6楼： | 反对 ARC ， 问题是EMB 根本无法保证他的 ARC 是安全的。 bug 多多。 同意武大侠的意见，应该保留一些编译选项给开发者选择。 看来 EMB 是全面倒向 LLVM , 放弃自己的编译器了。 多了个理由坚守 Delphi7 ， 然后转向 FPC ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/21 18:41:17 | ||||
| 7楼： | 我 移动 上写的代码 我都当 ARC 不存在，效果也很好。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2016/10/21 21:23:10 | ||||
| 8楼： | 毫无意义的事情 ---------------------------------------------- Great! |
|||||
| 作者： |
|
2016/10/21 22:17:34 | ||||
| 9楼： | 产品是人家的，由他们折腾去吧。就算现在形成决议，也不会立马添加到下一个版本中，总有个时间差的。用Delphi基本都是老人了。最后一个版本用十年总可以的，到时候大家都退休了，还操心个屁。我看桌面引入ARC就如同XP->VISTA，会有一段时间折腾的，不鸟他就好了。再说，咱职业生涯也没那么长，到时候自然不需要操心了。 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/21 22:53:21 | ||||
| 10楼： | @r960204 (武稀松) RTTI其实很好处理，编译时将RTTI生成到一个与．dcu同名的．rtti文件中，根据需要进行链接。实现简单，灵活度又高 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/21 23:23:20 | ||||
| 11楼： | 不明觉厉~ ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/22 8:39:51 | ||||
| 12楼： | 这个计划要多久？ ---------------------------------------------- -我的博客 |
|||||
| 作者： |
|
2016/10/22 13:43:47 | ||||
| 13楼： | 弱弱的问一句。。ARC 是什么？ ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/22 15:49:30 | ||||
| 14楼： | ARC是iOS 5推出的新功能，全称叫 ARC(Automatic Reference Counting)。简单地说，就是代码中自动加入了retain/release，原先需要手动添加的用来处理内存管理的引用计数的代码可以自动地由编译器完成了。 该机能在 iOS 5/ Mac OS X 10.7 开始导入，利用 Xcode4.2 可以使用该机能。简单地理解ARC，就是通过指定的语法，让编译器(LLVM 3.0)在编译代码时，自动生成实例的引用计数管理部分代码。有一点，ARC并不是GC，它只是一种代码静态分析（Static Analyzer）工具。 ---------------------------------------------- -我的博客 |
|||||
| 作者： |
|
2016/10/22 20:48:36 | ||||
| 15楼： | 多谢楼上耐心解答~ 这么看来，ARC 不是与 delphi 的 interface 比较类似么？ ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/22 22:45:57 | ||||
| 16楼： | 我看了也不懂ARC是啥，赶紧百度了解一把，理解为原来就是编译器智能分析你的上下文，帮你抽定内存管理，就像写java一样不用管释放不用怕有泄漏，又保持手动内存管理的高效，不像Java那么慢，不知对了否。 ---------------------------------------------- 心无挂碍，无有恐怖，远离颠倒梦想，究竟涅槃。 |
|||||
| 作者： |
|
2016/10/23 9:13:09 | ||||
| 17楼： | 事情发生了变化： @Marco make it clear later: "there is no plan to remove non-ARC compiler from Win32 and VCL applications. We are considering adding an ARC option in case you want full memory management compatibility among platform." 在我看来，这个似乎是个好消息，但愿不要使用让人蛋疼的方式来实现。 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/23 20:03:29 | ||||
| 18楼： | @zwjchinazwj (蒲石) 他们给选项，这是个好消息，给用户自由选择的权利 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2016/10/24 10:14:15 | ||||
| 19楼： | @wr960204 (武稀松) 我担心他们的具体实现方式。说实话，如果仅是质量问题(BUG多），这种问题相对好解决，如果是产品设计问题，麻烦就大了。 我认为他们在产品设计方面比技术更让人担心。 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/24 10:18:59 | ||||
| 20楼： | 但愿 Nick Hodges 的回归能改变点什么，但Nick Hodges以前就是搞C# Builder的。 受C#影响颇深，就一些评论来看Nick Hodges 是希望移除指针的。我推测，完整RTTI 的出现以及Attribute的出现应该主要就是他发挥的作用。 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/24 13:07:31 | ||||
| 21楼： | 没指针的编译语言我是不用的,若是移除指针 我就转fp了和C#了 ---------------------------------------------- http://blog.sina.com.cn/bmsrnote |
|||||
| 作者： |
|
2016/10/24 13:19:20 | ||||
| 21楼： | @zwjchinazwj (蒲石) 对于原生代码来说，移除指针在实际工程中应该是会导致很多问题的。 对于ARC，其实我觉得这个事儿有点不上不下。ARC在设计模式上引入的问题在于，有时候你真的很难预先确定一个引用到底应该是Strong还是Weak，尤其是涉及到Delegation的时候。另一个麻烦的典型场景是在多个线程并发操作同一个引用的时候，尤其是ARM这种平台原子操作不是以指令LOCK前缀实现，而是使用LDREX/STREX指令对方式的情况，微观时序完全无法预计。至少无ARC方案，或者GC方案，本身不至于有多大硬伤…… ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/24 16:20:21 | ||||
| 22楼： | to zwjchinazwj (蒲石) 之前有个朋友也是Delphi老人，他说这最近这些版本守java影响较大。 我个人觉得也是，越来越像java，但是学的又不彻底，因为有语法和历史包袱。 还不如Delphi的架构还是走原生，内存程序猿管理，跟C++一个路子，但是可以跨平台做快速开发 另起炉灶搞个新的语言，完全没有包袱，平台开发+ARC 跟objectiveC一个路子，但是又不仅仅限于苹果平台，可以跨WIN，MAC，IOS，ANDROID，LINUX等平台。 Radstudio里面集成Delphi，CB，以及新语言开发工具。 类似安德尔斯几次成功的做法，TurboPascal，Delphi，VJ++，C#，TypeScript开始还受历史限制，但是加入自己的特性，后面就完全是自己重头来，越往后越自由。才能扔掉包袱快跑 ---------------------------------------------- 武稀松http://www.raysoftware.cn |
|||||
| 作者： |
|
2016/10/24 17:18:21 | ||||
| 23楼： | arc类似接口使用引用计数器,这个在以前搞OC时体验挺糟糕的,而且绝对不会像java那么智能... ---------------------------------------------- |
|||||
| 作者： |
|
2016/10/24 17:41:35 | ||||
| 23楼： | @scarlette 对于移除指针，我是持反对意见。对于ARC，我同样持保守态度－可以有，但是是程序员可以自行选择部分使用ARC. ARC有无可辩驳的执行效率损失，执行效率本该是 原生语言的一大优势，全盘的ARC无疑是砍掉自己的优势去与虚拟机语言竞争。 不过，无论是指针还是ARC，这个问题需要衍生到Delphi的定位。如果朝着动态语言方向发展，学习C#,Java，去掉指针是合情合理的。然而，Delphi毕竟不是C# Java，Delphi也没有虚拟机，其招牌就是原生。 所以，问题的关键是，易博龙到底把谁当作主要对手，目前来看是Java C#，而不是 C++ Go等，这是个让人非常遗憾的问题。 @wr960204 (武稀松) 很同意你的观点，感觉易博龙有帮子人，其实就是想搞一个类似C# Java的东西。Delphi成为了此人可怜的测试工具。Mobile上的 Unicode(无Ansi，无Utf8)，ARC(只能使用ARC)这些都毫无疑问的表明，此人根本不属于Delphi阵营。其想法很可能是想通过Mobile平台，反过来影响Windows平台的用户，使用户慢慢的不得不接受这样的变化。现在，他们说在Windows平台加入ARC（选项），在我看来，也极有可能是 实现这种转变的一环。因为在mobile平台，仍然是ARC only. 因此，要想些windows和mobile下都可以用的代码，就必须ARC。此人仍然没有放弃继续推行他的ARC的世界。 ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/24 22:51:38 | ||||
| 24楼： | 凡是有指针的语言都喜欢. 如果delphi去掉指针,那就真的是自废武功.windows下的原生开发,正是有了指针才强大无比. 总之反对去掉指针... ---------------------------------------------- - |
|||||
| 作者： |
|
2016/10/25 8:32:57 | ||||
| 25楼： | 听风就是雨，加 ARC 就不要指针？狗屁逻辑。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/15 1:25:43 | ||||
| 26楼： | top casino games and free no alluvium bonus offers, free casino bonus ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/15 15:29:10 | ||||
| 27楼： | 还以为是垃圾回收机制。 仔细看才发现，居然是编译器上的功夫。牛逼。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/15 15:49:11 | ||||
| 28楼： | 不存在了，最新的消息是取消ARC了。 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/15 15:51:05 | ||||
| 29楼： | 我希望 1 移动上 string 从 1 开始。不要从 0 开始 2 移动上 取消 ARC。 这样 github 上 大量的代码不用修改，就能直接用到移动上。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/16 1:03:33 | ||||
| 30楼： | 仔细看看现在是哪个年代了，这贴子还挖出来 ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/16 9:35:47 | ||||
| 1楼： | 半死不死了，吊着。 ---------------------------------------------- delphi 是兴趣，和工作无关，即使它倒闭。又不靠它 delphi 吃饭，怕甚？ |
|||||
| 作者： |
|
2018/10/16 10:47:48 | ||||
| 31楼： | 我个人觉得有ARC很好，特别是写服务程序的时候，这样能尽可能的保证内存长时间稳定，可以很大程度上提升开发效率；否则由于哪怕一个小BUG都会导致程序在长时间运行过程中出现内存增长； ---------------------------------------------- - |
|||||
| 作者： |
|
2018/10/16 11:51:48 | ||||
| 32楼： | 长期以来，我们一直认为ARC内存管理是对传统Delphi模型的改进，因为它删除并简化了一些内存管理。然而，我们在构建和维护大型库时以及通过与客户在复杂代码库上交谈，已经了解到，虽然ARC在纸上和局部变量以及更简单的场景中看起来很棒，但是对于复杂场景，它常常会造成很多麻烦。此外，T组件所有权模型与ARC不一致，使ARC启用现有组件库变得复杂。 我们有许多要求使ARC是可选的，但是启用ARC的对象将不容易与非启用ARC的对象共存，并且我们需要用于两种类型的对象的容器，并使得无法将它们混合。这将是一个极其复杂的场景。 我们仍然认为引用计数的内存管理是相关的，但是与其为它引入新的机制，我们更喜欢利用和增强Delphi中接口使用的现有引用计数模型。这种情况已经持续很长时间了。对同一对象的接口引用和对象引用会引起麻烦，但是这是许多Delphi开发人员已经知道如何处理的问题，并且有很多关于它的文档。 接口引用最近已经用弱引用和甚至不安全的引用扩展了。这些额外的选项大大增加了“面向接口的ARC”的灵活性和灵活性。换句话说，尽管我们要删除对象引用的ARC，但是接口引用的ARC是已经存在并将继续可用的语言的一个特性。 除此之外，我们希望改进和简化具有堆栈引用的本地短期对象的生存期（和内存管理）管理。这是我们在10.3不可能介绍的一个特性，但我们正在积极调查。 作为积极的影响，也是禁用ARC的原因之一，我们预期Linux for 10.3和FireMonkey for mobile在将来会有性能改进。 尽管我们理解几年前对计划的这种改变可能带来惊喜并影响现有代码，但是对ARC模型不满意的开发人员，支持不同平台上的多个模型，以及与本机内存管理相比性能损失，将会感激不尽。吃了这个决定 RAD Studio的路线图中提供了进一步简化Delphi内存管理的替代方法，但是当前的特性集（具有引用计数的接口以及对弱和不安全引用的支持、组件所有权模型和标准通用实践）已经提供了一些尝试OD框架减少了Delphi开发人员对手动内存管理的担心。 Copyright © 2018 Embarcadero Technologies, Inc. | Embarcadero Confidential/NDA ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/16 11:53:35 | ||||
| 33楼： | 简单的说。 ARC 支持 VCL 太难了。他们肯定不会让 VCL 支持。 另外 桌面部分，肯定不打算支持。 移动未来 可能会 取消支持。 ---------------------------------------------- (C)(P)Flying Wang |
|||||
| 作者： |
|
2018/10/16 13:58:07 | ||||
| 34楼： | 你们难道就没发现，是26楼挖的坟，而且打的无关紧要的广告，什么赌场 ---------------------------------------------- 就怕想不到，没有做不到的 |
|||||
| 作者： |
|
2018/10/18 11:32:54 | ||||
| 35楼： | 为什么JS就能做到内存管理不用太在意，而delphi却会这么难实现？，而且现在typescript增加了静态类型的特性后，越来越多的架构都采用ts来写了，反而delphi在服务端的开发却不多，还一直以桌面程序为傲，但往后我估计桌面程序也会慢慢的采用web的技术方案， ---------------------------------------------- - |
|||||
| 信息 |
| 登陆以后才能回复 |
