一只澄闪厨的个人资料

建议官方将本期恒沙险境的排名规则特殊处理一下先声明一下，绝对的公平是不可能的，但这个做法要比现在不改明显更公平。那么具体讲就是，首先把所有成绩里面，上了X门恒沙的和没有上X门恒沙的分开。X门看实际情况而定，比如可以是3门。上了的放入参照组，没有上的放入排名组。然后仅对排名组的成绩进行排序，并确定分数的关键节点，如0.1%分界线，1%分界线等。排名组排好了以后，参照组的按照排名组的节点发放奖励即可。比如，没有上3门恒沙的成绩里面，xxxx万分是0.1%分界线，那么上了恒沙的成绩和分界线对照，超过的就按0.1%发放奖励，没达到的就按下一个档次发放奖励即可。如此一来，虽然不可能绝对公平，但比起现有做法，对没有恒沙的人来说无疑更为公平，而且没有损害有恒沙的人的利益。

你游好不容易把时曦强度改到限定应有的，希望别再出盾消耗bug啦面对这一波时曦问题，官方虽然晚回应了几天，但是终归是能直面和解决问题了，这点还是要点赞的。作为对你游的支持，我已经把时曦氪满门了。但是我们注意到，这次的修改引入了一个新东西：临时盾。所谓临时盾，就是有“有效期”的盾，过了一定时间（理论上个人回合，行动序列都可能，实际时曦这个是2行动序列）以后，即使盾没有被消耗也会消失。在时曦之前，常见的加盾途径给的护盾都没有“有效期”，也就是长期盾。长期盾只会因为消耗而消失，不会因为时间推移而消失。那这样就有可能出现长期盾和临时盾混杂的情况。这处理不好是会产生Bug的。例如：可能的bug 1: 时曦的盾和金桂盾混在一起，到期以后清理，但连同金桂盾也被误清了。这个错误实在太低级了，官方大概是不可能犯的吧。可能的bug 2: 盾消耗次序混乱。例如，第一轮金桂上盾，第二轮时曦开大加盾，同时这一轮受到伤害，那么问题来了，消耗哪个盾呢？你游一般的逻辑是先加的先用，这就会导致先用了金桂长期盾，等到后面金桂盾消耗干净了，时曦的盾正准备发挥作用呢，结果忽然到期消失了。理想的实现方法是对所有盾的到期时间排序，优先用最先到期的不知道官方是怎么处理的。希望官方谨慎一点，少出点这类容易起有害节奏的bug吧。

你游好像还没人算过概率表，那我来给大家拉个抽卡欧非表吧如有错误和疏漏，还请不吝赐教。

