幻の上帝

正式用户

最新动态 4月前

  1. 5月前
    2018-07-27 20:36:16
    幻の上帝 更新于 关于DEV C++和opengl的bug

    8102年了,为啥要用这类古董……(如果用IDE,请确保IDE能以足够傻瓜化为卖点而不是把你拐到坑里;或者你应该清楚常见问题的分析套路。)
    -mwindows指定链接使用Win32子系统,启动程序时不会脑补一个控制台出来(进一步细节我在这里 有提,搜-mwindows)。至于标准输入输出流,那应该没有影响,只是到控制台的关联的默认逻辑被干掉了,简单情况就是重定向代替。如果你还要控制台就得用控制台API,比较麻烦,不建议这样搞。
    GDI不能使用了……不清楚具体症状和你怎么拿到的DC怎么用的问题,暂不评论。

  2. 2018-07-27 20:33:53

    不讨论立场和论据有效性,对最后结论之前的论证有个问题。
    为什么是“「碓」能被更多的输入法打出,因此本文推荐使用「碓」”
    而不是
    「碓」能被更多的输入法打出,因此本文推荐使用「㨃」而使输入法适应推定正字法的要求?

  3. 去年
    2017-11-14 12:19:36
    幻の上帝 更新于 C++如何防止数组越界

    @长岛冰茶 用数组并不是什么大问题吧。。。我现在写计算物理用的基本都是数组,主要是越界检查这种习惯的养成的问题

    不管是之后修改代码还是让别人读,抽象不当从来都是问题,只不过刷题用的一次性代码问题看起来没那么突出而已。
    如果目的是用高级语言表达正确的逻辑,越界检查这样的操作甚至都不应该需要成为习惯;应该成为习惯的是使用接口自觉注意满足前置条件(首要的前提是得知道是啥),而不是依赖是否存在越界检查这样的实现细节,剩下的让语言规则隐含的不变量保证。当然,越界检查也可以设计为接口的行为,像vector::at;不过之前提的文档已经讨论过为啥artificially widening narrow contracts不是好主意了。
    不过比起数组,更大的问题在于为什么你得用会让你想到用数组的古董C++……

  4. 2017-11-13 19:28:35
    幻の上帝 更新于 C++如何防止数组越界

    @Sakura 原题目是要求统计100000个随机的0-50的数字出现频率,那么显然用数组是很不错的做法啊
    而这个我是不小心把遍历数组的上界写大了,发现不同的编译器处理起来结果不一样,所以想到了这个问题

    于是为什么你会觉得这是“显然是很不错的做法”?是因为你一下子想到了数组而没想到用别的嘛?另外你有没有想过“结果不一样”是什么原因?
    正常的选型思路先分析清楚你需要什么之前,忘了哪些东西能被实现支持。你这里的算法也就要求能放50个计数的容器,并不是数组那么具体的东西。在这个基础上,想到用std::vector毫不费力,而不是先想到数组再绕一圈回来想到怎么满足避免不可预期的行为。(硬说的话,确定类型的精确的解是A<std::size_t, 50>,其中A是受参数50作为容量的最小值约束的容器,在C++中不好直接表达,就这个问题也没啥用。)
    作为实现者,你本来就应当保证整个过程中都只会涉及well-defined的操作,然而你所谓的“处理起来结果不一样”就不是,所以遇到这个问题就足够说明你思路的缺陷了。之后分析非预期行为会拐到所谓“内存地址”之类不确定的实现细节上,也同样表明这一点。
    须知,至少对C++这样的语言,选择静态类型的问题上,你的第一印象很可能会有后遗症——不管你要的是可行解还是最优解。对现在的C++,看到数组或者指针类型基本就说明代码馊了;这样的类型是非常特定场景才合适的东西。你需要了解什么时候引入合适的抽象。

  5. 2017-11-12 21:10:39
    幻の上帝 更新于 C++如何防止数组越界

    感觉问题的目的不太明确。先补基础 吧。

  6. 2017-11-12 20:48:07
    幻の上帝 更新于 C++如何防止数组越界

    为什么你会想到用数组这种东西。

  7. 2017-03-08 12:30:00
    幻の上帝 更新于 [C++]STL几种算法简单介绍

    好好的标准库spec 不看撸毛实现……然后看清楚之后就知道里面并没有你所谓的STL;事实上在这类语境 中讲的STL基本是指这个
    不纠结concept拿SGI的古董考古干嘛。
    至于这坨实现……一看不是__迫真UB__ 就是漏ADL 啥的,能吃么。

  8. 2017-02-22 04:54:00

    新发现一段科普读物 ,其中的Chapter 8.1提到了一些类似的破事和文献名称可供消遣。

  9. 2017-02-07 01:51:10

    我没找到纯粹逻辑角度出发的系统性描述,也许是动机不太充分,所以也没有严格地统一定义这样的性质。但经验上来看,类似的倾向整体看的确容易导致不方便实现的“坏”的形式。
    也因为没有统一的严格定义,我找不到关于如何避免非直谓命题的一般的结论。对于具体的演绎系统来讲可能会清晰一点。同理,“一些直谓性的和非直谓性的命题来证明其实两者可以互相转化”在这个意义上无法判断,因为概念缺乏精确的外延。
    例如,就你的例子,如何判断一个程序是否具有属于“包含解程序本身的输入数据”的形式?注意尽管构造反例证明停机问题不可解这点大同小异,但现存的各个证明本身实际上各自依赖不同的具体模型(比如图灵机或者λ演算),不同的模型之间并非构造性地天然等价,而是需要补充假设(就图灵机和λ演算而言,这个假设是邱奇-图灵论题 ,被广泛承认后实际上定义了可计算性)。由于模型的构造不保证一一对应,在不知道“形式”的外延时,自然也无从确保输入数据“不以任何形式包含解程序本身”这个判定性问题的解在各个模型中都一致了。通过添加更多的假设和定义来针对不同模型区分不同的自指也许会有一些更一般的结论,不过我不清楚能一般到什么程度。

查看更多