Stephan T Lavavej最初对make_unique的建议是N3588
它包括以下功能:
make_unique<T>(args...)
make_unique_default_init<T>()
make_unique<T[]>(n)
make_unique_default_init<T[]>(n)
make_unique_value_init<T[]>(n, args...)
make_unique_auto_size<T[]>(args...)
但是，最后的提案N3656仅包含
make_unique(两种形式)。我找不到有关该函数其他形式的任何讨论。我读了the minutes of the Bristol meeting，但他们甚至都没有引用原始建议。为什么这些额外功能未包含在最终草案中？
最佳答案
分钟是准确的。整个委员会没有讨论过N3588(原始配方，不带Standardese)，仅在那里讨论了N3656(特脆，带Standardese)。如果您没有参加过 session ，这似乎很奇怪，但是会发生的情况是工作组(核心，演进，图书馆，图书馆演进)和研究组(文件系统等)在一周中并行工作，最终进行民意测验(任何人都可以投票)，以确定应向正式委员会提出的内容。在第二天至最后一天，全体委员会(100多人)开会，简要讨论了正式动议，并进行了草率投票(只有投票成员可以投票)。如果有人担心功能不够完善，或者与其他功能存在集成问题等，则在此处进行讨论-但是整个委员会不会研究提案的微观细节。基本上，如果有争议的事情足以保证这一点，那么它无论如何也无法幸免，因此将其从该 session 的审议中撤回。然后在最后一天，全体委员会再次开会，并进行了真正的投票(仅投票成员)。通常，在实际投票期间应该没有任何意外，因为前一天是试运行。
LWG分钟未公开，但是我可以告诉您发生了什么。 N3588故意不包含Standardese-我在那做的是探索设计空间，弄清楚我们应该模仿哪些新表现形式，并主张或反对各种事物。我打算从LWG收到反馈，然后为下次 session (芝加哥)起草Standardese，因为编写任何复杂的文件都花了我很多时间才能完全正确(这比实际实现要花更多的时间，因为Standardese会认真地跳舞有关实现细节，例如SFINAE)。在介绍该提案时，我解释了我如何不是default-init的忠实拥护者(我将其称为垃圾初始化)，但概述了无论如何都可以完成。我还解释说，自编写建议以来(在收到MS开发人员的反馈的同时)，我已经了解了更多有关array-init案例的信息。有趣的是，核心语言为括号初始列表提供了排序保证，因此新的X [3] {f()，g()，h()}从左到右调用这些函数。函数调用没有得到那些保证，(在我看来)这些保证会像我最初的建议中那样包装array-init造成致命的伤害。有一些巧妙的方法可以实现序列保证，而用户语法略有不同，实现复杂性更高，我向LWG解释了这一点。在这一点上，我真的很想删除array-init，我对default-init(这很容易指定和实现，但我认为基本上没有必要)不满意。 LWG的 react 是他们只需要最简单的形式-不需要array-init，甚至不需要default-init。我很高兴听到这一消息，并且能够在 session 本身(例如凌晨4点)写下必要的Standardese。这就是N3656的来源。 LWG进行了另一番调整，并进行了一些细微的调整(将make_unique 的返回类型从void更改为unspecified，这是我在“固定”之前所做的)，可以将其带到全体委员会。
然后，正如您在几分钟内看到的那样，您担心的是，使用make_unique可能会使我们步伐太快。 N3588在 session 前准时寄出，但这是它第一次出现-几乎所有的提议都需要一次以上的 session 才能从首次出现转变为正式动议(我的第一个提议是透明的运算符，是这是一个更不寻常的异常(exception)，因为它的出现并在波特兰进行了投票，但没有发生变化。顺便说一下，这是一个完全有效的担忧。最后，表决通过了-成员不必解释其表决，但我的感觉是，这是很小的提议，没有人反对实际内容和可用的实现的结合。
现在，对于make_shared，我将不得不再次考虑所有这些东西!
关于c++ - make_unique数组，原始提案与最终提案，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/16755415/