《高质量C++/C编程指南》与《陷阱》的讨论本文提到的“文章”，“原文”均指《高质量C++/C编程指南》。“本文”是指本篇评论。只有《陷阱》是指《高质量C++/C编程指南》陷阱。百度空间中《陷阱》一文似乎有个点击这里查看原文的字样，但没链接。我把原文链接贴一下： http://tieba.baidu.com/mo/q/checkurl?url=http%3A%2F%2Foss.org.cn%2Fman%2Fdevelop%2Fc%26c%2B%2B%2Fc%2Fc.htm%23_Toc520633988&urlrefer=b32d4717121c0e862005672436b7a6a7所有 > 开头的行是引用《陷阱》一文的文本。 (*) 文章主要从实际操作的角度出发，因此在一些地方的叙述欠缺严谨性。下文遇到类似情况，不再写出这句评论，代之以“参见(*)” (**) 考虑到文章的成文年代（2001年）以及当时各编译器对标准的支持程度（特别是VC 6带的，原文很大程度上是基于这个编译器的），加之文章从实际操作角度出发(参见(*))，也就不难理解为什么文中只字未提模板，以及会出现某些明显和标准不符的地方了（例如new的异常）。下文遇到类似情况，不再写出这句评论，代之以“参见(**)” 顺便再吐一句：Windows 98亮瞎狗眼 > 第1章文件结构 > 每个C++/C程序通常分为两个文件。 > //错误。没有强调翻译单元的概念。参见(*)。作者的本意是想说明实际操作中通常的组织代码方式。毕竟程序员日常写的是各种xxx.c，xxx.cpp，xxx.h，代码也是存放在一个个这些名字的文件中，而不是“xxx.翻译单元”中。另外，原文此处不强调某个概念什么时候也是错误了（至于两“个”文件，无视好了） > 1.2 > 建议1-2-1 > 在C++语法中，类的成员函数可以在声明的同时被定义，并且自动成为内联函数。这虽然会带来书写上的方便，但却造成了风格不一致，弊大于利。建议将成员函数的定义与声明分开，不论该函数体有多么小。 > //这条建议一般不适用于类模板。原文只字未提模板，原因参见(**) > 1.4 关于头文件目前有争议。头文件（假定里面放了函数声明等）有违反DRY原则的嫌疑。所以“但头文件可以导致其它方面——像重构（典型情况如重命名一个函数）的复杂化” > 第2章程序的版式 > 这章基本是主观内容。读者需要注意风格是有争议的，其中的“良好风格”或“不良风格”并非公认。既然是主观内容，那容许鄙人主观评论一下 > 2.8 > 很多……数据成员 > “Biarne Stroustrup ”拼写错误……效率。无评论。 > 第3章命名规则 > 这章也基本是主观内容。好吧，同意，我想说的是，原文全文都是主观内容。 > 3.1 > 规则3-1-1 > 标识符应当直观且可以拼读，可望文知意，不必进行“解码”。 > //这点和此文建议使用的匈牙利命名法有一定程度的矛盾。原文叙述的不是微软的那种匈牙利命名法（作者也不赞成，例如“‘匈牙利’法最大的缺点是烦琐”、“会让绝大多数程序员无法忍受”），作者他也说了“据考察，没有一种命名规则可以让所有的程序员赞同……而应当制定一种令大多数项目成员满意的命名规则，并在项目中贯彻实施” > 规则3-1-3 > 命名规则尽量与所采用的操作系统或开发工具的风格保持一致。 > //尽管大部分人应该乐于支持这个观点，不过事实上有时候无法实现。例如同时使用标准库和Windows API 风格的代码。这时倒不妨直接约定允许根据上下文选择要使用的命名风格。要点是，应该让人看出某个名称是用哪个风格命名的，而不至于一眼就混淆来源。赞同 > 3.2 > 规则3-2-7 > 为了防止某一软件库中的一些标识符和其它软件库中的冲突，可以为各种标识符加上能反映软件性质的前缀。例如三维图形标准OpenGL的所有库函数均以gl开头，所有常量（或宏定义）均以GL开头。 > //在 C++ 中应该考虑是否可以用命名空间代替前缀。赞同。难道又是因为(**)？ > 第4章表达式和基本语句 > 我真的发觉很多程序员用隐含错误的方式写表达式和基本语句，我自己也犯过类似的错误。 > //作者似乎没搞清楚“错误”一词的语义。 “隐含错误”一词原文表述不清，意思大概是“容易造成费解和引入Bug”。 > 4.3 > 规则4-3-4 > 不要写成 > if (p== 0) // 容易让人误解p是整型变量 > if (p!= 0) > //事实上，C++中的NULL典型地就是 int 字面量 0 （考虑到成文时间，不提新标准的空指针类型），和 int 兼容。以 Bjarne Stroustrup 的观点，这样恰恰会使人误以为 NULL 不是整数，因此推荐用 0 而不是 NULL 。链接失效…… > 4.3.5 > 或者改写成更加简练的return (condition ? x : y); > //这里的括号是多余的。个人风格问题 > 4.4 > 这节不是语言本身而是涉及语言实现的内容。以现在的观点来看，优化器会可能会在此做一些工作。当然了解一些相关原理大体上还是有益的。无评论。 > 第5章常量 > 常量是一种标识符，它的值在运行期间恒定不变。C语言用 #define来定义常量（称为宏常量）。C++ 语言除了 #define外还可以用const来定义常量（称为const常量）。 > //谭XX风格的信口开河。这段引文中逗号或者句号之间的内容，没一个能算得上是正确的。参见(*) > 5.2 > 规则5-2-1 > 在C++程序中只使用 const常量而不使用宏常量，即const常量完全取代宏常量。 > //这是有问题的。事实上很多情况下 const 只能让编译器被修饰的对象当做只读变量，而非编译期的真正意义的常量进行处理。与 #define 的符号常量（字面量）相比，只读变量受到了一些限制，例如不能作 case 的标号。完全？大概真的不可能。改成“尽量”也许好一点？ > 第6章函数设计 > C语言中，函数的参数和返回值的传递方式有两种：值传递（pass by value）和指针传递（pass by pointer）。 > //错误。形式上， C 语言函数参数只按值传递。所谓的指针传递是按值传递的一种，只是传递参数的类型是指针而已。 C只有按值传递。刻意区分这两者的目的，作者说了是为了帮助新手区分指针和引用。 > 6.1 > 规则6-1-1 关于参数省略名称主观内容，不过，个人认为养成不省略名称的习惯，通常要比习惯省略名称要好，绝大部分函数的参数名称都是有意义的。 > 6.2 > 规则6-2-3 > 不要将正常值和错误标志混在一起返回。正常值用输出参数获得，而错误标志用return语句返回。 > //在C++中可以不使用此规则而使用异常（在 C 中理论上也可以类似地使用 setjmp/longjmp ，但容易造成语义不明确，实际上基本不用）。《陷阱》补充一下基本完善了 > 6.3 本节是《陷阱》一文中仅有的几处值得讨论的地方。 > 规则6-3-1 > 在函数体的“入口处”，对参数的有效性进行检查。 > //在函数接口语义明确的情况下并非是必需的。例如 C 标准库中以及 POSIX 标准中的许多函数。 1. “并非是必须的”不是万能否定句。得说明为什么有它不会带来好处，去掉它也不会带来害处 2. 根据下文，这里的“有效性检查”就是指使用断言assert。当然，要使用得正确。和没有用相比，对程序正确性的好处是显而易见的。对于某些设计（例如契约式设计），断言是必不可少的用于检查前置条件的手段，而且也不会损失效率（release） > 规则6-3-2 > 在函数体的“出口处”，对return语句的正确性和效率进行检查。 > //同样不是必需的。此外检查可能损失效率。看看下文说的“检查”，明明就是自己复查下代码，对于return语句留个心眼，防止写出有问题或者效率低下的代码出来。根本不是“同样”的“检查”。当然，下面几条注意事项是不是有道理就是另一回事了。 > 要搞清楚返回的究竟是“值”、“指针”还是“引用”。 > //注意返回对象的语义，但是刻意区分“值”和“指针”是不必要的，严格上是错误的——它们根本就不是可以比较的一类概念。前面已经说过。 > 建议6-4-2 > 函数体的规模要小，尽量控制在50行代码之内。 > //尽管为数不多，有些特殊情况，如编译器的某些分析程序，是明显的反例。人家都说了“尽量”啦，何况只是建议。 > 第7章内存管理 > “640Kought to be enough for everybody > —Bill Gates 1981” > //和本章主题无关。和本文主题无关 > 7.1 > 内存分配方式有三种 > //有误。内存分配具体方式由实现决定，语言只限制存储类。参见(**) ，说的是VC 6吧。 > 7.2 > 漏了重复释放内存的错误（这通常会引起程序崩溃）。根据实现，可能会引起安全问题顺便说下，原文只字未提安全问题。例如缓冲区溢出什么的，最起码应该提醒一下strcat这种函数用起来要特别小心吧。 > 规则7-2-1 > 用malloc或new申请内存之后，应该立即检查指针值是否为NULL。防止使用指针值为NULL的内存。 > //对 C++ 而言是错误的。 ISO C++ 关于内存分配失败的默认行为是抛出 std::bad_alloc 异常。如果要使分配失败不抛出异常，使用 nothrow 版本，或者设置实现相关的编译选项。参见(**) ，VC 6惹的祸 > 规则7-2-5 > 用free或delete释放了内存之后，立即将指针设置为NULL，防止产生“野指针”。 > //不一定必要。例如指针是自动变量，在退出所在的块作用域被自动释放时。确实不一定必要。后文基本同意，没有新评论就不列了，只列举出有评论的内容。 > 10.2 > 规则10-2-1 > 若在逻辑上A是B的“一部分”（a partof），则不允许B从A派生，而是要用A和其它东西组合出B。 > //错误。尽管一般组合能够胜任这项工作，但并非绝对。可以使用private继承完成相同的任务，并且提供覆盖成员函数的特性。这是组合无法完成的。首先要区分接口继承和实现继承。从OO的设计角度考虑，如果按照设计原则是组合的，应当尽量使用组合。因为私有继承是实现继承，而非接口，违反了针对接口编程的设计原则。组合当然也能做到继承做不到或者麻烦的，比如运行时动态改变组合的对象（指针）。当然，如果是作为一种技巧来实现一些其他方法很难实现的东西，那各种继承还是很有用处的，不需要刻意不用。最后扯一句“头文件中#ifndef #define #endif”吧，这是原文最莫名其妙的地方之一了。大概作者希望我们能心有灵犀，意识到他就是指头文件开头和结尾的那个include guard吧……

