C++ arrays in classes... strange bug...

[JP]

I've got a strange problem with putting some of my arrays into a class.

If i have this, original, setup:

Code: Select all

Game.pp:
-----------

#define W 12
#define H 10

pvert_type pvertArr[W*H];
unsigned int intArr[W*H*6];

gfx.h:
------

struct pvert_type {
  float x,y,z;
};

And i pass those arrays to a shader everything works fine, rendered properly.

If i then do this:

Code: Select all

Object.h:
----------

#define W 12
#define H 10

class Object {
  private:
    pvert_type pvertArr[W*H];
    unsigned int intArr[W*H*6];
    
};

gfx.h:
------
struct pvert_type {
  float x,y,z;
};

Then when i pass the arrays to the same shader in Object::render() it crashes... The arrays are definetly valid as i can do whatever i want with them in the class; changing their values and everything but it just crashes when i try to render them in the shader... I also tried changing it to dynamic allocation with pointers it still doesn't work...

I've made multiple attempts to get this sort of thing working but it just doesn't want to...

I guess i'm missing out some really basic thing to do with arrays in C/C++ but i really can't figure it out!

[rogerborg]

Your code is ugly, and the compiler is punishing you for it.

Why are the data private?

[pippy]

Code: Select all

Object.h:
----------

#define W 12
#define H 10

class Object {
  private:
    pvert_type pvertArr[W*H];
    unsigned int intArr[W*H*6];
   
};

gfx.h:
------
struct pvert_type {
  float x,y,z;
}; 

make sure that Object #includes "gfx.h". A good idea would be to use the same namespace uses similar features so there is no confusion:

Object.h:
----------

Code: Select all

#define W 12
#define H 10

namespace objects{
  struct pvert_type {
    float x,y,z;
  }; 
  class Object {
    private:
      pvert_type pvertArr[W*H];
      unsigned int intArr[W*H*6];
  };
}

You're probably trying to obtain pvertArr without a accessor (a method that returns a private value). It's good that your using private properties

[JP]

Of course gfx.h is included, otherwise it wouldn't compile I just left it out from lazyness!

I'll try out your theory of it being private...

Rogerborg, how's it ugly?

And of course the arrays should be private... if they were public then they could be changed from outside the class which really shouldn't be allowed....

[JP]

Making the arrays public didn't seem to help at all...

[bitplane]

your struct is 12 bytes long, is pragma pack set to 8 or something in gfx.h? try setting it to 1 byte-

Code: Select all

#pragma pack(1)

[rogerborg]

I didn't think it would, I was just making conversation to cover up the fact that I don't have a clue what's going on.

It certainly looks fine, so unless the data are being destroyed before they're used in the shader, I can't see what's going on. You're not passing references to out-of-scope objects around, by any chance?

[JP]

It's not out of scope, it works if i substitute in a simple quad instead of the grid arrays. The simple quad is defined in gfx.h and not in a class so i guess that's sort of why it works, seems like it's certainly something to do with the class.

Bitplane, i don't have the pack pragma at all, but as it works if the arrays are not in a class then surely it's not a problem with packing?

[bitplane]

The only other thing I can think of is that it's something to do with where the memory is located, is there a DLL boundary involved? Some crazy compiler flags perhaps?
My money is on Vitek, he's bound to know the answer

[JP]

There's no DLL's at all in the project, could be a compiler flag i guess... But... I think i've got smaller arrays working in this fashion...

When passed to the shader the shader param is 'const void*' could that be a factor?

[vitek]

I don't see anything wrong with the code. Ideally you wouldn't use macros, and the names of the user defined types are poor [pvert_type, pvertArr and intArr].

I'm not exactly sure how you are using these arrays, but it shouldn't have anything to do with packing. The data in each array should be packed the same regardless of the scope that contains the type declaration. You could check the packing with sizeof(pvert_type), sizeof(pvertArr) and sizeof (intArr) in both cases. They should be consistent.

I'm assuming that you're passing these things to the driver directly using driver specific calls [you are using unsigned int indices which are probably 32-bits].

Anyways, you should probably show us the Object::render() method, or maybe create a simple test to show the problem.

Travis

[JP]

In my defense the pvert_type name was by the guy who did my job before me and i've never got round to changing it and have used a lot of his code in my engine so it stuck, i should change it really, you're right.. And the pvertArr and intArr names were just names i made up for the small example i posted.

The Object::render() method just calls one of my CG shaders, passing the vertices, indices and other parameters to it. Just to reiterate my project isn't using irrlicht but OpenGL, just seems like you thought it was irrlicht from your response!