creating 3-dimensional array

[nesvarbu]

I need to create a 3-dimensional array points[n][m][l] in c++. This array is used in OpenGL function to draw nurbs:

gluNurbsSurface( GLUnurbsObj *nurb, GLint uKnotCount, GLfloat *uKnot,
GLint vKnotCount, GLfloat *vKnot, GLint uStride,
GLint vStride, GLfloat *points, GLint uOrder,
GLint vOrder, GLenum type );

Ok I tried several ways to create an array:
1. I just used GLfloat points[7][5][4], I it would be ok, BUT I can't use constants, the size of array depends on other variables, so I tried another way:
2.

      
GLfloat ***points;

points = new GLfloat**[UKnotCount - UOrder];
for (int i = 0; i < UKnotCount - UOrder; i++)
{
  points[i] = new GLfloat*[VKnotCount - VOrder];
  for (int j = 0; j < VKnotCount - VOrder; j++)
  {
    points[i][j] = new GLfloat[4];
  }
}

Everything would be OK , BUT when I use this array in OpenGL function

      
gluNurbsSurface( nurbSurface, VKnotCount, VKnots, UKnotCount, UKnots,
              7*4, 4, &points[0][0][0],VOrder,UOrder, GL_MAP2_VERTEX_4 );

It throws an error: "Invalid floating point operation". So I guess this type of array doesn't suit OpenGL function. I don't have much of knowledge in pointers and addresses, so maybe I'm using the pointers incorrect? Or maybe there's another way to create a 3-dimensional array? Any help would be appretiated.

[AssKoala]

Look at what OpenGL asks for:

GLfloat *points

What you're passing it is a GLfloat****, that is the address of a triple pointer.

Now, there's a specific reason as to why it makes absolutely no sense to send a multidimensional array to an OpenGL function. It doesn't know the bounds of the array. If you were to send it that three dimensional array, it wouldn't be able to figure out how to dereference the array properly without passing it a plethora of extra parameters. OpenGL functions already take enough parameters to require pushing them onto the stack, but the fewer the better.

The bluebook has this listed: Click Me!

That should at least be a start on understanding what you need to send that function.

Here's what the bluebook says about that parameter:

Originally Posted by The OpenGL Bluebook v1.0

Specifies an array containing control points for the NURBS surface. The offsets between successive control points in the parametric u and v directions are given by s_stride and t_stride.

[tvqpriqphh]

nesvarbu:
it is true that a three dimensional array is a triple pointer

typeof(points) == GLfloat * * *


however, if you specify array offsets, those pointers get dereferenced

typeof(points[0]) == GLfloat * * (equivalent to *(points+0))

typeof(points[0][0]) == GLfloat * (equivalent to *(*(points+0)+0))

typeof(points[0][0][0]) == GLfloat (equivalent to *(*(*(points+0)+0)+0))

the compiler might be having trouble with the order of operations, perhaps you should try this syntax:

&(points[0][0][0])

now you dereference the triple pointer first and take the address of the result

typeof(&(points[0][0][0])) == GLfloat * (equivalent to &(*(*(*(point+0)+0)+0)))

[AssKoala]

I don't know how far I want to get into this one but tvqpriqphh, I don't know if you've ever programmed OpenGL or even know why what you're doing is such a terrible idea.

What if the three dimensional array was dynamically allocated? It might be a cube structure as an array but there's no guarantee whatsoever that it will be linear in memory. Pass it around by casting and you'll read/write into parts of memory that don't belong to that array. You'll end up crashing or corrupting your own memory.

What you said is correct about how the dereferencing works, but it has no relevance on this question whatsoever. OpenGL requires linear chunks of memory and sending it a 3D array is not the correct way to use it. The compiler is not having any problems in this case, the op's code specifically shows a misunderstanding of the OpenGL function. It is pebkac and what you posted is nowhere near the solution and is just plain bad advice.

By the way, use i, j, and k when making examples on how dereferencing works -- seeing the three 0's is great but the ordering is not understood by the reader.