将H2和O2充入一密闭容器，使用低压汞灯照射，会发生爆炸反应么？如题，纯想象，非危化。假设H2和O2的摩尔比2:1，温度，压强不固定。低压汞灯假设是无臭氧的（发出的光主要波长253.7 nm，能量471.5 kJ/mol），光照强度不固定。反应的活化能和温度、压强等应该有关系。那就以STP为准吧。

二氧化铅和硫酸共热放出氧气，氧气的氧元素来自哪里？有3种看法： 1. 来源于PbO2自己 2. 来源于水 3. 来源于硫酸到底哪个呢？有没有相关的资料？

问下酒精喷灯能够使用的酒精浓度感觉AR的酒精比较浪费，95%的便宜但不知道有什么影响，请教一下，有喷灯使用经验的介绍下

[实验预告]电解纯水(不是两只羊的水哦)产生臭氧目的: 定性验证电解纯水可以产生臭氧。具体内容，例如实验原理，步骤等稍后奉上。通过搜索化吧的帖子，发现实验党们早就做过电解过氧化氢制取臭氧的实验了。但还没人做过电解水产生臭氧的实验。(电解稀硫酸也可以得到，似乎也没有人去做过)甚至还有人怀疑电解水得到臭氧的可能性。因此在这里做个实验证实一下。从这个实验看来，市面上的各种电解水臭氧消毒机还是有科学道理的，不是骗人的东西。

