关于指针问题的一个笔记加牢骚
“指针是不好的”这一观点被重复过很多次,可惜这种看法有根本性错误。指针本身就是一种抽象、是某种知识的一种表现形式,其存在必要性没有任何疑问:如果没有指针类似物,如何精确的操作内存?
如果是一种等价的替代品,必然伴随着人们认为的指针的一切缺点。如果是一种受限的替代品,如引用,必然就导致一些任务无法完成。
如果问大多数人如何解决,不外乎陈词滥调的多语言编程,什么地方使用什么语言,这全都没有切中要害:那些在底层编程的人,就应该更加兢兢业业的处理本来没有必要关注的问题?
指针的真正的缺陷是,这种抽象本身未能携带一些使用上的必要信息、以及依赖于这些信息的必要机制和策略。引用计数就是增加信息和自动处理的一种尝试,但它存在效率问题;GC是运行时刻收集信息并自动处理,仍然存在效率问题(比如LAG)。
让一些人说,这又成了不得不付出的代价和取舍了,不幸的是,这又不过是另一条陈词滥调。就这个问题深入的话,这里存在一个陈述:一个内存只要申请了,它就必须被释放。
在技术上其难点在于,释放点未必紧跟着申请点,中间还隔着若干个使用点。
首先是模块内部的传递,这里面有两个难点:一个是只有运行时刻才确定的申请、一个是分支造成的不确定性。其次,指针可以被传递到模块外部去,这就更缥缈了。再次,考虑到不同线程的生存周期,显然不能简单的按传递流程决定何时释放。
(欢迎补充)
但这些问题真的不能解决吗?这是有待人们考虑的。我非常反感的是,很多有影响力的人他们并没有真正尝试过、得到确定的结果,就向新人灌输各种各样的观点,让程序员带有各种各样先入为主的观念。
就指针的这个问题来说,大部分内存申请,都有比引用计数和GC更稳妥的方式处理。我们都看到值类型参数所占用的内存会在函数返回时被归还到栈上,在更大尺度上有很多情况很类似。其次,对于触发内存释放的条件也有很多方法可以(在编译期和运行期)探查。
(欢迎补充)
那么我们为什么要为了少数情况(如果最终确认存在、或者处理起来成本太高的话),承担GC或引用计数的损失?或者让程序员手工处理?
别提针对问题所具有的模式进行抽象了,很多人根本没自己思考过栈和堆的合理性、引入的问题及是否、如何解决,就被大嘴们似是而非的观点给灌晕了,然后自己再变成一个大嘴,说起来一套一套的(如果能对号入座别见怪,我也晕过..)。
嗯嗯,好像我又激动了,这不好。
到此为止。总而言之一句话,咱们干活的、学习的,现在的环境是史无前例的差,好像身处一个巨大的菜市场,四处都是叫卖之声,以至于我们都没法认真的思考了。也许我唯一能做的就是买副耳塞子了 :)
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 如何编写易于单元测试的代码
· 10年+ .NET Coder 心语,封装的思维:从隐藏、稳定开始理解其本质意义
· .NET Core 中如何实现缓存的预热?
· 从 HTTP 原因短语缺失研究 HTTP/2 和 HTTP/3 的设计差异
· AI与.NET技术实操系列:向量存储与相似性搜索在 .NET 中的实现
· 周边上新:园子的第一款马克杯温暖上架
· Open-Sora 2.0 重磅开源!
· .NET周刊【3月第1期 2025-03-02】
· 分享 3 个 .NET 开源的文件压缩处理库,助力快速实现文件压缩解压功能!
· Ollama——大语言模型本地部署的极速利器
2009-01-29 职场中的我们,应该有多和谐?