DELPHI盒子
!实时搜索: 盒子论坛 | 注册用户 | 修改信息 | 退出
检举帖 | 全文检索 | 关闭广告 | 捐赠
技术论坛
 用户名
 密  码
自动登陆(30天有效)
忘了密码
≡技术区≡
DELPHI技术
lazarus/fpc/Free Pascal
移动应用开发
Web应用开发
数据库专区
报表专区
网络通讯
开源项目
论坛精华贴
≡发布区≡
发布代码
发布控件
文档资料
经典工具
≡事务区≡
网站意见
盒子之家
招聘应聘
信息交换
论坛信息
最新加入: wjy13061029975
今日帖子: 1
在线用户: 6
导航: 论坛 -> 文档资料 斑竹:liumazi,ruralboy  
作者:
男 zhyhero (zhyhero) ★☆☆☆☆ -
盒子活跃会员
2022/8/16 20:56:56
标题:
Delphi-PRAXiS上一个关于字符串类型的讨论,挺有意思 浏览:1351
加入我的收藏
楼主: https://en.delphipraxis.net/topic/5591-why-shortstring-in-delphi-cannot-used-in-our-programs-using-new-ide/

节选1
Arnaud Bouchez     291      Posted September 22, 2021

ShortString have a big advantage: they can be allocated on the stack. So they are perfect for small ASCII text, e.g. numbers to text conversion, or when logging information in plain English.
Using str() over a shortstring is for instance faster than using IntToString() and a temporary string (or AnsiString) on a multi-thread program, because the heap is not involved.

Of course, we could use a static array of AnsiChar, but ShortString have an advantage because they have their length encoded so they are safer and faster than #0 terminated strings.

So on mobile platform, we could end up by creating a new record type, re-inventing the wheel whereas the ShortString type is in fact still supported and generated by the compiler, and even used by the RTL at its lowest system level.

ShortString have been deprecated... and hidden. They could even be restored/unhidden by some tricks like https://www.idefixpack.de/blog/2016/05/system-bytestrings-for-10-1-berlin

Why? Because some people at Embarcadero thought it was confusing, and that the language should be "cleaned up" - I translate by "more C# / Java like", with a single string type.

This was the very same reason they did hide RawByteString and AnsiString...
More a marketing strategy than a technical decision IMHO.

I prefer the FPC more "conservative" way of preserving backward compatibility.
It is worth noting that the FPC compiler source code itself uses a lot of shortstring internally, so it would never be deprecated on FPC for sure. 😉

Edited September 22, 2021 by Arnaud Bouchez





节选二

Dalija Prasnikar     971       Posted September 23, 2021

I don't remember anyone complaining :classic_biggrin:

The though process was a bit different. Mobile compilers were supposed to attract new generation of developers. To do that it needed to have some competing features. One was automatic memory management (hence ARC), another one was streamlining string and array indexing - hence zero-based strings. Short strings store length at index zero, so they were completely incompatible with that goal. AnsiStrings with ANSI encoding are not something that exists on mobile platforms, so they were deemed as unnecessary, too.  So 8-bit strings were removed.

 

Unfortunately, what they didn't take into account is impact on existing codebases. The same ones that were supposed to run on all other platforms (yes, you couldn't reuse GUI), but there is not reason to throw away non-GUI code. 

 

Zero based strings wreak havoc in string handling, causing subtle bugs all over the place. Most people after they learned about it would just turn the damn thing off. Removing all other 8-bit strings was also a mistake, because 8-bit strings make a whole a lot of sense in cross-platform, especially on Linux where UTF-8 encoding rules. So while throwing out AnsiString as such made sense, the rest did not. This is also why 8-bit strings were reintroduced, even before ARC was removed - which happened for completely different and unrelated reasons.  

 

And the last, but not the least. TBytes are completely different beast from strings. It is not that just that handling functions were missing. TBytes don't have COW, and also debugger support is extremely limited and you cannot easily inspect textual data stored within.

 

And we all know how many new customers they attracted to Delphi because it was suddenly cross-platform.


----------------------------------------------
z@S7
作者:
男 pcplayer (pcplayer) ★☆☆☆☆ -
普通会员
2022/8/16 22:16:45
1楼: 简单说,垃圾回收这种玩意就是为了给不适合干这个职业的人准备的。

当然,不适合干这个职业的人数更多。因此有了垃圾回收,市场才更大。
----------------------------------------------
-
作者:
男 ddrfan (若苗瞬) ▲▲▲▲▲ -
普通会员
2022/8/16 23:17:59
2楼: 呃,String,包括AnsiString,一直都不需要我们自己申请释放。
加减赋值也不需要我们计算长度,也不用人管它重新分配空间没。

所以楼主发的这个我觉得不是垃圾回收的事儿。

感觉一门语言不能哪方面都想沾一点,还是保持自己的最初的特点和优点更好。
----------------------------------------------
Bye bye DDRFAN...
作者:
男 emailx45 (emailx45) ▲▲▲▲△ -
普通会员
2022/8/17 3:30:07
3楼: I think the big problem, in Object Pascal in particular, is the amount of subtypes for a particular type: strings!

Like many other factors in the computer, I think it started with the goddamn inheritance of MSWindows, and by consequence the language that created it: "C"

And, over time, the OP was adapted to calm the animalistic principles of skeptical programmers and their criteria of "evolution".

Thus, with the appearance of new platforms, it became clear that the technological "mess" would, one day, show true chaos.

This is clear in many other scenarios, for example, today we have in Fireibird new types for numerical values, because, due to the exponential growth of values, it was necessary to make use of subterfuges to represent such large values....

But don't be sad, because the sadness could be even greater as 128bit computing or higher arrives....
----------------------------------------------
The higher the degree, the greater the respect given to the humblest!RAD 11.3
作者:
男 stacker (OOP才是王道) ★☆☆☆☆ -
普通会员
2022/8/18 3:57:05
4楼: 垃圾回收搞到安卓13还在搞,证明根本就是垃圾一个,怎么不直接回收这个垃圾?
----------------------------------------------
-
作者:
男 hs_kill (lzl_17948876) ★☆☆☆☆ -
普通会员
2022/8/18 8:43:13
5楼: 都是编码惹的祸
其实我觉得在一般开发情况下没必要纠结字符串类型
大致可以认为字符串类型, 一种是开发用的(string/unicodestring), 一种是显示或对外输出用的(ansi/utf8/utf16...)

内部开发用unicode对内容进行各种处理, 需要对外输出时在转码到外部需要的编码字节流

如果是特殊处理, 比如大文本的分步加载, 这时再用对应编码的类型做处理, 这种应用一般不多(相对业务开发)
----------------------------------------------
http://www.cnblogs.com/lzl_17948876/
信息
登陆以后才能回复
Copyright © 2CCC.Com 盒子论坛 v3.0.1 版权所有 页面执行87.89063毫秒 RSS