【程序员搞笑图片】自我感觉良好

104 条评论 | |

你也许感兴趣的：

共有 104 条讨论

  1. 委员会花了 3 年时间才通过

    回复

    1. > std::print 多花了 3 年时间，主要是因为 Windows 上的 Unicode 因层层遗留的代码页而非常残缺。

      回复

      1. 3 年太短了。也许在 c++ 30 多年后，我们就能得到没有丑陋模板的静态反射了。

        回复

        1. 该死。2030 年已经不再遥远了。

          回复

        2. 也许在 2036 年左右，我们可以开始在生产代码中使用 C++30。

          回复

          1. 鉴于目前在生产中可以合理使用的最 “现代 “的 C++ 是 2017 年（而且只有在非常幸运并在一些积极维护的项目中工作的情况下），这种说法非常乐观。现实世界中的许多软件甚至从未达到 2011 年的水平。

            回复

            1. 我的工作最近升级到了 C++20。我们的代码库已经有 20 年的历史，文件数以万计。这是可行的。

              回复

            2. 是啊，我刚按下回车键就意识到我应该把年份写得更晚一些。必须在规范发布后的几年内，让这些功能进入编译器，然后再过几年，这些功能才会被认为足够成熟，可以使用。

              回复

              1. 是啊，要在所有编译器中以可用的方式实现这些功能，已经需要很长时间了。您可以使用的是所有编译器中实现方式的交集。目前，C++ 2017 或多或少已全面实现。但除此之外的任何内容都不是。

                回复

        3. 如果没有令人恐怖的符号和分隔符的乱码，真的会是 C++ 实现的东西吗？

          回复

      2. 怎么说？我记得我曾经捣鼓过一次 Unicode，一旦我掌握了窍门，它似乎就变得相当简单了

        回复

        1. 因为 Windows 默认不使用 Unicode，而且使用 unicode 的方式也与其他人不同，所以

          回复

  2. 我想说的是，cout 逊毙了。它一直都很烂。

    这是有人想耍小聪明的一种语言特点，他们想：”嘿，看，我们可以在编译器中做到这一点（运算符重载），然后他们就觉得很有趣，我们就这么做吧，让运算符以一种你根本不知道到底发生了什么的方式调用函数，这样追踪起来就会很麻烦，然后我们就在 hello world 的例子中使用这种奇怪的技术！”我并不完全反对运算符重载。

    我并不完全反对操作符重载。它在 DSL 之类的东西中非常棒。它是一种强大的语言功能，但我个人认为核心语言不应该使用它，因为它不是 DSL，而是一种通用语言，所有操作符都应该是标准的、可预测的。

    回复

    1. 让 std::endl 冲洗流也是一个非常糟糕的决定。初学者会认为你应该一直这样结束一行（很明显，为什么不呢？）

      令人印象深刻的是，他们是如何把写入 stdout 这么简单的事情弄得如此糟糕的。

      回复

    2. std::cout 和 << 的重载都是为了提供一种类型安全和可扩展的方式来执行格式化输出，并避免 printf 的陷阱；它可能并不完美，但却是一种改进。

      回复

    3. 很难同意。std::print和std::println依赖于C++ 20格式化库，而格式化库本身又依赖于C++ 11的特性。

      回复

      1. 所以你说，35 年前他们就应该在基础语言中加入适当的字符串格式化功能？我同意。

        也许 C++ 2050 会提供这一基本功能，甚至现在连 JS 都有了。

        回复

        1. 这是什么观点？C++ 和 JS 是不同的语言，在速度、向后兼容性、抽象成本等方面有着不同的要求。这就好比要求 JavaScript 具备与 C++ 和 C 一样快的基本功能。如果 C 可以在 1972 年达到与 C 一样快的速度，为什么 JS 就不能在 2025 年达到呢？

          解释型 JavaScript 和 Python 分别在 2015 年和 2016 年实现了字符串插值。认为 C++ 在 35 年前就应该有编译时类型检查的字符串插值，而 Python 在 10 年前还没有运行时未检查的字符串插值，至少可以说是一种乐观的想法。

          回复

        2. 我的意思是，当然，但对于典型的真实 C++ 工作负载来说，稍微好一点的字符串操作能带来多大的不同？我不一定说这不是问题，但它在我的 C++ 愿望清单中也不是特别重要。

          回复

    4. 我想说的是，我真的不喜欢 “DSL”，它只是对函数的包装，而不是使用解析器生成器和编写基本的编译器或解释器。 Antlr 已经有十多年的历史了。 还有其他的解析器生成器。 作为运算符重载集合的 “DSL “应该只是对命名良好的函数的标准函数调用，而不是轻量级解释型语言

      回复

      1. 编写编译器或解释器，而不是做简单的事情？

        有些人还不明白 “复杂是敌人 ”的道理？

        在集成开发环境（IDE）中为您的自定义语言提供语法高亮和代码智能等基本功能呢？文档如何，尤其是针对您自制的编译器/解释器的所有怪癖的文档？

        DSL 只是一些函数调用。这是简单且可预测的事情，而且几乎没有任何开销（精神或计算开销）。相反，编译器是一些最复杂的软件。

        能够写出

        1 + 2 - 3 * 4 / 5 ^ 6

        而不是

        MyCustomNumberFormat.substract(MyCustomNumberFormat.add(1, 2), MyCustomNumberFormat.multiply(3, MyCustomNumberFormat.divide(4, MyCustomNumberFormat.power(5, 6))))

        是上帝的恩赐。

        在 Java 中处理大数字、向量或矩阵的人都知道这种痛苦。

        回复

        1. 写一个编译器或解释器，而不是做简单的事情？

          如果你曾经编写过复杂的 DSL，你就会知道我建议的是简单的事情。如果你一开始使用的是无原则的大杂烩方法（这通常就是这种方法的情况），甚至是真正有原则的方法，你最终会意识到你需要通过归纳推理来思考你的语言。 一般来说，解析器生成器会使用访问者模式和 AST，从而使其变得简单。我看到有人在 React + Typescript 中使用 g4 语法在一天之内就实现了基本的解释器

          有些人还是没明白复杂性是敌人的道理！

          在任何规模合理的 DSL 上，方法论都会更加复杂。 此外，它的结构性也更差，通常会给你带来更差的错误报告/推理能力。

          在集成开发环境中为您的自定义语言提供语法高亮和代码智能等基本功能如何？

          如果你在语法工具包中使用，你可以从 IntelliJ 免费获得这些功能。

          为您的自定义语言提供构建工具支持如何？

          告诉我什么构建工具可以在您的宿主语言中识别您的自定义语法？

          关于文档，尤其是关于您自制编译器/解释器的所有怪癖的文档如何？

          通常情况下，当你写出一个像样的编译器时，错误信息会更清晰。 请注意，我在这里所说的一切显然都取决于是否采取了有原则的方法。我并不是说你不能编写一个像样的 “函数集合方法”，但我用过的许多方法通常都会在函数内部出现奇怪的堆栈跟踪，如 execOps(coerce(myVal)) 而不是合理的错误信息。

          1 + 2 – 3 * 4 / 5 ^ 6

          使用语言内置的运算符和优先级不是 DSL。 你只是在描述运算符重载。 顺便说一句，我可以在一两天内为上述针对大 ints 的 “DSL “编写一个解释器。

          回复

        2. 我想到了一个更简单的方法来表达我的观点。 如果您在实现 DSL 时没有扩展操作符，使其适用于与已适用类型非常相似的类型，那么随着 DSL 的发展，您基本上就是在创造一种编程语言。

          是使用半个世纪以来在实现编程语言过程中积累的工具和模式更好，还是使用自己自创的方法更好？ 最终，你认为哪种方法更有可能正确、可维护且更简单？

          回复

        3. 你能写出来固然很好，但很多时候并不清楚，因为 “+”没有名字，所以你必须深入查找才能找到。

          让矢量对象使用数学语法是一种 DSL，它是矢量数学的特定领域语言，它保持了 +-*/ 的含义，并且具有内聚性。(或任何自定义数字格式）。

          << 是一个有点聪明的运算符，除了看起来像箭头外，它与摄取或产生 IO 毫无关系。这可能是当时最好的运算符，但它滥用了运算符重载。

          回复

    5. 我不知道追踪操作符调用时会遇到什么麻烦。你知道这是一个重载函数调用。问题出在哪里？

      回复

      1. 有些人不使用集成开发环境……

        这在 C/C++ 开发人员中并不少见。

        当然，用 CTRL 单击某个符号来查看其定义是很简单的。但前提是您使用的是集成开发环境……

        回复

        1. 对于那些选择不使用集成开发环境或同等工具集的人，我要说：祝你们在后面呆得开心。

          回复

    6. 由于操作符重载而无法跟踪函数调用是一个技能问题。我永远不明白为什么那么多人有这种看法

      回复

    7. 我个人认为核心语言不应该使用它，因为它不是 DSL，而是通用语言，操作符都应该是标准的、可预测的。

      [/ 引]

      这当然是我以前从未听过的观点。

      回复

    8. 而且速度慢得要命。在生产代码中永远用不上它，总是要使用普通的 C 函数。

      回复

  3. 这就是我坚持使用 holy c 的原因

    回复

    1. Std::print（和 println）使用 std::format 格式化字符串，而不是使用 c 格式化指定符。这允许你为自定义类实现 std::format 的特殊化，从而更容易打印它们。

      回复

      1. 而且这样做更安全，因为 std::format 类型会在编译时检查格式指定符，所以如果你使用 std::print(“{:d}”, some_not_decimal_variable)，你会得到一个编译错误，而不仅仅是程序不安全。

        回复

        1. 我不确定在现代，printf 是否真的更安全。大多数与 printf 有关的安全问题都已通过编译时标志（如 -Wformat 及其扩展）（gcc 帮助文档）得到了 “解决”。所有开发团队都 “应该 ”默认启用这些功能。

          此外，对于自定义的类似 printf 的函数，也可以通过 __atribute__((format(printf, x, y))) 轻松启用。

          回复

          1. 这些都是你需要了解的神秘知识，而不是语言默认做的正确事情。

            你需要知道的这些玄之又玄的东西，正是 C++（和 C）如此令人难以置信的困难和用户敌对的原因。

            printf 很容易受到格式字符串攻击，很容易出现 UB，不允许扩展（你不能轻易用它打印自定义类型），而且它总体上是一个有点差劲的老式 API（例如它也不是类型安全的）。

            回复

      2. 用它打印自定义类型并不容易

        这就是为什么我 20 年来一直使用 Sfio 来代替 studio 的原因。

        回复

    1. 不，你在 Predef.scala 中有 println。

      回复

        1. No no. TRANSLANG🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️🏳️‍⚧️

          回复

          1. 调用 translang。请使用新语言，是时候有一种新的时髦语言出现了

            ，也许我们甚至可以使用人工智能和振动编码来进行翻译！

            回复

      2. 然后由用 C++ 编写的 LLVM 编译成二进制 🙃

        回复

        1. 还有 Cranelift 和 GCC 作为（实验性的）codegen 后端。不过，访问文件系统需要 C++17，该标准有点慢。

          回复

        2. 这不是 C，正如最初的评论所暗示的。

          回复

        1. 实际上不是。Rust 版本 n 需要 n-1。一路下来都是线性的。但从最初的 rust 开始编译需要几天时间。

          回复

                1. 现在有人会问，最初的 OCaml 编译器是用哪种语言编写的。(不知道，最好的猜测是 C++，但也可能是 C；但鬼知道，也许是类似 LISP 的语言）

                  回复

  7. 其他语言都是 C 语言的克隆，功能较少。

    回复

      1. preach

        c++ 就像试图打开一辆破铜烂铁的电子卡车上的空调，你必须在触摸屏上浏览 6 个用户界面才能提高温度

        回复

        1. 如果你不对除了你喜欢的那门语言之外的所有语言大放厥词，那你还算是程序员吗

          回复

  9. 这个位置代表了你与硬件的接近程度，这是因为与 Python 和 Java 类似的语言相比，C++ 是一种低级语言，对吗？对吗？

    回复

  10. 这和只用 cout 有什么区别，我是新手

    回复

    1. 我想大多数情况下都是一样的，但与所有其他语言相比，cout 是一种相当非典型的打印到控制台的方式

      回复

  11. include <iostream>

    using namespace std;

    cout << “cout better”” << endl;

    回复

  12. 这很有趣，因为这是事实。除非你是新手，否则不需要其他信息。

    回复

    1. C++ 刚刚在其标准库中引入了专门的 std::print 方法。

      我会坚持使用我最信任的 std::cout

      回复

      1. I’ll stick to my good ol trusty std::cout tho

        Streams suck, man

        回复

        1. 流式计算学习起来肯定很乏味。但一旦你学会了，它们就会非常有用。

          回复

          1. 流确实很难学

            它们就是不好。<iostream> 会拖慢编译速度，重载运算符会误导读者，支持自定义流缓冲区也很麻烦。

            我不会向任何人推荐使用流。

            回复

            1. 我的工作经常要用到流，所以我已经与它们和平共处了。它们对我来说已经是第二天性了。

              不过我同意超负荷位移的说法。

              回复

            2. <iostream> slows down compilation as hell,

              pigeon@hawking ~ $ cat foo.cpp
#include <print>
int main() {
  std::print("Hello world!n");
  return 0;
}
pigeon@hawking ~ $ time g++ -O2 -std=c++23 foo.cpp -o foo
real    0m1.334s
user    0m1.313s
sys     0m0.020s
pigeon@hawking ~ $ cat bar.cpp
#include <iostream>
int main() {
  std::cout << "Hello world!n";
  return 0;
}
pigeon@hawking ~ $ time g++ -O2 -std=c++23 bar.cpp -o bar
real    0m0.392s
user    0m0.367s
sys     0m0.025s

              操作符重载会误导人

              C++ 开发人员应该熟悉操作符重载。没有它，你就无法使用eg std::variant。你不能让你的类型在 std::unordered_map 中作为键使用哈希值。如果你不能或不愿意重载操作符，那么很多 C++ 对你来说都是封闭的。

              支持自定义流缓冲区很麻烦。

              [/ 引]

              ……不是吗？

              回复

          2. 流作为概念是有用的。不过 C++ 的语法和实现太烂了。

            回复

      3. just

        定稿的std::print提案发表于2022年。

        回复

          1. it was added to the specification in C++23

            aka the 2023 version

            回复

            1. Ah sorry. 我在 C++ 20 上工作，所以从来没有亲自赶上过更新

              回复

              1. 使用只有 5 年历史的 C++ 版本？你在哪里工作，一家闪亮的新创公司吗？(/s)

                回复

                1. 不能合法讨论细节，但与军事有关。

                  回复

  14. 这是什么备忘录模板？我喜欢它，哈哈

    回复

  18. 我宁愿这样，而不是什么都加，什么都加，10 年后就乱套了。但也许这有点迟了……

    回复

  19. 哦哇。打印。Cout 也非常棒，用途非常广泛。

    回复

  20. 这个 subreddit 里的人在无意义的蠢事上大做文章

    回复

  21. 你是在告诉我，我一直在无缘无故地做 std::cout

    回复

  22. #define print(… ) printf(__VA_ARGS__) 🥇👩🏻‍❤️‍💋‍👨🏻🖕🖕🍾

    回复

    1. std::print 和 printf 使用不同的格式说明符

      回复

      1. 我相信对于这个备忘录中给定的测试用例，它肯定没问题。

        回复

        1. 对于这个案例是的。对于其他所有案例都不行。

          回复

          1. print(“No shit?”);

            估计这也行得通！

            回复

            1. print(“fuck {}”, “off”) 这个不行？真奇怪，好像你故意说得太多了。

              回复

              1. 你好像觉得这是堆栈溢出什么的？这完全符合备忘录的精神。

                另外，你的评论仍然可以编译，我们都知道这是衡量 C++ 成功与否的唯一标准。

                回复

  23. 在虚幻引擎 5 中编码的最佳程序语言是什么？🤔

    回复

    1. 虚幻引擎已经过时而且臃肿。使用 scratch，编程简单，具有大量的可移植性👍

      回复

    3. 在虚幻引擎 5 中编码最好的程序语言是什么？🤔

      使用光标和 ai 以及 vibe 编码吧宝贝！这就是现代开发人员超越神的方式。

      回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注