gpt4 book ai didi

c++ - 是否有合法的方式从 gsl::not_null 转移?

转载 作者:太空宇宙 更新时间:2023-11-04 13:20:39 29 4
gpt4 key购买 nike

Guidelines Support Library介绍not_null<T>谁的目的是在类似指针的类型上强制执行不变量,有意地在智能指针上。然而it's a known issuenot_null<unique_ptr<T>>不起作用。

据我所知,原因是 unique_ptr<T>不可复制构造并且not_null<T>没有可以从其 T 移动的构造函数。 not_null<T>也不是默认构造的,因为它会破坏它的不变性。即使我们可以构建not_null<unique_ptr<T>> , 不可能有意义地到达 unique_ptr里面因为我们无法复制unique_ptr移动它会留下 not_null<T>与 nullptr。它看起来像一个完美的陷阱。

我认为我们可以合法地从 not_null<T> 移动特定上下文中的对象:就在它超出范围之前。换句话说,从中移动应该是销毁前的最后访问。这样,程序的其余部分将无法观察到不变量损坏的对象。 (只有 not_null 自己的代码才能观察到。)

在下面的示例中,我们假设我们可以从 not_null<T> 移动.

not_null<unique_ptr<int>> f()
{
return make_unique<int>(1);
}

void g(not_null<unique_ptr<int>> p)
{
...
}

void h()
{
auto p = f();
g(make_unique<int>(2));
}
  1. 我的假设是否正确 not_null<unique_ptr<int>> 的状态从 f() 返回后在从中移动后不会泄漏(仅作为示例)?

  2. 我的假设是否正确 not_null<unique_ptr<int>> 的状态传递给 g() 在从它移动后不会泄漏(仅作为示例)?

  3. 在 C++14/17 中是否可以允许这种特殊类型的移动,同时禁止常见的移动情况?

最佳答案

1&2:忽略省略会使问题在任何值得使用的编译器上都没有实际意义的事实,是的。还忽略了 unique_ptr 不能“泄漏”这一事实。

3:没有

这一直是 ISO C++ 提案邮件列表中一些争论的主题。一般概念是“破坏性移动”,其中从对象移动和销毁它的行为是在同一个调用中执行的。但这必须是一种语言特性;在 C++14 中没有办法判断移动构造函数/赋值是否被调用,从而给定对象肯定会被销毁。

关于c++ - 是否有合法的方式从 gsl::not_null<T> 转移?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/35420704/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com