锦上添花：C ++标准库应该包含什么？

最新推荐文章于 2024-09-21 10:38:43 发布

dfsgwe1231

最新推荐文章于 2024-09-21 10:38:43 发布

阅读量289

点赞数

文章标签： java javascript c/c++ ViewUI

这是对盖伊·戴维森（Guy Davidson）的文章“不包括电池：C ++标准库中应包含的内容”的答复。 ”。

在过去的几年中，一直在推动将图形库包含在C ++标准中。这有点像开罗。或SDL。当前形式的提案在这里。

在目前的状态下，图书馆提案可以在预先分配的表面上绘制一些形状，对图像有一定的支持，并且有一些课程项目可以添加文本，也许可以以鼠标/键盘处理的形式进行输入。

图书馆的主要目标似乎是教学。提出的论点是，对于孩子来说，在屏幕上闪闪发光的小精灵很酷很酷。当然，已经存在执行此操作的库，还有更多，但是您会看到，C ++没有像样的，惯用的软件包管理器，因此，当然，一些著名的委员会成员得出的结论是，C ++标准应该提供2D图形库。的盒子。

我确实认为这是一条不应走的路，这样做最多是在浪费时间。让我来告诉你为什么。

但是，首先，需要进行一些澄清。

盖伊·戴维森（Guy Davidson）和其他人为此付出了大量的工作，时间和精力。推动该提案通过标准化的人们比我以前的专家要多得多。

我没有为C ++做任何贡献，所以接下来的事情只是一个人的意见。

我还想明确指出，我对该图书馆没有负面意见。我的问题是，此时需要包含2D绘画库，即C ++标准中的任何绘画库。

希望我不会被误解！

无论如何，让我们开始吧。

C ++标准库不是库。

C ++标准的确切含义是：规范明确的文档，以最详细，明确的方式描述C ++的含义以及其工作方式。目标是任何人都可以通过实现该规范来自己实现C ++编译器。但是，恰恰是该规范不够具体，或者实施得不太正确，或者执行得很周到，因此各种C ++编译器最终在行为上各不相同。有时根本无法实施，因为执行实施的人员和执行规范的人员忘记了彼此交谈。

现在，该规范的很大一部分描述了标准模板库，这是每个符合要求的编译器附带的库。

该规范至少存在5种实现，由许多实体维护。有些是开源的，有些则不是。它们每个都在选定的平台和系统子集中工作。即使它们位于任何C ++程序的最底层，也像其他任何库一样，也容易出现错误。

在这种情况下，C ++标准库中应该包含或不应该包含什么是一个非常重要的问题。与编译器捆绑在一起的标准配件是什么？大多数人需要什么才能使C ++高效？

盖伊的文章描述了一个人可以拥有的职位。也许我们什么都不需要？也许我们需要一些词汇类型？也许是容器？也许不会？我们需要文件系统支持吗？插座？ json吗？ XML？ rpg制作工具？ sql？ HTML？ javascript vm吗？ 2D图形？ 3D图形？肥皂？ IPC？窗口化？应该定义pi吗？那websockets呢？ FTP？ ssh？ VR？ AR？加密货币？ ssl？我们需要ssl但不需要其他加密货币吗？深度学习？声音？ 3D音效？视频解码？ gif？

显然，我们需要画一条线。

某个地方？

在哪

让我们看看.Net。或Java。提到STL时，通常会比较C ++和Java。 Java很酷，对吧？它基本上具有套接字，HTTP和加密以及所有内容。

但是Java主要由单个实体维护。因此，Oracle的某个人决定Java应该具有套接字并实现了套接字，内部进行了审查，现在Java具有套接字了。有时，Google希望使用相同的API进行套接字，然后在他们说“提前”之前，被要求赔偿90亿美元。

同时，C ++规范经历了漫长而痛苦的过程，直到获得投票，并且在每个功能，每种方法上都获得了多数共识。应该把它叫做data吗？ get ？ “在彭博社，我们有使用200万行代码库data经验”，彭博社的工作人员会说。 “我们注意到在EBCDIC键盘上使用类型get更快。” Will反对IBM的家伙。 “而且我们有300万行代码库”。

我对哪种模式最好没有意见。仁慈专政显然只有在独裁者是仁慈的情况下才有效。

但是，我将论证民主不适合建立一个好的图形库。

委员会资源有限。

