我从官方收集与组织了这些信息，没有任何我个人的主观评论。如果你想知道这次会议的主要内容，请阅读下面的内容（我已经知道了绝大多数关于c++17库的内容，但是要将其全部写出来还是需要一定的时间）
<a></a>
p0001r1 弃用<code>register</code>关键字
p0002r1 <code>bool</code>类型不再支持<code>++</code>运算符
p0012r1 异常成为类型系统的一部分，第五版
p0061r1 支持<code>__has_include</code>
p0134r0 引入非静态成员变量的拷贝构造函数//not sure
p0136r1 重写继承构造器(core issue 1941 et al)
p0160r0 删除一元运算符的预设值//wording for removing defaults for unary folds
p0004r1 弃用过时的<code>iostreams</code>的别名
p0006r0 采用基于标准库规范的类型特征变量模板
p0092r1 优化
p0007r1 constant view:一个::as_const 的辅助函数模板
p0156r0 可变的lock_guard (rev. 3)
p0074r0 使std::owner_less更加灵活
p0013r1 逻辑运算符类型特征 (revision 1)
n4531 替换std::rand，版本三
p0013r1 逻辑运算符类型特征 (revision 1)[c++17投票通过]
这些文件将会应用于n4529草案，然后进行拟议草案技术规范的投票。
p0159r0 将会作为并发技术规范发布，届时可能稍作改动。
n4505草案和p0155r0的”task block r5”负责这项工作。
p0112r1草案负责这想工作。
p0021r0草案负责这项工作。
1274.常见的非终结符表达式和内嵌初始化列表
1391.非推导模板参数到参数类型的转化
1722.lambda函数指针转换函数应该不例外吗？
1847.部分排序时声明一致性
1863.抛出对象的类型应该支持std::current_exception()
1949.”sequenced after”代替”sequenced before”
1975.允许声明异常类型
1981.隐式和显式的上下文转换
1990.decl-specifier-seq造成的歧义
2000.<code>#include</code>之外的头文件名称
2004.常量表达式中有可变成员的变量
2006.cv-qualified的void类型
2015.虚函数的odr-use
2016.类型转换函数的描述中可能存在的歧义
2019.存储时间描述中成员引用的省略
2024.依赖类型和未解包的参数包
2026.zero-initialization和constexpr
2027.指定多个alignas的需求不明
2031.<code>&&</code>的不兼容
2052.模板参数推导vs重载操作符
2075.传递短初始化列表给数组引用参数
2101.对类型和值的依赖的错误说明
2120.数组作为标准布局类的第一个非静态成员变量
1169.<code>num_get</code>不能和strto*完全兼容
2072.缓冲区容量定义不明确
2101.一些类型转换可能产生非预期的类型
2111.处理异常时可能调用那些已经删除的句柄？
2119.扩展int类型缺少哈希函数
2127.带raw_storage_iterator的move-construction
2133.重载逗号迭代器
2156.无序容器的reserve(n)保存的是n-1个元素
2218.容器如何使用allocator_traits::construct()不够明确
2219.invoke-ing一个带有reference_wrapper的指针作为对象表达式
2224.不活跃对象的状态问题
2234.assert()应该允许在常亮表达式中使用
2244.关于basic_istream::seekg的issue
2250.library issue 2207中的follow-up
2259.17.6.5.5规则中有关成员函数的问题
2273.regex_match的歧义
2336.is_trivially_constructible/is_trivially_assignable结果永远是false
2353.std::next限制过度
2367.pair和tuple无参数时不兼容is_constructible
2380.<code><cstdlib></code>应该提供long ::abs(long) 和long long ::abs(long long)吗?
2384.分配器的解除函数需要更好的规范
2385.function::assign分配器参数无意义
2435.reference_wrapper::operator()的标记应该是被删除
2447.分配器和volatile-qualified值类型
2462.<code>std::ios_base::failure</code> 被过度规范
2466.<code>allocator_traits::max_size()</code>默认表现是错误的
2469.map的[]操作符和unordered_map规则错误
2473.<code>basic_filebuf</code>对c文件的兼容
2476.<code>scoped_allocator_adaptor</code>是不可分配的
2477.<code>std::vector::erase()</code>和<code>std::deque::erase()</code>的不一致
2483.<code>throw_with_nested()</code>应该使用is_final
2484.<code>rethrow_if_nested()</code>是不可实现的
2485.常量tuple&&应该重载get（）
2486.<code>mem_fn()</code>应该提供向前兼容
2487.<code>bind()</code>不应该是cv-overloaded, 而应该是const-overloaded
2489.<code>mem_fn()</code>应该是noexcept的
2492.明确comp的需求
2495.没有类似异常安全元素的东西
2494.[fund.ts.v2] ostream_joiner应该是noexcept的
2500.[fund.ts.v2] fundts.memory.smartptr.shared.obs/6 应该适用于cv-unqualified void
2515.[fund.ts.v2]observer_ptr的确定操作符不能匹配任何简介
2517.[fund.ts.v2] 两个propagate_const assignment 操作符返回不正确的类型
2526.[fund.ts]experimental::function::swap 条件不正确
以上只是投票通过的部分记录。每次的会议都会涉及很多工作，不会全都反映在文件上，比如，有关modules的热烈讨论文件中就没有。虽然我几乎花了所有的时间在库工作组中，但是还是不能跟进所有的内容。最终版文件我会在reddit分享各个模块的进展。
本文作者可以回答大多数有关库的问题，但是可能回复略有延迟。可以确定的是，库的可用性提高了。看起来一切都像小猫一样温顺可爱，但是如果你去看一眼重载集合，就会发现这些模棱两可的东西简直是灾难。lwg2451是作为标准库定义的一个极好的例子，<code>optional<string> opt_str = "meow";</code>现在还未实现。对于基本规范没有什么问题，但是<code>optional</code>的ship-stopper不符合国际标准。在这次会议上，lwg意识到一些issue影响到了<code>variant</code>，问题会牵扯到基本规范。当然了，会议会解决这些问题，你不必经历这些痛苦。
本文来自云栖社区合作伙伴“linux中国”，原文发表于2013-04-02.
![阿里云ECS（ubutun）下安装docker[图]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)