-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
可否像维基百科一样引入争议性内容出处。 #301
Comments
感觉书里关于nullptr 的来历动机, 和网上的内容形成了很大争议,如果方便,请标注一下权威的出处。 |
这个理解和 WG21 N2431 没什么冲突。
|
原来理解来自于这里,应该标注上。 不过我对提交这个讨论的人同样不苟同,弱类型应该不能通过思维逻辑到强类型上。 这个单纯是增不增加类型的问题。 保持弱类型,它肯定就是弱类型,总不能搞运行时的动态语言吧。 个人非常难以接受c++现代化之前很多跳大神的行为。 感觉那段时间的标准委员会几乎都是原教主义的激进份子。 最严重的是 长期试图使用模板跳大神模式达成编译器的行为,这直接逼走了一大批用户(并且还洋洋自得,看我模板图灵完备)。 许多比c++还不工业化的语言,都选择了直接开放编译器中间件的模式, 比如JavaScript+babel, 这样语法直观又简洁。 dirty work 和用户的项目完全隔离开, 不干扰程序真正试图表达的语义。 不过目前来看c++ 17 以后一切都在变好, 虽然其他没有接触过 新c++的用户,还保留着过去c++恶劣不堪的印象。 |
我估计下面示例代码不能复现的原因,应该较为类似 #289 提出的原因 |
今天刚开始看这本书。第 2 章 语言可用性的强化,2.1 里写 nullptr ,描述为NULL具有很奇怪的简单的逻辑设计失误, 这个理由很反直觉,按理说 处理关键词 单纯是编译器的设计,如果不是为了兼容性,NULL在编译器层面很好处理, 我简单查了一下,网上更多的说法是 C++ 从前是为了保持了 C的兼容性 保持了 NULL的一致性,既然保持兼容性那NULL必然是保持一致的弱类型。 然后 后来权衡下引入了安全的类型nullptr, NULL作为遗留性继续兼容C。
感觉这就是单纯的决心增加类型安全性nullptr, 而不是在这点上保持与旧的C一致性的的选择问题。 和逻辑完全无关。 然后我又查了下后来的C23也开始增加了nullptr类型。不过并未进一步查询是否一定的原因是为了增加两种语言的兼容性。
文中举例的代码,在msvc下以cxx_std_20 编译 是可以通过的
The text was updated successfully, but these errors were encountered: