记忆分配的噩梦 [英] memory allocation nightmare
问题描述
我正在尝试开发一个用于建模来自
Bezier补丁的3D对象的应用程序，但我有内存分配问题。这是我的
结构：
typedef struct _vector3 {
union
{
struct
{
浮动x，y，z;
};
浮动v [3];
};
} vector3;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r，g，b;
} vertex;
typedef struct _tri {
顶点顶点[3];
vector3 normal;
} tri;
typedef struct _patch {
vector3 matrix_cp [4] [4]; //补丁的16个控制点
vertex patch_vertices [POINTS_ON_CURVE] [POINTS_ON_CURVE]; //补丁的
顶点列表
tri * elmt; //补丁的三角形列表
int triCount; //补丁上的三角形数
}补丁;
这是我用来为elmt分配内存的行：
g_myPatch-> elmt = malloc（（（POINTS_ON_CURVE - 1）*（POINTS_ON_CURVE -
1）* 2）* sizeof（tri））;
POINTS_ON_CURVE最多30个，程序运行正常，但超出这个
值，它会在上面的行中崩溃。我想知道它是否与尴尬的属性相关
vertex patch_vertices [POINTS_ON_CURVE] [POINTS_ON_CURVE];补丁
结构。但我需要一个2D阵列，所以我无法避免它。
有谁知道这个问题来自哪里？
Thx
Sam
Hi,
I''m trying to develop an application for modeling 3D objects from
Bezier patches, but I have a memory allocation problem. Here are my
structures:
typedef struct _vector3 {
union
{
struct
{
float x, y, z;
};
float v[3];
};
}vector3;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;
typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;
typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;
Here is the line I use to allocate the memory for elmt:
g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));
Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can''t avoid it.
Does anybody know where does this problem come from ?
Thx
Sam
推荐答案
" berthelot samuel" < SA ************** @ voila.fr>在消息中写道
"berthelot samuel" <sa**************@voila.fr> wrote in message
这是我用来为elmt分配内存的行：
g_myPatch-> elmt = malloc（（（POINTS_ON_CURVE - 1） *
（POINTS_ON_CURVE -1）* 2）* sizeof（tri））;
POINTS_ON_CURVE最多30个程序正常，但是>超过这个
值，它在上面的行崩溃了。我想知道它是否与尴尬的属性有关
顶点patch_vertices [POINTS_ON_CURVE]
[POINTS_ON_CURVE];补丁的结构。但是我需要一个2D数组，所以我无法避免它。
有谁知道这个问题来自哪里？
Here is the line I use to allocate the memory for elmt:
g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) *
(POINTS_ON_CURVE -1) * 2) * sizeof(tri));
Up to 30 for POINTS_ON_CURVE the program works fine, but > beyond this value, it crashes at the line above. I wonder if it could be related to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE]
[POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can''t avoid it.
Does anybody know where does this problem come from ?
我认为POINTS_ON_CURVE是一个常数。对malloc（）的调用不应该崩溃
（尽管它可能返回0），所以如果它发生则表示内存损坏。
分配一个数组（N -1）*（N-1）* 2只是在你的代码中某处要求一个边界超限
错误。我会暂时改为N * N * 2和
看看崩溃是否消失，可能会被不正确的结果所取代。
然后你需要浏览代码寻找错误，记住
您已将数组大小减少了与POINTS_ON_CURVE的正方形成比例的数量
。
另一件事检查是否你没有在
堆栈上放置任何结构。一个30 * 30的数组是900个元素，对于许多平台来说太大了，无法处理
。
I presume POINTS_ON_CURVE is a constant. A call to malloc() shouldn''t crash
(though it may return 0), so if it does it indicates memory corruption.
Allocating an array of (N-1) * (N-1) * 2 is just asking for a bounds overrun
error somewhere in your code. I would change temporarily to N * N * 2 and
see if the crash goes away, probably to be replaced by incorrect results.
Then you need to trawl through the code looking for the error, remembering
that you have reduced the array size by an amount proportional to the square
of POINTS_ON_CURVE.
The other thing to check is that you haven''t put any structures on the
stack. An array of 30*30 is 900 elements, too big for many platforms to
handle.
在文章< news：ca ** ************************@posting.google。 com>
berthelot samuel< sa ************** @ voila.fr>写道：
In article <news:ca**************************@posting.google. com>
berthelot samuel <sa**************@voila.fr> writes:
typedef struct _vector3 {
以下划线开头的名称，嗯，iffy最好。你可以在某些范围内使用一些，但其他人总是保留，并且
没有理由写_vector3。这里。结构标签名称
住在一个单独的名称空间，所以可以写：
typedef struct SS;
struct S {...};
（假设您确实想首先使用typedef;
请参阅我之前关于此主题的任何帖子更多细节）。
完成后，让我继续讨论
" struct _vector3 {"：
union
{
struct
浮动x，y，z;
};
浮动v [3];
};
}
这里的结构不包含任何成员，但声明了一个没有标记的工会
。该联合包含一个名为v的成员，其中
是一个大小为3的元素类型float的数组，并且还声明了
另一个没有结构的结构标签。
这些在C中是不合法的。（它们是有效的GNUC和Plan-9-C
结构，但这些编译器都没有定义标准C
语言。我碰巧认为他们*应该*已经被付入了
C99，但显然他们不是，所以我认为不是真的
相关。:-)）
要在标准C中重写此内容，请清除小狗名称，例如
" _vector3"，以及保持typedef但是为人为因素标记
的原因，你可能会使用这样的东西：
typedef struct vector3 VECTOR3;
struct vector3 {
union {
struct {
float x，y，z;
} s;
float v [3];
} u;
};
Of当然，现在为了访问v数组或s struct member
一个struct vector3对象的
，你必须写出中间的
名字：
VECTOR3 vec;
...
vec.uv [i] = some_value;
...
vec.usz = some_value ;
...
最后，我应该注意到 - 虽然它很可能适用于
大多数系统 - 仅限C标准*保证*如果您通过vec.us，
存储它们并从vec检索内容，您可以从vec.us中检索
。 uv如果你已经存储过这种方式。
你也可以提出一个技术论证，即vec.uv [0]和vec.usx
必须是同一个对象，因此可以交叉访问
，但是编译器可以自由地假装结构
已被编写为，例如：
struct {
浮动x;
浮动pad1;
浮动y;
浮动pad2 ;
浮动z;
浮动pad3;
}
换句话说，编译器可能会在x，y，
和z成员之间插入填充，以便v [ ]数组 - *不得*包含
内部填充 - 不覆盖所有三个结构
成员。 （我知道没有任何令人讨厌的编译器对程序员来说这很麻烦，但标准允许它。）
因此可能是明智的避免整个联合技巧，并且
只使用大小为3的数组作为结构的唯一元素。
然后你可以#define数组中的索引表示X，Y，
和Z轴：
typedef struct vector3 VECTOR3;
struct vector3 {
float v [3];
};
#define VEC3_X 0
#define VEC3_Y 1
#define VEC3_Z 2
...
VECTOR3 vec;
...
vec.v [VEC3_X] = x_value;
vec.v [VEC3_Y] = y_value;
vec.v [VEC3_Z] = z_value;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r，g，b;
} vertex;
typedef struct _tri {
顶点顶点[3];
vector3 normal;
} tri;
再次，我建议避免使用前导下划线。
typedef struct _patch {
vector3 matrix_cp [4] [4]; //补丁的16个控制点
顶点patch_vertices [POINTS_ON_CURVE] [POINTS_ON_CURVE]; //补丁的顶点列表
请注意，您的新闻软件已将您的评论分成两行，
以便它现在是语法错误。这是C99的一个问题
" //评论。
tri * elmt; //补丁的三角形列表
int triCount; //补丁上的三角形数量
}补丁;
这是我用来为elmt分配内存的行：
g_myPatch-> elmt = malloc（（（POINTS_ON_CURVE - 1）*（POINTS_ON_CURVE -
1）* 2）* sizeof（tri））;
此调用看起来没问题，前提是POINTS_ON_CURVE至少为2，尽管你可能想要使用comp.lang.c tested"变体：
g_myPatch-> elmt = malloc（n * sizeof * g_myPatch-> elmt）;
（这里的n是比POINTS_ON_CURVE少一个的平方的两倍，
如上所述。
POINTS_ON_CURVE最多30个程序工作正常，但超出此值，它会崩溃在上面的行。我想知道它是否与尴尬的属性相关
顶点patch_vertices [POINTS_ON_CURVE] [POINTS_ON_CURVE];补丁的结构。但我需要一个2D阵列，所以我无法避免它。
有谁知道这个问题来自哪里？
typedef struct _vector3 {
Names beginning with underscores are, well, "iffy" at best. You
can use some in some scopes, but others are always reserved, and
there is no reason to write "_vector3" here. Structure tag names
live in a separate name space, so it is OK to write:
typedef struct S S;
struct S { ... };
(assuming you really want to use the typedefs in the first place;
see any of my earlier postings on the subject for more details).
With that out of the way, let me move on to the contents of
"struct _vector3 {":
union
{
struct
{
float x, y, z;
};
float v[3];
};
}
Here the structure contains no members, but does declare a union
that has no tag. That union contains one member named "v", which
is an array of size 3 of element-type "float", and also declares
another struct with no tag.
These are not legal in C. (They are valid GNUC and Plan-9-C
constructs, but neither of those compilers defines the Standard C
language. I happen to think they *ought* to have been put into
C99, but apparently they were not, so what I think is not really
relevant. :-) )
To rewrite this in Standard C, steering clear of dogdy names like
"_vector3", and to keep the typedef but mark it for human-factors
reasons, you might use something like this:
typedef struct vector3 VECTOR3;
struct vector3 {
union {
struct {
float x, y, z;
} s;
float v[3];
} u;
};
Of course, now in order to access the "v" array or "s" struct member
of a struct vector3 object, you have to write out the intermediate
names:
VECTOR3 vec;
...
vec.u.v[i] = some_value;
...
vec.u.s.z = some_value;
...
Finally, I should note here that -- while it is likely to work on
most systems -- the C Standards only *guarantee* that you can
retrieve things from vec.u.s if you have stored them via vec.u.s,
and retrieve things from vec.u.v if you have stored them that way.
One can also make a technical argument that vec.u.v[0] and vec.u.s.x
must necessarily be the same object, and thus be cross-accessible
as it were, but a compiler is free to pretend that the structure
had been written as, e.g.:
struct {
float x;
float pad1;
float y;
float pad2;
float z;
float pad3;
}
In other words, a compiler might insert padding between the x, y,
and z members, so that the v[] array -- which *must not* contain
internal padding -- does not overlay all three of the structure
members. (I know of no compilers that are annoying enough to do
this to the programmer, but the Standard permits it.)
It might therefore be wise to avoid the entire union trick, and
just use an array of size 3 as the only element of the structure.
You can then "#define" indices into the array to denote the X, Y,
and Z axes:
typedef struct vector3 VECTOR3;
struct vector3 {
float v[3];
};
#define VEC3_X 0
#define VEC3_Y 1
#define VEC3_Z 2
...
VECTOR3 vec;
...
vec.v[VEC3_X] = x_value;
vec.v[VEC3_Y] = y_value;
vec.v[VEC3_Z] = z_value;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;
typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;
Again, I would recommend avoiding the leading underscores.
typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
Note that your news software has split your comment into two lines,
so that it is now a syntax error. This is one problem with C99''s
"//" comments.
tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;
Here is the line I use to allocate the memory for elmt:
g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));
This call looks OK, provided POINTS_ON_CURVE is at least 2, although
you might want to use the "comp.lang.c tested" variant:
g_myPatch->elmt = malloc(n * sizeof *g_myPatch->elmt);
(where n here is twice the square of one less than POINTS_ON_CURVE,
as above).
Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can''t avoid it.
Does anybody know where does this problem come from ?
正如Malcolm建议的那样，你可能会遇到堆栈
限制 - 31 * 31是961，而顶点是由两个vector3s
和三个float组成。 漂浮通常是四个字节，并且
" vector3"通常是12或16字节，所以通常的情况是
2 * 12 + 3 * 4 = 24 + 12 = 36，或者2 * 16 + 3 * 4 = 32 + 12
= 44个字节。
" b"后面还可能有四个字节的填充。 顶点的成员，将这些数字分别提高到40和48字节
。如果这些顶点中有961个。数组元素
在补丁中，每个都是48个字节，需要46128个字节
仅适用于patch_vertices成员。
-
In-Real-Life：风河系统Chris Torek
美国犹他州盐湖城（40°39.22''N，111°50.29'' W）+1 801 277 2603
电子邮件：忘了它 http://web.torek.net/torek/index.html
由于垃圾邮件发送者，阅读电子邮件就像在垃圾中搜索食物一样。
As Malcolm suggested elsethread, you might be running into stack
limits -- 31*31 is 961, and a "vertex" consists of two "vector3"s
and three "float"s. A "float" is typically four bytes, and a
"vector3" will typically be 12 or 16 bytes, so the usual case is
either 2*12 + 3*4 = 24 + 12 = 36, or perhaps 2*16 + 3*4 = 32 + 12
= 44 bytes. There may also be four bytes of padding following the
"b" member of a "vertex", raising these numbers to 40 and 48 bytes
respectively. If there are 961 of these "vertex" array elements
in a "patch", and each one is 48 bytes, that requires 46128 bytes
just for the patch_vertices member.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22''N, 111°50.29''W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
你好Chris，
感谢您的相关建议。
看来我的结构确实使用了大量的内存。但是我能做些什么才能克服这个问题呢？我现在不能真正改变我的结构......
有没有人有天才的想法？
欢呼，
Sam
Chris Torek< no **** @ torek.net>在消息新闻中写道：< c5 ********* @ news4.newsguy.com> ...
Hi Chris,
Thank you for your relevant advice.
It seems that my structure uses a lot of memory indeed. But what can I
do to overcome this ? I can''t really change my structures now...
Has anyone got a genius idea ?
cheers,
Sam
Chris Torek <no****@torek.net> wrote in message news:<c5*********@news4.newsguy.com>...
在文章< news：ca ******** ******************@posting.google。 com>
berthelot samuel< sa ************** @ voila.fr>写道：
In article <news:ca**************************@posting.google. com>
berthelot samuel <sa**************@voila.fr> writes:
typedef struct _vector3 {
typedef struct _vector3 {
以下划线开头的名称，嗯，iffy最好。你可以在某些范围内使用某些，但其他人总是保留，并且
没有理由写_vector3。这里。结构标签名称
生活在一个单独的名称空间中，所以可以写：
typedef struct SS;
struct S {...};
（假设你真的想首先使用typedef;
看看我之前关于这个主题的任何帖子了解更多细节）。
有了这个，让我继续介绍
struct _vector3 {"：
Names beginning with underscores are, well, "iffy" at best. You
can use some in some scopes, but others are always reserved, and
there is no reason to write "_vector3" here. Structure tag names
live in a separate name space, so it is OK to write:
typedef struct S S;
struct S { ... };
(assuming you really want to use the typedefs in the first place;
see any of my earlier postings on the subject for more details).
With that out of the way, let me move on to the contents of
"struct _vector3 {":
union
{
struct
{
float x，y，z;
};
float v [3];
};
}
union
{
struct
{
float x, y, z;
};
float v[3];
};
}
这里结构不包含任何成员，但确实声明了没有标记的联合。该联合包含一个名为v的成员，其中
是元素类型为float的大小为3的数组，并且还声明了另一个没有标记的结构。
要在标准C中重写，转向清晰像
_vector3这样的小狗名字，为了保持typedef但是为了人类因素原因而标记它，你可能会使用这样的东西：
typedef struct vector3 VECTOR3 ;
struct vector3 {
结构{
浮动x，y，z;
} s;
浮动v [3];
VECTOR3 vec;
...
vec.uv [i] = some_value;
...
vec.usz = some_value;
...
最后，我应该注意到 - 虽然它是可能适用于大多数系统 - 仅C标准*保证*如果您通过vec.us，
存储它们并从中检索东西，您可以从vec.us检索内容vec.uv如果你以这种方式存储它们。
还可以提出一个技术论证，即vec.uv [0]和vec.usx
必须是同一个对象，因此是交叉可访问的
虽然如此，但是编译器可以自由地假装结构已经被编写为，例如：
struct {
float x;
float pad1;
float y;
float pad2;
float z;
float pad3;
}
内部填充 - 不覆盖所有三个结构
成员。 （我知道没有任何令人烦恼的编译器对程序员来说这很麻烦，但标准允许它。）
因此，避免整个联合技巧可能是明智的，并且<只需使用大小为3的数组作为结构的唯一元素。
然后你可以#define数组中的索引表示X，Y，
和Z轴：
typedef struct vector3 VECTOR3;
struct vector3 {
float v [3];
};
#define VEC3_X 0
#define VEC3_Y 1
#define VEC3_Z 2
...
VECTOR3 vec;
...
vec.v [VEC3_X] = x_value;
vec.v [VEC3_Y] = y_value;
vec.v [VEC3_Z] = z_value;
Here the structure contains no members, but does declare a union
that has no tag. That union contains one member named "v", which
is an array of size 3 of element-type "float", and also declares
another struct with no tag.
These are not legal in C. (They are valid GNUC and Plan-9-C
constructs, but neither of those compilers defines the Standard C
language. I happen to think they *ought* to have been put into
C99, but apparently they were not, so what I think is not really
relevant. :-) )
To rewrite this in Standard C, steering clear of dogdy names like
"_vector3", and to keep the typedef but mark it for human-factors
reasons, you might use something like this:
typedef struct vector3 VECTOR3;
struct vector3 {
union {
struct {
float x, y, z;
} s;
float v[3];
} u;
};
Of course, now in order to access the "v" array or "s" struct member
of a struct vector3 object, you have to write out the intermediate
names:
VECTOR3 vec;
...
vec.u.v[i] = some_value;
...
vec.u.s.z = some_value;
...
Finally, I should note here that -- while it is likely to work on
most systems -- the C Standards only *guarantee* that you can
retrieve things from vec.u.s if you have stored them via vec.u.s,
and retrieve things from vec.u.v if you have stored them that way.
One can also make a technical argument that vec.u.v[0] and vec.u.s.x
must necessarily be the same object, and thus be cross-accessible
as it were, but a compiler is free to pretend that the structure
had been written as, e.g.:
struct {
float x;
float pad1;
float y;
float pad2;
float z;
float pad3;
}
In other words, a compiler might insert padding between the x, y,
and z members, so that the v[] array -- which *must not* contain
internal padding -- does not overlay all three of the structure
members. (I know of no compilers that are annoying enough to do
this to the programmer, but the Standard permits it.)
It might therefore be wise to avoid the entire union trick, and
just use an array of size 3 as the only element of the structure.
You can then "#define" indices into the array to denote the X, Y,
and Z axes:
typedef struct vector3 VECTOR3;
struct vector3 {
float v[3];
};
#define VEC3_X 0
#define VEC3_Y 1
#define VEC3_Z 2
...
VECTOR3 vec;
...
vec.v[VEC3_X] = x_value;
vec.v[VEC3_Y] = y_value;
vec.v[VEC3_Z] = z_value;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r，g，b;
} vertex;
typedef struct _tri {
顶点顶点[3];
vector3 normal;
} tri;
typedef struct _vertex {
vector3 pos;
vector3 normal;
float r, g, b;
}vertex;
typedef struct _tri {
vertex vertices[3];
vector3 normal;
}tri;
同样，我建议避免使用前导下划线。
Again, I would recommend avoiding the leading underscores.
typedef struct _patch {
vector3 matrix_cp [4] [4]; //补丁的16个控制点
顶点patch_vertices [POINTS_ON_CURVE] [POINTS_ON_CURVE]; //补丁的顶点列表
typedef struct _patch {
vector3 matrix_cp[4][4]; //16 control points of the patch
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; //list of
vertices of the patch
请注意，您的新闻软件已将您的评论分成两行，
以便现在出现语法错误。这是C99的一个问题
" //评论。
Note that your news software has split your comment into two lines,
so that it is now a syntax error. This is one problem with C99''s
"//" comments.
tri * elmt; //补丁的三角形列表
int triCount; //补丁上的三角形数量
}补丁;
这是我用来为elmt分配内存的行：
g_myPatch-> elmt = malloc（（（POINTS_ON_CURVE - 1）*（POINTS_ON_CURVE -
1）* 2）* sizeof（tri））;
tri* elmt; //list of triangles of the patch
int triCount; //number of triangles on the patch
}patch;
Here is the line I use to allocate the memory for elmt:
g_myPatch->elmt = malloc(((POINTS_ON_CURVE - 1) * (POINTS_ON_CURVE -
1) * 2) * sizeof(tri));
此调用看起来没问题，前提是POINTS_ON_CURVE至少2，虽然
你可能想要使用comp.lang.c tests变体：
g_myPatch-> elmt = malloc（n * sizeof * g_myPatch-> elmt）;
（其中n是两倍于POINTS_ON_CURVE的平方的两倍，
如上所述。
This call looks OK, provided POINTS_ON_CURVE is at least 2, although
you might want to use the "comp.lang.c tested" variant:
g_myPatch->elmt = malloc(n * sizeof *g_myPatch->elmt);
(where n here is twice the square of one less than POINTS_ON_CURVE,
as above).
POINTS_ON_CURVE最多30个程序正常工作，但超出此值，它会在上面的行中崩溃。我想知道它是否与尴尬的属性相关
顶点patch_vertices [POINTS_ON_CURVE] [POINTS_ON_CURVE];补丁的结构。但我需要一个2D数组，所以我无法避免它。
有谁知道这个问题来自哪里？
Up to 30 for POINTS_ON_CURVE the program works fine, but beyond this
value, it crashes at the line above. I wonder if it could be related
to the awkward attribute
vertex patch_vertices[POINTS_ON_CURVE][POINTS_ON_CURVE]; of the patch
structure. But I need a 2D array, so I can''t avoid it.
Does anybody know where does this problem come from ?
正如Malcolm建议的那样，你可能会遇到堆栈
限制 - 31 * 31是961，并且顶点是由两个vector3和三个float组成。 漂浮通常是四个字节，并且
vector3通常是四个字节。通常是12或16字节，所以通常的情况是2 * 12 + 3 * 4 = 24 + 12 = 36，或者2 * 16 + 3 * 4 = 32 + 12
= 44个字节。在
b之后还可能有四个字节的填充。 顶点的成员，分别将这些数字提高到40和48字节。如果这些顶点中有961个。数组元素
在补丁中，每个都是48个字节，仅需要为patch_vertices成员提供46128个字节。
As Malcolm suggested elsethread, you might be running into stack
limits -- 31*31 is 961, and a "vertex" consists of two "vector3"s
and three "float"s. A "float" is typically four bytes, and a
"vector3" will typically be 12 or 16 bytes, so the usual case is
either 2*12 + 3*4 = 24 + 12 = 36, or perhaps 2*16 + 3*4 = 32 + 12
= 44 bytes. There may also be four bytes of padding following the
"b" member of a "vertex", raising these numbers to 40 and 48 bytes
respectively. If there are 961 of these "vertex" array elements
in a "patch", and each one is 48 bytes, that requires 46128 bytes
just for the patch_vertices member.
这篇关于记忆分配的噩梦的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
