| 技术论坛 |
|
|
| ≡技术区≡ ① |
| DELPHI技术 |
| lazarus/fpc/Free Pascal |
| 移动应用开发 |
| Web应用开发 |
| 数据库专区 |
| 报表专区 |
| 网络通讯 |
| 开源项目 |
| 论坛精华贴 |
| ≡发布区≡ ② |
| 发布代码 |
| 发布控件 |
| 文档资料 |
| 经典工具 |
| ≡事务区≡ ③ |
| 网站意见 |
| 盒子之家 |
| 招聘应聘 |
| 信息交换 |
| 论坛信息 |
|||
|
| 导航： | 论坛 -> DELPHI技术 斑竹:liumazi,sephil | |||||
| 作者： |
|
2024/4/8 16:23:10 | ||||
| 标题： |
|
加入我的收藏 | ||||
| 楼主： | 不错不错，虽然Delphi用的人不太多，但她一直在更新，她努力追赶曾经的竞争对手，跨平台开发渐入佳境，希望Delphi今年能重回前10！
- |
|||||
| 作者： |
|
2024/4/8 16:26:52 | ||||
| 1楼： | 顶多只能第十名，我看了看除了fortran外，不太可能超过前面任何一位了。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/8 16:38:26 | ||||
| 2楼： | d12.1用起来很稳定,整数的计算除法、取模速度已经很快了,我觉得是这么多年来最好的一个版本，但字符串方面还是慢，如果有能人优化一下字符串速度那更好，再也就是编译安卓文件还是太大，有很大优化空间,一个空的app几十兆，我想emb他们有心去优化，十分之一的空间都不要。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/8 16:52:58 | ||||
| 3楼： | 在这个位置很不错了，除非在web和AI方面能有所突破，否则进前10很难了 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/8 17:35:26 | ||||
| 4楼： | 楼上正解。特别是在WEB方面，一直是短板。 要是能够出个类似JS的原生支持，那就牛逼了。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/8 20:06:00 | ||||
| 5楼： | 可喜，做桌面开发，Delphi无出其右。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/8 22:48:02 | ||||
| 6楼： | 这么多年，WEB基本原地。WEB要是有进步，还有上升的空间。 ---------------------------------------------- 山外青山楼外楼,能人背后有能人弄.. |
|||||
| 作者： |
|
2024/4/9 14:13:03 | ||||
| 7楼： | 在WEB方面上不加强，很难进前十。 这么多年了WEB开发上一点没长进，被别的语言都超过了，唉！ ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/9 14:25:44 | ||||
| 8楼： | 每出新版，估计为了找Keygen和下载ISO以及各种寻找控件的活动，就会拉升到10/11，然后逐渐下滑到20左右。 TIOBE排名，也就是个互联网关键词搜索频度排名。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/9 16:48:53 | ||||
| 9楼： | 桌面跨平台还是差劲，只能做linux for x86/Mac Os。移动倒是通杀了，andorid/ios。 lazarus是真正的跨平台，任从原理上说，任何指令集都可以适配fpc，这似乎是一个更有前途的语言。 现在的先进语言都把跨平台放在非常重要的位置，delphi理应要重视，否则没有大的突破。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/9 18:19:42 | ||||
| 10楼： | 这比较我不相信 Fortran 比 Delphi 多人用? 奇 SQL 都当 script, 单用 SQL 写不出应用程序. Visual Basic 停产多年, 祇在维护的人在用. Java 因安全问题, 外国用的人已大幅减少, 美国政府内禁用. 现在又增大收费范围. 而且运行效率又差. 站在商业软件市场的份额, C++ 才是王道. 其次就是 C#, Delphi. 可以选择的其实不多. ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/9 18:32:56 | ||||
| 11楼： | 大家没发觉 C++ Builder 近年很多人在询问吗? 它拥有世上最强的程式库 C++ 的可吸纳性, 也拥有 Delphi 在软件包开发能力的优势. 这东西不能忽视. 就差在看开发商的作为. ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/10 1:33:00 | ||||
| 12楼： | 别指望了。。。 能搞好windows开发 就烧香拜佛吧。 老指望 农妇能做出满汉全席 只会越来越失望 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/10 12:29:17 | ||||
| 13楼： | 楼上思想落后了。 delphi fmx完全具备跨平台的功能，只是emb不想这样做。 很早fmx就支持android for armv8的开发了，既然移动可以支持，桌面应该也没什么难度，只是emb不想开发linux for arm/risc-v/loongarch。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/11 1:06:12 | ||||
| 14楼： | @sxqwhxq FMX出来几年了？到现在都只能说堪堪能用而已。各种BUG满天飞 没这个精钢钻 接不下这个瓷器活 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/27 23:43:33 | ||||
| 15楼： | 放弃幻想吧，一个没有主流公司用的语言，一个没有新工作岗位的语言，一个没有新用户学的语言，能有什么前途？曾经Windows桌面开发的辉煌已经过去，醒醒吧，各位！哪天失业还想写代码的，趁早再学一两门新语言，有能力转行的，早点转行，IT行业，是一个极度内卷且螺旋下降的行业，人到中年，得承认，我们不是入错了行，是选错了职业！ ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 6:13:07 | ||||
| 16楼： | 楼上，没有创意和毅力去实现，肯定是赚不到钱的。 ---------------------------------------------- 只有偏执狂才能生存！ |
|||||
| 作者： |
|
2024/4/28 7:28:03 | ||||
| 17楼： | 和排名没啥关系，重要的是要干啥，delphi 现在基本能实现所有你想实现的功能，关键你能力能否达到，比如那些看衰的人，是因为他们不会用，就觉得实现不了。 要是能力强，你拿汇编实现各种功能都行。 还有就是python ，是因为有一堆人在维护各种库才让人觉得无所不能，可这玩意当初就是个脚本工具而已。 普通玩玩的话，玩什么语言都行，关键是自己要实现的能不能实现 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 10:29:50 | ||||
| 18楼： | 1、首先，你有创意和毅力，不一定能成功，创业失败才是常态，年轻时无所谓，人到中年，你不得吃饭？不得养家？你现在试着去找一个工作看，别的地方不清楚，Delphi的岗位在北京基本绝迹了。 2、Delphi是什么都能实现，往前倒推，C++、C、汇编都可以实现，这不是我们继续使用Dephi的理由。无论是代码执行效率、开发效率、社区生态Delphi都不再是一个值得继续投资的语言。GoLang、Rust、TypeScript甚至Java，Python、QT，每种语言都有其优劣势，相信大家都是熟练工了，换个语言比你造轮子，更有性价比。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 10:59:21 | ||||
| 19楼： | Delphi成也RAD，败也RAD，控件拖拽太好用了，导致我们这个社群里很多兄弟连基本的内存分配释放、指针这些基本功都用不好，群体性技术水平偏低，大大限制了Delphi生态的发展，其它语言基本都是开源的，Delphi的专利版权问题，也同样导致了，这个语言没有未来 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 11:41:28 | ||||
| 20楼： | 版权问题，可以用开源的Lazarus，支持各种平台甚至龙芯电脑。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 12:01:20 | ||||
| 21楼： | 别扯那些有的没的，没有Lazarus工作岗位，吃什么喝什么？用爱发电？ ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 18:46:52 | ||||
| 22楼： | 不敢苟同19楼，当你被业务逻辑忙得晕头转向时，就知道拖拉组件多么重要了。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/28 21:59:08 | ||||
| 23楼： | 有很多专业技术人员，有一定编程基础，工作需要搞点业务软件，RAD的优势就很明显了。编程不等于quan职软件开发。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/29 10:55:56 | ||||
| 24楼： | 我觉得emb如果能修复各种bug，同时加速推出社区版的话，排第8应该可以，超过sql和vb问题不大，但是前面7个有难度 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/29 19:33:21 | ||||
| 25楼： | 虽然不是靠编程和Delphi吃饭，但希望Delphi挺进前10，最好重现昔日辉煌！ ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/29 19:35:25 | ||||
| 26楼： | @hq200306：以前字符串性能不是Delphi津津乐道的优势吗，如今已经成了拖后腿的劣势了？ ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/29 21:15:20 | ||||
| 27楼： | string肯定慢，就算单线程都比go，c等都慢，string多线程更慢。pchar稍微好一点 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/30 10:26:30 | ||||
| 28楼： | 我不记得delphi的string有过啥优势,反而还是api创建多线程的瓶颈。我记得delphi和c#的string效率都不高，为了性能都推荐stringbuilder。 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/4/30 17:18:07 | ||||
| 29楼： | 那可能是我这个大菜鸟没搞清楚了，记得以前看资料说字符串性能是Delphi的优势之一 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/5/3 23:04:14 | ||||
| 30楼： | 我记得Pascal字符串有记录长度，C语言字符串求长度就很慢，字符一个一个数到结尾'\0'字符，strlen、strcpy、strcat等字符串函数都受此影响 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/5/4 21:02:09 | ||||
| 31楼： | 内置 string 类型确实是 delphi 相对于 c 或者 c++ 的优势，它的相关处理代码都是人工优化的二进制代码。只是有一个问题，多线程情况下比较复杂，预置的优化代码是一定会做互斥的，而有时候可能某些string资源不会被跨线程访问，所以这部分性能就被白白浪费了，建议遇到此种情况，就不要使用内置字符串了，直接使用字节数组吧 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/5/5 10:46:56 | ||||
| 32楼： | 内置string要实现copy on write，在多线程环境必然需要加锁，只要不是对性能有极致的追求，相对于带来的方便，牺牲这点性能其实完全可以接受 ---------------------------------------------- - |
|||||
| 作者： |
|
2024/5/5 20:47:20 | ||||
| 33楼： | 1、delphi 内置 string 在设计上很好的平衡了性能与便利，记得某位微软 mvp 说过，同时代 excel 为了提升性能就是采用类似 delphi string 的方案；c++ 智能指针也这个思路 2、多线程除非 Immutable 否则还要 COW 还有比 RTL 的 InterlockedIncrement 原子操作更轻量的实现？ 3、在 delphi 中完全 pchar 按 c 的玩法没问题，性能肯定也没得说；但区分各种堆/栈操作，各种 strcat/strcomp，除非提升核心价值/解决性能瓶颈。这种牺牲语言便利性、增加心智、影响 curd 赚钱，除了装 13 实在不知道还有啥用 多说一个，“为了性能都推荐 stringbuilder”不武断，注意上下文，如“频繁拼接大量字符串”；这可不是 delphi 或 c# 特有的，其他 java、go 甚至 c/c++ 新手，不注意内存预分配都会掉沟了；譬如 go 这种 Immutable 的拼接会分配新字符串，又会导致大量内存分配和 GC 压力 ~ ---------------------------------------------- - |
|||||
| 作者： |
|
2024/5/5 21:47:37 | ||||
| 34楼： | S := S1 + S2 这种操作，需要重新分配内存嘛。这个不怪字符串。怪程序员不理解字符串。 至于多线程，加锁，不用字符串，搞其它的就不用加锁了？只要是个变量，在多线程里面，如果需要加锁，它都跑不脱加锁的命运。 ---------------------------------------------- - |
|||||
| 信息 |
| 登陆以后才能回复 |