即使睡眠不足剥夺了提案的作者的汗水，大部分工作和投票还是在为期一周的季度会议中进行，人们在会议中讨论越来越多的提案。随着委员会学会提高透明度，更多的人做出了贡献，从而为参加会议的人带来了更多的工作。这项工作几乎没有钱。充其量，您可以希望有人向您支付前往会议举行地点的佛罗里达海滩，瑞士绿色山丘或夏威夷游泳池的机票。据报道，您将永远不会看到海滩，山丘或泳池。

而且由于资源有限且时间有限，因此需要对提案进行排序，确定优先顺序甚至丢弃。 ISO C ++指南试图描述应该如何进行排序和优先级排序。

于是问题就变成了：委员会是否可以抽出时间在2D图形库上工作，这是优先事项吗？

该提案以当前形式（仅限于绘图形状）大约150页长。这是为下次会议提交的最大建议之一。

它只会变得更大。 “小型而简单的图形库”的复杂性永无止境。在该提案上的每一分钱都不会花在其他工作上。当然，人们会讨论他们感兴趣的提案，并且讨论会并行进行。仍然。在这些会议中，每20万名c ++开发人员中可能只有一个人。

让我们画一个三角形

2D图形与标准化流程所擅长的完全相反。标准化与形式主义有关，因此它最适合描述形式事物，数学和算法。现实变得越混乱，将其写在纸上越难描述，并且几十年来该纸一直是真相的来源。

首先要玩漂亮的像素游戏是要获得“表面”。绘制像素的画布。

因此，希望您有一个surface类，您可以为其指定尺寸，并为您提供一个可以在其上绘画的画布。

可是等等。在大多数桌面系统上，如果需要表面，则需要将其放在窗口中。 Windows通常具有标题，因此图形API应该可以处理它，对吗？

您可能还希望窗口具有图标。图标是大多数系统上的文件，其格式特定于系统。但是有时候它不是路径，而是对应于路径的名称。

在某些桌面操作系统上执行程序期间，窗口的大小可能会更改。

有时，可以将窗口移至具有其他分辨率的另一个屏幕。还有这种奇怪的新屏幕，其中虚拟像素大于真实像素吗？除非您要渲染图像或其他东西，否则您应该确保使用了所有酥脆小像素的全部功能，因为客户因吹嘘其屏幕的酥脆度而支付了溢价。

那边的那个女人很嫉妒，所以她买了一个电视，每像素40位。你真的看不出有什么区别，但是你要告诉她她浪费了5000美元吗？

然后，口袋里有一个屏幕，它的各个方向都旋转着，现在表面变得不规则了。但是它没有窗口，所以没有标题或图标。

现在是几奌？哦，这太小了……但是最好去看一本书WTF ELECTRONIC INK，您应该尽可能少刷新，而且只有黑色？

世界疯了吧？让我们坚持使用Linux，对吧？因此，在Linux上，有一个叫做X11的东西，您需要向它发送一个表面…哦，抱歉，在撰写本文时，X11已经过时了，现在您应该使用Wayland…除非您有帧缓冲区？可以使用opengl进行加速。或嵌入式opengl。完全不同的东西。但实际上，Vulkan的速度比这两件事都要快。哦，在这个系统上，我们希望您自己绘制窗口，关于CSD与SSD的战争已经进行了多年，而且您不能袖手旁观。

如果您使用的是CSD，请确保我可以正确拖动窗户，并且设置了粘性角，以便窗户可以很好地对齐。确保处理它们。正确地。当您拖动窗口时，窗口应该有点透明，您知道窗口合成对吗？

好的，您开始告诉自己，也许绘图很复杂。让实现者的编译器作者和库供应商应对所有这些废话。因此，您提供了一个可在任何地方使用的API，因此它绝对不会处理任何事情，也就是说，它无法在任何地方使用。

现在，编译器作者有点生气。他们一生中想要的就是编写编译器，并且在那里，他们试图了解GDI的工作原理。另外，Microsoft可能对提供绘图框架并不真正感兴趣，他们希望用户使用基于XML的WinRT工具。同时，GCC伙计们仍在尝试让std::thread在Windows上工作。

lang人得到的错误报告是“不起作用”。人们期望STL 在任何地方都能完美，一致地工作

没问题。我们将使图形库成为可选的。因此，现在标准库中有一些不是标准的。如果以及何时实施它们，它们在每个平台上的表现都不尽相同。因此，现在使用标准工具编写的代码不可移植。因此，我们需要在存储库中拥有STL的副本以及混乱的构建脚本。回到原点。

也许我们在某个地方搞砸了？让我们看一下互联网上存在的内容。人们肯定有显示器，所以一定会为他们编写库，对吧？

