Green_Baron, if you have a prefered api for window management I can try swapping over to that.
Perhaps one for matrix and vector math too to minimize the code provided

It should work with any windowing api.

I just realized you overworked the code already. pls. stand by ?

... and i gave up. Sorry. The handling of the vertices isn't that translucent, represented as a classical array, then again a as a vector. If there is a problem with the number of vertices and the buffer bound or not, it is hidden well ?

But the shaders compile without a sound !

I use a std::vector to build the array, then copy it out into a fresh heap allocation and copy it across. Just to eliminate memory shenanigans. Each vertex is a vector3, which is just 3 floats.

I've tried using a hardcoded array, but it crashed with that too.
I've tried using glGetBufferParameteriv to check the vbo and that seems fine. Size seems correct for buffers of any size.
So 100% sure it's not the buffer, I'm sure from your comment that it's not the shader. 
sending in the same buffer but with a lower count crashes, so either there's something very subtly wrong or the driver is bad. Or maybe my card.

activating debug context resolves the issue. I think even if I have done something wrong the drivers should at least give me more info than this
     nvoglv64.dll!000007fecfb7ce67()    Unknown
     nvoglv64.dll!000007fecf654fca()    Unknown
     nvoglv64.dll!000007fecf655db4()    Unknown
>    Testbed.exe!DrawMeshShaded(Mesh & mesh, Color color, Shader & shader, Matrix * mat) Line 498    C++

On the danger of being impertinent, but you can just pass in the vector's data() pointer.

Pseudocode for static data, 1 vec3 attribute:

vector<vec3> vertices;

glCreateBuffers(1, buf)
glNamedBufferStorage(buf, vertices.size(), vertices.data());
glCreateVertexArrays(1, vao)
glVertexArrayVertexBuffer(vao, buffer index, buf, 0, sizeof(vec3);
glVertexArrayAttribBinding(vao, shader attrib location, buffer index );
glVertexArrayAttribFormat(vao, shader attrib location, 3, GL_FLOAT, GL_FALSE; 3 * sizeof(float) /*or sizeof(vec3)*) );
glEnableVertexArrayAttrib(vao, shader attrib location);

and before the draw call:
glBindVertexArray(vao)

And that's it for static data ...

In the vertex shader: layout( location = shader attrib location ) in vec3 positions;

What's the difference between using &vertices[0] and vertices.data()?

5 hours ago, taby said:

What's the difference between using &vertices[0] and vertices.data()?

If vertices is empty, .data() doesn't crash.

Green_Baron: I thought as much, but wasn't sure how it worked when the graphics card runs out of memory and needs to swap stuff in and out. Or if the buffer call was async or not. Does the driver allocate it's own memory to swap stuff? Or is that something you have to manage yourself?

I don't know what it does behind the scenes, i think it can swap some stuff. In opengl 4.5 glNamedBufferStorage (or glBufferStorage(), and the glBufferData() family) asks for the memory to hold the upcoming data. If it fails it generates an out-of-memory error (which the debug context will catch then). Large mipmapped textures are memory intensive. And yes, if that happens, the world must change to accomodate for it. I haven't been there yet ... dunno ... but a mipmapped rgb texture of 8k*8k is ~800mb ...

For more details: Red and Blue book.

I've got an old version of the red book from way back. Not sure I want to pony up the money again.

When I get back home I'll try to use some example program and see if that works. That should prove either way if it's my code or not.

You don't want to own the latest available documentation and reference ?