ISO/IEC C++ China Unofficial

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 498|回复: 11

PR0145

[复制链接]

5

主题

33

帖子

88

积分

超级版主

Rank: 8Rank: 8

威望
0
经验
55
贡献
0
发表于 2015-12-4 12:28:31 | 显示全部楼层 |阅读模式
不知道EWG怎么想的,居然把这等逗比过了
那么就肛了。(语法错误无视。)
回复

使用道具 举报

10

主题

108

帖子

507

积分

超级版主

RA2DIY 特别行政区行政长官

Rank: 8Rank: 8

威望
4
经验
388
贡献
3
发表于 2015-12-4 13:19:18 | 显示全部楼层
破事不会更少。

不过目前这样比如 foo(unique_ptr<T1>(new T1), unique_ptr<T1>(new T1)) 确实略坑。

点评

所以智商不够的不配用new。特别是都有make_unique了还想怎么着?敢用new的说明已经考虑了包括副作用顺序坑的异常安全问题。  发表于 2015-12-4 14:19
We will prevail!! www.lhmouse.com
回复 支持 反对

使用道具 举报

1

主题

16

帖子

73

积分

超级版主

Rank: 8Rank: 8

威望
0
经验
57
贡献
0
发表于 2015-12-4 14:04:46 | 显示全部楼层
看了一下, 好像反对的居多?
不过这对于旧的代码没有影响...因为本来就不确定顺序的代码都没问题, 现在确定了顺序也不会出问题.

点评

哇, 回了这么多, 吓了一跳, 我可以删除.(斜眼)  发表于 2015-12-4 14:23
旧的代码如果本身不2b不会多出问题,但维护起来一忽儿搬到新实现然后backport回来,遇到不长眼的n00b乱写就容易坑了。  发表于 2015-12-4 14:22
确定了会有兼容问题,以及会出现更多二逼代码,还不方便故意不确定。  发表于 2015-12-4 14:20
回复 支持 反对

使用道具 举报

8

主题

64

帖子

269

积分

超级版主

Rank: 8Rank: 8

威望
12
经验
169
贡献
12
发表于 2015-12-4 15:31:53 | 显示全部楼层
本帖最后由 nadesico19 于 2015-12-4 15:33 编辑

对这个我倒是持欢迎态度的,不确定性的存在本来就有碍于表达方式的发展,因为编译器要优化所以给语言戴上枷锁这种做法我觉得是本末倒置。

至于兼容性出问题、2B代码的产生,只要火烧不到头上,Why should I care?
(然而谭XX、二级党依然没有出头之日

(完了,帝球已经上好膛了
回复 支持 反对

使用道具 举报

3

主题

20

帖子

202

积分

超级版主

mikonmikonmi

Rank: 8Rank: 8

威望
4
经验
170
贡献
4
发表于 2015-12-4 15:48:54 | 显示全部楼层
nadesico19 发表于 2015-12-4 15:31
对这个我倒是持欢迎态度的,不确定性的存在本来就有碍于表达方式的发展,因为编译器要优化所以给语言戴上枷 ...

反对。
“不确定”需要预先定义,毕竟演算一事本身就不是所见即所得的(即使对某些形式系统,确实存在求值序之间的差别)。如果认定过程式的所见即所得就是确定,那么我觉得这个视野窄了点,反倒妨碍表达方式本身的存在感。
沿海征收头GAY骨
回复 支持 反对

使用道具 举报

8

主题

64

帖子

269

积分

超级版主

Rank: 8Rank: 8

威望
12
经验
169
贡献
12
发表于 2015-12-4 16:29:26 | 显示全部楼层
岩川黑鬼 发表于 2015-12-4 15:48
反对。
“不确定”需要预先定义,毕竟演算一事本身就不是所见即所得的(即使对某些形式系统,确实存在求 ...

羊驼这个说得有道理,要给求值顺序一个大家都认可的定论是很难的(倒是Lisp系不会有这方面问题?)。

不过现实情况是原有的对不确定性的定义已经开始威胁到标准库的使用和发展,在这个时候做出适度修缮我觉得还是利大于弊。
回复 支持 反对

使用道具 举报

3

主题

20

帖子

202

积分

超级版主

mikonmikonmi

Rank: 8Rank: 8

威望
4
经验
170
贡献
4
发表于 2015-12-4 17:11:06 | 显示全部楼层
nadesico19 发表于 2015-12-4 16:29
羊驼这个说得有道理,要给求值顺序一个大家都认可的定论是很难的(倒是Lisp系不会有这方面问题?)。

不 ...

这里其实不是定论问题。
形象地说,在过程式(或者algol-like)背景下生长起来的伙计们,往往不那么习惯接受“求值”和“演算”这样的概念。仔细考虑这样的问题:当我们写下一个典型的数学演算式的时候,我们会知道它具有的算律;然而到了写程序的时候,algolists反倒期望他们写下的是“看起来应当顺序执行”的指令。
如果能够意识到这样的问题,我们不妨重新看待标准库。如果需要强行顺序化求值,并非没有对应的理论基础(和“仿若”的实现方式)。这比起强行更正求值序孰优孰劣,我们不妨参照这样的态度——也即
我们是否仍然在语言中保留裸指针?

点评

如果能通过“仿若”的方式将问题范围仅限于标准库内部,给用户一个干净的接口倒还好,不过貌似已然有点收不了手的架势。。。  发表于 2015-12-5 00:14
沿海征收头GAY骨
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Archiver|ISO/IEC C++ China Unofficial

GMT+8, 2017-12-15 18:21 , Processed in 0.053644 second(s), 23 queries , XCache On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表