[化万]为什么三张卡片的问题这么多人认为概率是1/2呢附上原题作参考：三张卡片，一张两面都是A，一张两面都是B，还有一张一面A一面B。现随机抽一张发现是A，问另一面也是A的概率是多少。认为结果是1/2的人，在心里隐含了一个假设，就是：那张AB的卡被抽到时，一定是A面向上。这样当出现A面向上的卡时，要么是AA，要么是AB，等可能，所以是1/2。但事实上AB的卡被抽到时，你既可能看到A（AB），也可能看到B（BA），因此这个假设是不对的。***** 如果告诉你AB的卡一定是A面向下B面向上 *****，我想没人会说答案是1/2吧？？？任意抽一张卡放桌上，你看到A面的概率是1/2（这个没争议吧，三卡六面，三A三B，要么A要么B，所以是1/2）。当看到一张卡为A时，此时要么是AA的卡，要么是AB的卡，但是这2种情况不是等可能的。本来抽到AA卡和AB卡的可能性都是1/3，但实际上我们已经排除了AB卡一半的可能性（BA不可能），所以这个看到A面的概率1/2中，包含了抽到AA卡的1/3概率，以及抽到AB卡一半的概率（AB，BA，排除BA）1/6，1/3 + 1/6 正好是看到A的概率 1/2。也就是说，当抽到一张卡是A面的时候，它是AA卡的可能性是AB卡可能性的两倍（本来要么AA卡要么AB，但是AB卡B面向上情况已经被排除）。所以，当看到A的时候，它是AA卡的可能性是2/3，是AB卡的可能性是1/3。也就是说，反面也是A的可能性是2/3。用穷举样本空间的方法也可以得到一样的结果：样本空间包含6种可能： AA AA AB BA BB BB 它们都是等可能的。其中出现A面向上的有3种情况（AA AA AB），其中两种情况反面也是A。所以是2/3 还可以用条件概率来做，P(抽到A面) = 1/2，P(抽到AA卡) = 1/3，因此P(抽到AA卡|抽到A面) = 1/3 / 1/2 = 2/3 这问题比三门一车二羊的问题迷惑性要小得多，我想大家应该不难理解正确答案吧。

