奶奶的靠语言机制保证安全

lhy0416

如果做不到这一点， 给你什么语言生产出来的都是大便。
如果能， 则就算机器语言， 照样坚不可摧。

...
zylthinking 发表于 2011-11-15 23:04

那你是认为现在许许多多的东西本不应该存在的了？{:2_168:}

三月廿七

如果做不到这一点， 给你什么语言生产出来的都是大便。
如果能， 则就算机器语言， 照样坚不可摧。

...
zylthinking 发表于 2011-11-15 23:04

只要被 JAVA 惯个4、5年，不知不觉就废了，

zylthinking

那你是认为现在许许多多的东西本不应该存在的了？
lhy0416 发表于 2011-11-15 23:06

别这么正式， 我只是骂街而已， 仅此而已。
我的观点只是我自己的， 不爽了骂两句， 不想做 宗师/传教士/先知 等等寻求玩形而上的快感。

三月廿七

c++ 相比 c 语言没有太多优势...

c++ 缺点之一就是 兼容c语言， 搞的人无可适从
不知道是应该把 c++ 当 c写？ 还是把 c 当c++写？
是用 goto？ 还是用 try/catch?
是用 stdio? 还是用 iostream?
是用 引用？ 还是用 指针？

面对太多选择，很容易使人抓狂...
结果自然是很容易写的不伦不类。

通常"程序员"都应该是喜欢比较纯净的代码， 要么是c ， 要么是c++
如果写的不伦不类了，自然是留下心理阴影了.

趁早远离 c++ 才是正道， 人间正道是沧桑啊...

幻の上帝

回复 24# zylthinking

屁话，人保证其安全，就没什么类型检查存在的必要了。
语言没提供足够的接口你怎么控制？我需要一个不能转换掉const的cast怎么办？
要是人能随心所欲精确控制所有东西……语言都嗝屁好了。是不是应该在大脑装个电极直接输出CPU指令？

幻の上帝

回复 25# zylthinking

不是这个意思。我起码还能解释abc是同一种东西，用来干什么（至少小时候我爸给我解释起来我没几分钟就懂了）。
但C的括号用来干什么你就没那么容易解释清楚。

幻の上帝

回复 26# zylthinking

不觉得有些像“多态”么。虽然用起来可能不合时宜。
看来我之前也没理解错。
你这个“简洁”弱爆了。我至少可以给出3个方面的理由说明这点。
1.缺乏全面性。认为你看到的表面上的简单就是简洁。这个我之前提过，对于语言实现和标准本身的描述来说这些“简洁”带来了麻烦的事。当然，你作为普通用户可以不去管这些，但你应该仍然受到影响。你可以想一下你要了解()这种转换的形式和static_cast、const_cast和reinterpret_cast这些东西是是什么的时候，先明确知道后三者再了解()其实有不同的行为更容易，还是先习惯()再接受后三种更容易。注意你不管接不接受这些cast，()的行为之间存在的差异是无法忽视的。
这个理由对你来说应该不怎么充分，应为你不管麻烦的事情，剩下的东西意识到了也不太容易忘，算是一次性投资，比起使用来说确实不算什么。
2.需求。这个我之前也说过，当存在某种特定检查做出较详细限制的需求时，()会应付不过来而cast可以。你可以没有这种需求，但你无法断定别人也没有。
3.别忘了背景。这是C++的东西。这些cast就算不存在，背后的语义仍然存在，并且会被overloading resolution、conversion sequence这些玩意儿用到。既然如此，为什么不单独提出来给用户使用的自由？顺便，C的转换也就是对于指针类型比较泛型，剩下的基本上确定。C++不一样，任意的构造函数都可能影响转换。更别提一堆user-defined conversion了。要是没有这些cast……呵呵，可读性？见鬼去吧（虽然现在也已经很烂了，不过按你说的考虑“人的因素”，先排除一些垃圾代码——这不算很多因为一知半解的用户写出来的东西大多甚至无法编译——相对还可以接受）。这点也加强了才有上面的这个理由2。

幻の上帝

回复 27# zylthinking

你说你没用过，但看过实现。
有些问题：
1.你看的是哪的实现？
2.用什么语言写的？
3,怎么实现的？
4.你认为你看懂了吗？
5.你认为这样的实现对dynamic_cast的目的而言有什么优点或缺点？

幻の上帝

回复 29# 三月廿七
简洁不应该是指看起来的简单。简洁还包括了要在各种情况下保持它继续简单的潜在成本。
代码长还真不一定不简洁。
STL的一些东西的实现加上它们的例子，和你用C写具体的东西来说，一般来说后者容易写的更短。但当例子换一个时，前者需要改变的东西往往可以更少。这里的表面上的复杂的代码，背后的语义更加抽象和深刻，在应付需求变化的时候反而有更大的弹性，所以在更一般的场景中比具体的代码更简洁。
作为专业程序员，就别一厢情愿地认为代码是可以写死以后扔到一边就不用去管的东西了。完全拒绝这类需求是不可能的。另外，要是什么事情都要事必躬亲身体力行，那么还不如当计算机不存在好了。
当然，语言或者用户的抽象能力弱的话，背后的复杂太容易体现出来，写得再怎么短都容易认为是不简洁的。这点另当别论。

幻の上帝

回复 34# 三月廿七

其实这点我同意……成也是兼容C，败也是兼容C。异常、namespace、lambda-expr这些舶来品没有触及多少语言最核心的部分，C++在骨子里仍然是C的，却无法写出看起来像C的协调的代码——除非不用其它特性。
对我而言，C在功能上的唯一一个问题就是C没有C++的模版这样的跨类型代码生成机制。如果C有那我对C++也不见得有多少兴趣了。
也许将来C是能弄得出来，不过语法嘛……现在的C++就是前车之鉴。所以不太指望。