事实证明，Qt非常受欢迎。但是，它比显示三角形要多得多。它于1995年发布。它具有字符串，线程和大量的东西。人们真的没有提出更好的建议吗？

wxWidgets甚至更老。它也具有字符串和线程以及许多与图形库无关的东西。 GTK是完全一样的东西。

但是C ++目标与SDL之类的东西更加一致。 1995年发布，带有线程，字符串和奇怪的东西。 Allegro，1990年发行。相同的东西

您会看其他语言。当然，Rust社区有一个很棒的绘画框架，对吗？还是围棋人？原来，他们围绕Qt或SDL或类似东西编写包装器，就像他们认为从头开始就很复杂。

因此20年后，您设法在所有平台上绘制一个三角形。对于所有的一些定义。

这是相当大的成就，因此您想与世界分享您的快乐。人们主要使用语言进行交流[需要引用]，所以您将在屏幕上显示一些单词，从三角形变成那个单词有多难？

无效draw_text（std :: point2d，std :: string）;

您了解到有一个名为“ Unicode”的标准，它描述了世界各地人们使用的所有字母。这么多字母。 Unicode标准的大小大约是您5年以来一直在研究的提案的10倍。幸运的是，大多数编程语言都支持至少部分Unicode。除了C ++。好吧，现在让我们将其放在一边。

因此，文本是使用字体呈现的。字体通常安装在系统上。有一个叫做字体数据库的东西，它告诉字体是什么。除非系统没有字体数据库。或没有字体。还是没有系统。人们还喜欢使用自己的字体。

字体是一种文件，其格式为标准格式。大约有5种竞争标准。

字体文件可以包含字形表，PNG，SVG，在虚拟机中执行的脚本，以及所有这些的组合。有些字体带有颜色，但并非所有人都喜欢颜色。您的孩子喜欢颜色。他们给你寄了一封信。您将添加对猫的支持，对吗？

您将了解有关亚像素渲染的信息。您因侵犯专利权而被判入狱几个月。您认为可以利用这段时间来学习百科全书中的连字。您开始后悔成为一名开发人员，而将新职业视为修道士。

字体渲染涉及很多数学运算，因此您会读一本数学书籍，写成一个叫AL-Khwarizmi的死人。您意识到一切都是从右到左书写的。那怎么工作？

因此，也许可选的2D图形库应该具有可选的文本支持？

在多伦多举行的下一次委员会会议上（有人很久以前夏威夷就沉没在大海中），有人试图编写具有网络和大量输入的复杂图形应用程序，并避免使用意大利面条式的代码，他们希望通过某种线程进行某种事件循环。显然，这是理论上的问题，因为没有输入支持。从未就如何命名键盘键达成共识。

您回想一下所有现有框架，例如Qt（现在是8.0版），它提供了事件循环，消息传递系统和Unicode字符串类型。也许他们在做些什么。

在这段时间内，人们继续使用Qt。人们因了解Qt而被录用。他们在学校的项目中使用了它。当然，Qt仍然很烂，因为标准中添加的C ++反射功能永远不足以替代其代码生成器。但是人们并不在乎它的糟透了。确实使用QML的人。或电子。

没有显示🐅，让我们回到2018年。

反正委员会还有什么事要做吗？

要考虑，必须编写并提出建议，而图书馆建议之所以存在是因为有人在其中做了很多工作。

但是，目前，C ++具有

线程支持差（没有执行程序或使用协程的工具）
不支持启动过程
不支持Unicode
I / O设施差
地区设施差
不支持动态加载的库
不支持HTTP
与加密货币无关

该列表当然会继续。我不知道什么是C ++库的最佳人选，但根据委员会本身的观点，库建议应

对大多数人有用
拥有一个稳定的API，该API不必经常更改
有真实的经验和反馈。这就是为什么大多数C ++库开始作为Boost库开始的原因。

提案常常因为不够有用或没有经过充分的战斗测试而被驳回。考虑到人们对STL稳定性的期望，这是合理的，但是这些标准应该一致地适用。

当然，经过多年的努力，许多语言功能仍在开发中，并且它们应该优先于库功能，因为可以通过boost或其他方法来填充纯库。

教学论点

提出要包含该库的论点之一是，它将使C ++更具教学性，并且人们对基于图形的项目更感兴趣。
我同情并完全同意使C ++更具教学性的目标。但是，要确保给定的功能是可教授的，而向语言中添加主要功能（主要目的是在教室中使用）之间是有区别的。

可教学性意味着易于使用，难以滥用以及概念与其实现之间的合理映射，并且通常表现出与大多数用户的期望相符的行为。任何新功能都应追求的质量。

