3.2 组织
对于 C++17 和 C++ 20 的工作,每次面对面的 WG21 会议有多达 250 人出席,而总成员人数约为出席人数的两倍。此外,加拿大、芬兰、法国、德国、俄罗斯、西班牙、英国、美国等十几个国家都有国家标准委员会以及 C++ 标准技术联盟的付费支持成员。成员代表了一百多个组织。为了让大家有所了解,在此列举部分成员所属组织:苹果、Bloomberg、欧洲核子研究中心、 Codeplay、EDG(Edison Design Group)、Facebook、谷歌、IBM、英特尔、微软、摩根士丹利、英伟达、Qt、高通、红帽、Ripple、美国 Sandia 国家实验室、拉珀斯维尔应用科技大学(HSR)和马德里卡洛斯三世大学。编译器供应者、硬件供应者、金融、游戏、库供应者、平台供应者、国家实验室(物 理)等都有坚实的代表。早期 C++ 中突出的电信业者的身影已经减少,而过去极少的大学的身影似乎在增加。
显然,如此庞大的组织和个人组成的群体代表着千差万别的兴趣和技术背景,需要一个组织结构来运作。会议是围绕工作组(WG)和研究组(SG)进行组织的。2019 年的夏天,我们已经有了这样一些分组:
- 核心工作组(Core WG 或 CWG)——编写语言的最终标准文本——主席 Michael Miller(EDG)。
- 库工作组(Library WG 或 LWG)——为标准库编写最终标准文本——主席 Marshall Clow(C++ 联盟,之前代表高通)。
- 演化工作组(Evolution WG 或 EWG)——处理语言建议——主席 Ville Voutilainen(Qt,之前代表 Symbio)。
- 库演化工作组(Library Evolution WG 或 LEWG)——处理标准库提案——主席 Titus Winters(谷歌)。
研究组探索新领域并设计可能的标准化:
- SG1 并发——并发和并行性主题——主席 Olivier Giroux(英伟达)。
- SG5 事务内存——探索事务内存的构件——主席 Michael Wong(Codeplay,之前代表 IBM)。
- SG6 数值——包括但不限于定点数、浮点数和分数——主席 Lawrence Crowl(
自己
,之前代表谷歌和 Sun)。 - SG7 编译期编程——最初专注于编译期反射,然后扩展到一般的编译期编程——主席 Chandler Carruth(谷歌)。
- SG12 未定义的行为和漏洞——系统地审查漏洞和未定义/未指定的行为——主席 Gabriel Dos Reis(微软,之前代表得州农工大学)。
- SG13 人机界面和 I/O——精选的底层输出(例如图形、音频)和输入(例如键盘、指点设备)的 I/O 原语——主席 Roger Orr(英国标准(BSI))。
- SG14 游戏开发和低延迟——游戏开发者和其他有低延迟要求的人感兴趣的主题——主席 Michael Wong(Codeplay,之前代表 IBM)。
- SG15 工具——与针对标准 C++ 的开发者工具创建有关的主题,其中包括但不仅限于模块和包管理——主席 Titus Winters(谷歌)。
- SG16 Unicode——与 C++ 中的 Unicode 文本处理相关的主题——主席 Tom Honermann(Synopsys)。
- SG19 机器学习——主席 Michael Wong(CodePlay,之前代表 IBM)
- SG20 教育——探索可以支持学习者和教师掌握今天的 C++ 的方法——主席 Jan Christiaan van Winkel(谷歌)
- SG21 契约——在 C++20 失败后尝试设计出契约系统(§9.6.1)——主席 John Spicer(EDG)
2017 年成立了一个小组来解决与语言和标准库设计缺乏方向有关的问题 [Dawes et al. 2018]。该方向组(DG) 的成员由召集人与工作组主席协商后任命,其成员是委员会、语言和标准库的长期贡献者。最初的成员是 Beman Dawes、Howard Hinnant、Bjarne Stroustrup、David Vandevoorde 和 Michael Wong。之后,Beman 退休,Roger Orr 加入。DG 的主席是轮流担任的,从我开始。DG 是咨询机构,其政策是只有在其成员一致同意的情况下才能提出意见。它维护有一份描述其建议的文档 [Dawes et al. 2018; Hinnant et al. 2019]。
工作组可持续十年以上,成员变化也很少。研究组则聚散自由,可能因兴趣使然,或者因为工作已经完成并提交给工作组进行最后的处理。例如,四个最重要的研究组已宣告胜利完成并解散:
- SG2 模块——主席 Gabriel Dos Reis(微软,之前代表得州农工大学)。
- SG3 文件系统——主席 Beman Dawes(
自己
)。 - SG8 概念——主席 Andrew Sutton(俄亥俄州阿克伦大学,之前代表得州农工大学)。
- SG9 范围——更新 STL,以使用概念,简化写法,及提供无限序列和管道——主席,Eric Niebler(Facebook)。
SG4 网络,目前处于休眠状态,因为其结果正在等待被合并到标准(§8.8.1)中。另一个研究组 SG11 数据库,因缺乏共识和缺乏足够数量的志愿者完成工作而解散。
某些研究组会产出技术规范(TS),这些技术规范可能是具有重要意义的文件,也以标准本身的风格写就。它们具有一定的官方(ISO)地位,但不能提 供国际标准(IS)所具有的长期稳定性。并发研究组(SG1)自 2006 年以来一直活跃,大部分时间由 Hans-J. Boehm(谷歌,之前代表过惠普实验室和 SGI)领导,它的地位已经接近 WG 了。
除了这些分组外,还有一个半官方的 C/C++ 联络组,由同时加入 C++ 委员会和 C 委员会(ISO/SC22/WG14)的成员组成。这个小组力图减少 C 和 C++ 之间的不兼容性,而 C++ 标准也会把每种不兼容之处记录下来。如果没有联络小组的不断努力,C 和 C++ 的兼容性远没有现在好。不过,即便如此,大多数从 C++ 导入 C 的特性都被修改过,而这就引入了一些不兼容性。
ISO 只需要也只认可三名正式官员:
- 召集人——担任工作组主席,制定工作组会议时间表(召开会议),任命研究组,并向更高级别的 ISO(SC22、JTC1 和 ITTF)负责——Herb Sutter(微软),自 2002 年以来一直担任该职位的工作,除 2008–2009 年期间是由 P.J. Plauger(Dinkumware)担任。
- 项目编辑——最终负责将委员会批准的更改应用于标准的工作草案——Richard Smith(谷歌);Pete Becker(Dinkumware)负责 C++11;Stefanus Du Toit(Intel)负责 C++14。
- 书记——负责记录和分发 WG21 会议的会议纪要——Nina Ranns(Edison Design Group,之前代表 Symantec)。
各个国家的标准委员会有各自自己的官员和章程。
显然,这些年来这些职位由不同的人担任过,但尽管工作量通常很大,很少有人在职少于 5 年。我曾担任 EWG 的主席 24 年,到 2014 年才把这一职位移交给 Ville Voutilainen。
通常,较小的提案直接提交给 EWG 和/或 LEWG,较大的提案则从研究组开始。提案需要以书面形式提出,并有人进行演示。一般来说,处理一项重要的提案需要数次会议(通常为数年),并且需要数篇 论文、修订论文和反复演示。最后,已经获得大力支持的提案将提交给整个委员会进行最终表决。召集人查看表决结果并裁定是否达成共识。共识不只是要多数。委 员会更倾向于能在经过工作组处理和投票后获得一致同意,如果达不到,通常至少也需要 9 比 1 或 8 比 2 的优势。召集人很可能会认为 8 比 2 的多数票未达成共识
。如果国家标准机构的负责人或几个主要委员表示强烈反对,就会发生这种情况。这样议题就会处于悬而未决的状态或者导致提案只被部分采纳。
标准会议令人筋疲力尽。通常,委员们从早餐到午夜一直在讨论工作问题。大多数时候,正式会议在 8:30–12:30 和 14:00–17:30 举行,加上大多数时候都会进行的晚间会议(19:00–22:00)。正在准备提案的委员的工作时间比这些还要长。WG 和 SG 主席一般在大多数用餐时间都在开会。周一至周五是全天,而如果没有任何意外发生,大多数委员会成员到了星期六的 15:00 左右会收工。不过,当会议在诸如夏威夷科纳(Kona)之类的好地方举行时,委员会以外的人似乎都不愿意相信开会并不是什么度假。
在 WG 和 SG 里,每个出席者都可以投一票。委员会全体会议的正式投票则是每个到会的组织一票(这样,大型组织就不会有多票),再加上国家标准机构的票数。技术性投票
和国家机构投票必须一致才算达成共识。
委员会 2006 年以前的历史记录在 [Stroustrup 1993, 1994, 2007] 中。C++ 基金会(§10.2)在其网站(isocpp.org/std)上维护了一份会及时更新的描述,涵盖组织、关键人物和委员会流程。
从 1989 年起,委员会的所有论文几乎都可以从一份文集中获取到 [WG21 1989–2020]。目前,该文集每年增加 500 多篇论文。另外,很多委员会的讨论是在已归档的邮件列表中进行的。每天可能有超过一百条邮件消息。要跟上委员会中发生的所有事情非常难,特别是由于很多事 情需要专门的技术知识才能跟进。我将自己的 WG21 论文集保存在主页 [Stroustrup 1990–2020] 上。
传统上,ISO 标准每十年左右修订一次。例如,我们有 C89、C99 和 C11。如此长的修订周期是有问题的,如果新特性错过了特性冻结,我们就会要再等上 12 年左右才能将它加入标准。人们自然就会主张将即将通过的标准拖延一两年:这个特性太重要了,不能等,因此得延迟一下标准的发布!
这就是为什么原本的 C++0x 结果成了 C++11,在 C++98 后过了 13 年。
在 C++11 之后,一些委员会成员希望缩短周期,召集人 Herb Sutter 建议我们采用列车模型。也就是说,列车在预定时间出发,任何没上车的人将不得不等待下一班。大家喜欢这个建议,也花了挺长时间讨论标准修订之间的合适间 隔。我主张短点,3 年,因为再长(例如 5 年)就容易被这个特性非常重要,等不了
这样的说法拖累,导致发布延迟。我们商定了三年的发布周期,Herb Sutter 补充建议采用交替发行大版本和小版本的英特尔滴答
模型。这也得到了同意,因此在 C++11(§4)三年后,我们发布了 C++14(§5),它纳入了之前被延迟的特性并纠正了早期使用中发现的小问题。C++17 也按时交付,但可惜并不是一次大升级(§8)。C++20 在 2019 年 2 月通过投票,确定了完整的发布特性。最终技术性投票于 2020 年 2 月在布拉格完成。
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论