C ++ 0x标准化过程的最新Herb Sutter trip report表明委员会决定完全删除模板的“导出”概念,并弃用异常规范。
我认为这些都是很好的举动,但是我感兴趣的是,如果有人有代码库,这些变化会导致他们不眠之夜吗?
答案 0 :(得分:14)
我从cfront 1.0开始用C ++进行编程,我很高兴地说我从来没有编写过异常规范或允许我负责的代码。当他们被提议时,我打电话给Bjarne Stroustrup喊道:“不要这样做!”我给出了他们为什么是一个可怕的想法的所有理由。令我惊讶的是,他说了一句“我知道。”当我问为什么来自哈迪斯的特征进入规范时,他说有一个大玩家的“专家”坚决坚持它必须进入规范或他们绝对不会签署,期间,讨论结束。如果我知道它是谁,我已经忘记了。
我已经弃用了很长时间。 : - )
答案 1 :(得分:5)
在过去的5到6年里,我所参与的任何代码库都没有不眠之夜。我不认为我曾经遇到过任何使用过export
的人,而且像Herb Sutter这样的专家已经对异常规范(除了nothrow)提出了长期努力,以至于大多数程序员现在已经收到了消息。
答案 2 :(得分:4)
export
从未在gcc或MSVC中正确实现,(但在EDG / Comeau中显然是如此,正如评论所说),但我猜它从未被广泛接受。 (但我主要生活在gcc / msvc世界中,所以我的观点并不包含整个C ++社区。)
至于例外规格,我相信它们也被打破了。
第三,弃用并不意味着会导致编译错误。强烈建议用户不要使用它,如果适用的话(我认为这里不多),继续使用其他机制来实现相同的目标。
答案 3 :(得分:3)
我当然不会对异常规范有所了解。 (“不幸的是,这个好主意从来没有成功过。”)现在noexcept
所代表的一切都是好的。
但我曾希望export
能成功。至少,export
允许您更改模板的辅助函数,而无需使用这些模板重新编译所有代码。它会让我们摆脱所有detail
名称空间:
namespace detail { // actually we don't want this public, but can't avoid it
template<typename T>
void f_helper() { /*---*/ }
}
template<typename T>
void f() {detail::f_helper();}
void g() {f<int>();} // has to recompile if f_helper()'s implementation changes
唉,因为在过去十年中我只使用过一个编译器,所以我永远不会使用它。
答案 4 :(得分:1)
我认为这两个动作都很好,也不会给我带来任何痛苦,我喜欢澄清与noexcept
有关的意图。
答案 5 :(得分:1)
任何认为noexcept是个好主意的人都需要阅读这个3部分系列。这是第3部分,结论:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=483
答案 6 :(得分:0)
我想现在任何支持它们的编译器都会继续支持它们作为可选扩展在可预见的未来,以便人们仍然可以编译它们现有的代码。