还可以预期，某些功能将面向高级用户，图书馆作者和专家。

但是，C ++的“教学友好部分”应该是专业设置中使用的功能的子集，而不是其他设置。

我希望人们学习使用Qt（例如），因为这是他们在职业生涯中可以使用的技能，而不是专门用于教学目的的技能。

我还认为，范围太有限的库可能会给语言造成不好的印象。如果人们被告知无法绘制表情符号或gif或使用游戏手柄，他们可能最终会认为C ++功能不够强大，并切换到其他语言，例如C＃，Java，JavaScript，Swift等。但是如果他们使用现有的，经过测试的框架，其功能强大到可以使他们实现自己的设计（Qt，SDL），即使代码不是“现代的”，他们也可以更好地了解c ++可以做什么。

换句话说，恐怕如果将人们介绍给玩具库，他们会认为C ++是一种玩具语言。

另外，“教学”需要更好地定义。

我们在谈论中学生吗？如果是这样，教他们C ++是个好主意吗？在某些情况下，Python，Javascript和Lua更合适，更容易掌握选择。我认为没关系。

我们在谈论大学CS 101吗？在这种情况下，可能需要向学生介绍构建系统，库和包管理。工具很重要。以我的经验，很多初级开发人员都不知道如何使用他们的工具，这与了解语言一样重要。人们了解并学会生态系统也很重要。 Qt，boost，wxwidgets，SDL ...

“我们需要标准库，因为很难使用第三方库”

我认为大多数人都同意这一点。在C ++项目中包含库是一种不好的体验，通常是痛苦的。在2D图形库上投入大量资源并不能解决该问题。除非每个存在的或将要存在的单个库都被纳入标准，否则，我们在哪里停下来？

我很遗憾地说，事情不会自行改善，这是不可能的。任何类型的软件包管理器的首要要求是权威。它甚至不一定必须是好的。但是，直到让各个实体来处理该问题之前，我们将继续拥有无数不兼容的半支持工具。我知道委员会的特权并不一定超出语言的定义范围，因此软件包管理的问题可能无法解决。但是工具而不是UI是C ++必须解决的最大挑战。

请注意，委员会可以在不扩大其特权范围的情况下帮助改进工具，尤其是：

寻找方法来取代预处理器的所有合理用法（反射/代码注入的工作对此非常重要）
定义便携式C ++ ABI（N4028）
定义可移植模块表示

当然，这些作品可能不如2D API那样迷人，但是它们更为基础，更重要的是，它们不能独立于委员会而进行。

事情应该以某种方式向前发展。

在查看了P0939和P0267之后，我想分享我希望在相关领域中完成的工作。当然，我不能做的比希望多得多，我只能希望激励一个人！但是我对您认为在这些领域中重要的事情感兴趣！

Unicode牛逼

我不建议这样做，因为我了解C ++为什么缺少Unicode，但是如果我们认真考虑2D图形，那么我们绝对需要适当的Unicode支持。

第一步是char8_t论文http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0482r1.html 。当然这还不够，但是有必要。
我们需要一套算法来规范化，比较，清理和转换Unicode字符串，计数字符。基于范围的东西可以很好地工作
字符类，正则表达式...我们可能不需要ICU那样多的功能，但确实需要一些功能。那可能是一个<unicode>标头。我不确定适当的Unicode支持是否是符合P0939中概述的约束的目标，但是它对处理用户输入/输出的任何应用程序（包括GUI，数据库，（Web）服务器，控制台应用程序）都将是有益的。

我不知道我们是否可以限定词汇量类型的Unicode字符串，但是处理世界语言肯定是每个人都需要的东西，并且如果有一个通用的惯用工具来做到这一点，它将更加容易。

将几何图元添加到标准

提取p0267中引入的词汇类型并独立于图形进行标准化可能会很有趣。像point_2d ， matrix_2d （最终是point_3d ， matrix_3d ）之类的类型对于图形很有用，但可能还有其他用途，例如科学计算，绘图操作。它们可能伴随着一组方法，以执行广泛使用的解析几何计算。所有这些都可以存在于<geometry>标头中。

这样做有多种原因，原因有多种

每个处理绘画或曲面的库都需要SDL_Point ， QPoint和wxPoint 。从一种类型转换为另一种类型很麻烦，容易出错。所有这些框架都可以受益于在相同坐标系中说相同的语言。这是词汇类型的定义。
这是经得起时间考验的保证。数学不受新技术趋势的影响，因此API可以保持数十年的稳定。
出于同样的原因，达成共识可能很容易，很难舍弃基础数学。