[经验 & 提问] 石墨电极易掉屑的原因及防剥落掉屑的“淬火”处理石墨电极是实验党常用的电解惰性电极。价格便宜，效果尚可，在高电流密度下也有不错的表现，只要不去电解什么NaF之类的，或是高温熔融物，基本不发生化学腐蚀反应。但美中不足的是这个黑色棒棒外表强悍的同时内心十分软弱，一旦作为阳极，并且产生气体的时候，就会产生比较严重的剥落掉屑现象。尤其是在电流密度较高的时候，掉下来的碳屑和溶液混在一起，常常使得溶液变成高浓度碳素墨水。。。甚至过滤都难以过滤干净。之所以有这种现象，是由于石墨电极并不是铁打一块的。它本是由许多石墨微屑通过添加沥青等胶结剂烧结而成。其表面和内部有许多孔洞。当作为阳极电解时，由于产生的气体汇集到孔洞中，压强增大，[加之阳极的强氧化环境腐蚀了胶结剂（正确否？？请指正）]，使得电极变得酥松，在气体液体等物理作用下剥离掉屑。最近，通过网上查阅资料，我发现一种石墨电极的处理方法可以有效地减少掉屑现象。方法是：首先把石墨电极在火焰上灼烧至红热，然后迅速放入冷水中进行“淬火”处理。根据实际试验，经过这种处理的石墨电极，尽管不能完全杜绝掉屑现象，但也获得了很大的改善：使用10A的强电流电解沸腾的NaHCO3溶液15分钟后，仅仅是溶液变成了淡棕色，掉屑很少。感兴趣的可以试验一下。在此忠告一下注意安全，操作红热物体谨防烫伤，大电流电解小心溶液暴沸。有几个问题想请教一下： 1. 第二段打中括号的一段话是否正确？ 2. 为何石墨阴极几乎不会产生掉屑现象，而阳极却很严重？ 3. “淬火”处理为什么可以减少掉屑？是什么原理？

【实验】高锰酸根在电解池中的阴极还原

[H2O2] 以30V电压，15A电流电解NaHCO3饱和溶液，直到水干得到一种强碱性物质，滴加稀盐酸有少量气体放出。目测为Na2CO3和NaOH混合物。

[H2O][电解也危险]今天电解碳酸钠溶液，电流太大导致溶液爆沸眼花把电源上显示的60V看成了6V，还没搞明白为什么电流有30A，反应有这么激烈，烧杯里的溶液已经剧烈沸腾了，幸好手快赶紧切断了电源，除了桌上溅了一点溶液外没造成什么严重后果。

[安全性]电解氟化钠溶液有可能得到二氟化氧么记得以前在那儿看到过，但是现在查不到了。如果有可能，那就不电解它了，二氟化氧可不是好玩的东西。

关于石墨电极电解碳酸钠或者碳酸氢钠饱和溶液使用石墨电极电解碳酸钠或者碳酸氢钠饱和溶液的时候，大家认为阳极附近除了正常的产物氧气外，会析出少量二氧化碳么？个人认为，对于碳酸钠，由于溶液中碳酸根离子较多，对氢离子的缓冲作用比较强，不太可能有二氧化碳出来，但是碳酸氢钠有可能。