C++: OpenGL, glm and struct padding

Question

can I safely use the glm::* types (e.g. vec4, mat4) to fill a vertex buffer object ?

std::vector<glm::vec3> vertices;    
glBufferData(GL_ARRAY_BUFFER,  sizeof(glm::vec3) * vertices.size(), &vertices[0], GL_STATIC_DRAW);

I'm not quite sure about that since struct padding (member alignment) could cause some trouble in my opinion, though all compilers I've tested returns the expected sizes.

I'm developing for C++11 Compilers (maybe this make a difference).

Collettecolletti

Answer 1

Define "safe".

C++ gives implementations wide latitude to pad structures as they see fit. So as far as ISO C++ is concerned, whether this "works" is implementation-dependent behavior.

It will work in general across a number of compilers for desktop platforms. I can't speak for ARM CPUs, but generally, glm::vec3 will be 3 floats in size. However, if you want to make sure, you can always perform a simple static_assert:

static_assert(sizeof(glm::vec3) == sizeof(GLfloat) * 3, "Platform doesn't support this directly.");

Linkous

Answer 2

Yes, glm is designed and built specifically for this purpose.

Request

According to the source they are just using structs with 4 floats which isn't safe against struct padding by default. That's why I'm asking this question. – Collettecolletti

Why wouldn't it be safe? The library's entire goal is to perfectly agree with OpenGL and GLSL and it's been achieving this since 2005. – Request

@pwny: The OP has explained why and is correct. Sounds like the library has a major flaw in achieving its goal. – Gower

@Collettecolletti If glm documentation specifies that it's safe then they would need to implement and test it such that it is safe on the implementations they support. There's no reason they couldn't depend on implementation defined behavior to achieve it. – Practical

@bames53: That's not feasible in this case. Alignment could conceivably vary between compiler invocations. You can't just test it once on some platform then put a big green tick next to that platform for this completely unspecified behaviour. – Gower

@LightnessRacesinOrbit The documentation for glm should cover the supported situations. You absolutely can check a compiler's implementation defined, documented behavior and implement a library depending on that documented behavior. – Practical

@LightnessRacesinOrbit The library officially supports a wide range of platforms and compilers. I doubt a project as serious as this one just "tests it once on some platform" and call it a day like you imply. The library works and will not give you problems if you use it on a supported platform with a supported compiler. For all intents and purposes, it has no issues related to struct padding. I don't see what's "unsafe" here. – Request

@pwny: As long as they are not actually instructing the compiler not to pack the struct, this isn't safe no matter how much they think they've tested it. I don't care what it "officially supports". – Gower

@LightnessRacesinOrbit It's not about just being tested. It's about defined, documented, implementation behavior. It's exactly as correct as using some kind of non-standard mechanism such as a pragma to specify how the struct is laid out. – Practical

@bames53: Oh I'd agree if any mainstream toolchain made guarantees about padding. However, at least GCC certainly does not. That's why it provides __attribute__ ((packed)). So, if this library is relying on GCC doing that, then the library is mistaken. – Gower

@LightnessRacesinOrbit It is specified as part of the ABI. GCC, clang, and intel's compiler, for example, all specify their ABIs (and mostly use the Itanium ABI where applicable). I believe that Microsoft does not publicly specify theirs but the basics, such as for simple structs, are pretty well known anyway. – Practical

@bames53: Um, none of the ABIs guarantee packed structs. – Gower

@LightnessRacesinOrbit They guarantee the exact layout of the struct, byte offset of every member, which bits are used for bit fields, where and how much padding there is, etc... – Practical

@bames53: Okay. Perhaps it's more well-defined within a certain ABI than I thought, but I have some questions if that's the case. I have taken them to #13582653. – Gower