【问题标题】:problems with operator new when allocating arrays分配数组时运算符 new 的问题
【发布时间】:2009-11-18 15:31:07
【问题描述】:

我的 C++/openGL 程序有问题。

在某些代码点,比如这些(它是一个构造函数):

MyObject(MyMesh * m, MyTexture* t, float *c=NULL, float *sr=NULL, int sh=100){
texture=t;
mesh=m;
subObjects=NULL;
texCoords=NULL;
if (texture!=NULL){
        texCoords=new float[mesh->numSurfacePoints*2];

new 抛出一个 std::bad_alloc 异常。在另一个地方也是一样。 有没有可能,我的内存用完了?我不这么认为,所以如果你能帮助我,我会很高兴! 再见!

【问题讨论】:

  • mesh->numSurfacePoints 的值是多少?
  • 你知道numSurfacePoints有多少个点吗?
  • mesh可以作为null传入吗?
  • 你应该使用std::vector
  • 值为36,网格不为空

标签: c++ arrays new-operator bad-alloc


【解决方案1】:

您还应该检查mesh->numSurfacePoints 的值可能是假的或负的,这也可能是错误的根源。

【讨论】:

  • 没关系。指定问题:我有一个 MyMesh 类,可以镶嵌 N 面锥体和金字塔。它还可以生成空心锥体,在这种情况下,锥体上有一个孔。如果我生成一个空心圆锥体,没关系,即使我使用 20 面圆锥体,但如果我生成一个非空心圆锥体,它会生成 MyMesh,但是当我将它传递给 MyObject 构造函数时,它会抛出错误。
【解决方案2】:

有没有可能是我的内存不够了?

std::bad_alloc 被抛出时你的程序使用了多少内存?

mesh->numSurfacePoints 崩溃时的值是多少?您确定作为mesh 传入的指针是有效指针吗?如果您有一个非常碎片化的地址空间,则可能没有足够的连续空间来分配一个大数组。在抛出std::bad_alloc 之前,您的程序运行了多长时间?

如果您还没有,您应该考虑使用boost::scoped_array 或其他形式的数组智能指针,以便在不再需要堆分配的对象时自动删除。

【讨论】:

  • 不幸的是,这个程序必须在我大学的服务器上运行,所以我不能使用智能指针。 thu numSurfacePoints 是 36,但它运行良好,数字更大(请参阅我对 Steffen 回复的评论)。我如何检查程序在崩溃时使用了多少内存?
  • 这取决于操作系统。但是,您的内存使用量可能会受到该大学服务器上的配额的限制,这可能会导致您用完内存的速度比通常使用完整地址时的速度快得多空间。
【解决方案3】:

实际上,对于现代操作系统,您不太可能耗尽内存。在你这样做之前,机器会频繁更换,以至于它或多或少地无法使用——你不能错过。此外,当我几年前使用 Win2k 进行实验时,我发现当我的测试应用程序分配尽可能多的内存时,几乎每个应用程序都会崩溃。 (包括调试器、办公应用程序、浏览器、电子邮件应用程序,甚至记事本。)

所以我会假设您要么尝试分配不合理的大数量,要么堆变得如此严重以至于无法满足合理的请求。

这样写你的代码怎么样:

// for example
const std::size_t arbitrary_max_size_constant = std::vector<float>::max_size();
// or std::nummeric_traits<std::size_T>.max() / 10; 

if (texture!=NULL){
  assert(mesh->numSurfacePoints < arbitrary_max_size_constant);
  texCoords = new float[mesh->numSurfacePoints*2];
  // ...
}

如果您的程序有错误,这会以调试方式提醒您,但不会减慢发布代码的速度。另一种可能性是您捕获异常并打印程序试图分配的内存:

if (texture!=NULL) {
  try {
    texCoords = new float[mesh->numSurfacePoints*2];
  } catch(const std::bad_alloc& x) {
    std::cerr << "failed to allocate << mesh->numSurfacePoints*2 << " bytes!\n";
    throw;
  }
  // ...
}

这样您还可以查看该值是否大到不合理。如果是,你就有了一个错误,如果不是,你要么内存不足,要么堆太碎片化,无法在这个地方分配程序需要的数量。

【讨论】:

  • 谢谢,但看起来没问题。只尝试分配 36 个浮点数,所以这应该不是问题。如果没有其他猜测,那么我将从一开始就开始调试......呃......祝我好运:)
  • 你是怎么知道这 35 个的?
【解决方案4】:

您是否在某个时候在 texCoords 上调用 delete[] ?看来您的内存肯定用完了。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-08-03
    • 1970-01-01
    • 2015-04-11
    • 1970-01-01
    • 2012-11-29
    • 1970-01-01
    相关资源
    最近更新 更多