【问题标题】:How to store dynamically loaded files as class member - pointer, non-pointer member, in vector?如何将动态加载的文件存储为类成员 - 指针,非指针成员,向量中?
【发布时间】:2014-08-01 20:20:59
【问题描述】:

编辑:一些变化,因为我认为存在一些误解。

假设我有一个 MainWindow 类作为我的程序 gui 的一部分。通过FileChooser 对话框,我想将图像文件加载到我的程序中。目前,我得到了所选文件的文件名,构造了一个 Image 对象,它隐藏了加载逻辑并希望将其存储为我的 MainWindow 类的一部分。我的问题是,您将如何存储该对象。我知道同时只有一个加载的图像,所以像std::vector 这样的容器格式的使用对我来说似乎不是很有用。

我的想法是:

- 使用非指针成员。但这很困难,因为我无法在 MainWindow 类的构造时构造 Image 对象。

-使用unique_ptr,因为我会说MainWindow 获得所有权时没问题,但我不确定当我必须传递指针时这是否非常有用(到可以显示的对象\小部件数据集的一些特定内容)。

-在这种情况下使用shared_ptr 以允许子小部件存储自己的指向Image 对象的指针

我知道这是一个“愚蠢”的问题,但我目前没有好主意。

【问题讨论】:

  • 如果您需要共享数据集引用,那么您必须使用shared_ptrunique_ptr 只有在对对象有单个引用时才有帮助。我没有得到带有矢量的部分,但你也可以有一个vector<shared_ptr<dataset>>
  • 数据集不应是 GUI 对象的成员。您的 GUI 应该与实际执行工作的代码分开。
  • 大多数类都有一个默认构造函数,你通常可以想办法知道它是否被初始化。你的Image 班级不是这样吗?

标签: c++ c++11 shared-ptr member unique-ptr


【解决方案1】:

存储文件的规范方法是std::vector<uint8_t>

如果您的程序一次在单个数据集上运行就足够了。

在构建 MainWindow 类之后,向量将是空的,直到您决定加载文件(我认为这就是您想要表达的意思 普通成员对我来说似乎很难) .

如果可以将多个数据集加载到您的程序中,您可以使用std::vector<std::vector<uint8_t>>

由于std::vector 已经为您提供了您需要的大部分功能(例如存储缓冲区大小、简单调整大小等),因此我不建议您使用其中一种智能指针来执行您正在做的事情。

更新后编辑

既然你已经有一个 Image 类对你隐藏缓冲区,std::vector<uint8_t> 当然没有任何意义。在这种情况下,真正的智能指针之一将是您的最佳选择。你选择哪一个取决于以下几点:

如果您的函数采用std::shared_ptr<Image>,则将您的Image 存储为std::shared_ptr<Image> 是有意义的。

如果您的函数采用Image*Image const*,您仍然可以使用std::shared<Image>,但std::unique_ptr<Image> 也可以,因为您可以通过调用std::unique_ptr::get() 获得指向对象的原始指针。 所以使用std::unique_ptr 不会阻止你传递你的Image。您只需要确保在仍有对它的引用时不会释放该对象。这应该不是问题,因为您将它存储在主应用程序类中。

【讨论】:

  • 最后一段没有意义。您正在将苹果与橙子进行比较。如果场合需要,将unique_ptr 发送到矢量有什么问题?
  • 我澄清了我想说的话。智能指针没有任何问题,我喜欢它们 ;)
  • 所以你会说即使同时只有一个对象也可以使用容器格式?我有一个(可能是错误的)想法,这不是很有效(另外,因为在简单的情况下必须使用不必要的容器接口)。
  • @Meiner 即使只有一个对象也使用容器格式是什么意思?关于标准容器,唯一“效率不高”的是它们是动态分配的,但是如果您不想受限于某些静态定义的限制,无论如何您都必须自己做(在这种情况下,向量将很可能比您的自编码版本更快)。
  • 现在好多了,但它仍然没有意义。存储缓冲区的大小和简单的调整大小完全unique_ptr 给你的东西无关。
猜你喜欢
  • 2018-03-24
  • 2015-02-15
  • 1970-01-01
  • 1970-01-01
  • 2010-11-02
  • 2021-12-22
  • 1970-01-01
  • 1970-01-01
  • 2013-05-02
相关资源
最近更新 更多