The use of slices and arrays as parameters in the Uniformxxx funcs

[kunos]

I am just moving my code to go-gl, code is an improvement but, I am struggling to understand the reasoning behind passing slices and arrays to the various funcs in uniformlocator.go .

For example:
func (location UniformLocation) Uniform3fv(count int, v []float32) {
if len(v) < 1 {
panic("Invalid array length - must be at least 1")
}
C.glUniform3fv(C.GLint(location), C.GLsizei(count), (*C.GLfloat)(&v[0]))
}

I think 99% of the time this is meant to pass some sort of Vector3 structure. I also guess this kind of approach is very common:

type Vector3 struct {
x,y,z float32
}

Now converting this into a slice is quite a mess... internally the funcion is then converting to a float* .. my proposal is to use *float32 as parameter with these functions, like this:

func (location UniformLocation) KSUniform3fv(count int, v *float32) {

C.glUniform3fv(C.GLint(location), C.GLsizei(count), (*C.GLfloat)(v))

}

and

func (location UniformLocation) KSUniformMatrix4fv(transpose bool, count int, matrix *float32) {

C.glUniformMatrix4fv(C.GLint(location), C.GLsizei(count), glBool(transpose), (*C.GLfloat)(matrix))

}

This should easily map to any kind of internal data structure used by the clients of go-gl .

[pwaller]

Hi! What are you moving from, out of interest?

Things are this way for a reason: go-gl/gl#77

If it would significantly help then I am not totally adverse to adding new functions which allow direct pointer access, but you must bear in mind that type safety is lost if you do this, as is potentially some performance, depending on what you're doing. Maybe not so much with the glUniform functions, though. I resigned myself early on with go to using slices of values rather than structs.

What does "KS"Uniform" mean? I would think better to call it UniformMatrix4fptr or something to indicate the type is a pointer rather than a "vector" (slice).

@jteeuwen care to weigh in?

[kunos]

Moving from chsc... although I am not sold on the idea yet.. so some mysterious reason including go-gl breaks type infos and "jump to definitions" in LiteIDE.. weird.

the KS is just the company prefix we add to temporary modifications of opensource project... it is not part of my proposal.. just a quick cut& paste.

[pwaller]

Unfortunately I can't help with it breaking LiteIDE. If there is a simple fix to go-gl which doesn't break any API compatibility I'd be happy to merge.

[UserAB1236872]

I know this sounds like excessive nitpicking, but I feel like I should mention that the Go spec doesn't guarantee structs are laid out in field order in memory, nor does it guarantee any word alignment, so passing in a pointer to a struct field is technically dangerous.

[pwaller]

Yeah, I remember going through this when I first tried out go and not getting that point, @Jragonmiris. I agree.