int vs int32 about go-sdl2

[phicode]

Golang's Int on 64 bit machines is 8 bytes.
Methods which return or accept an Integer could be changed easily.
Structures which are passed to SDL need to adhere to the ABI of the C structures.
Otherwise all structs would need to go through a translation layer.

I recently fixed (almost) all struct ABIs, see: https://github.com/veandco/go-sdl2/blob/master/sdl/struct_test.go

In general I agree that reducing type casts would be nice. On the other hand go ints do have different width on 32 and 64 bit systems.

[slevin]

I see. I was mistakenly under the assumption that C ints would be 64bits on a 64bit machines. I missed that you were doing casting into and out of Go ints in parameters and return values. I guess translating structs would be too much a performance hit? And its not clear making everything int32 (parameters and return values) would be less casting or more convenient even if that might make the api more consistent.

[phicode]

I contributed the unit tests and fixes because I ran into some misaligned structures while developing some little test applications.

From an architectural point of view I believe that a translation layer would make a lot of sense.
For example I did not fix the 'AudioCVT' structure because CGO has a hard time dealing with packed structures.

Since I only fixed existing code I did not add real struct translations (purely out of laziness :) )
My measurement so far have shown that crossing the barrier between C and GO through CGO is quite expensive. More than a very few thousand calls per frame is unrealistic.
So I believe that a translation layer would add few enough overhead to be noise against the CGO call overhead. Of course benchmarks would be required to verify this.

This could be a nice place to try out go:generate :)

@jackyb: Do you have any design in mind for this or similar issues?

[krux02]

I actually would suggest, to chage the API to int whenever possible. For example in timer.go GetTicks and Delay could be changed to use int instead of uint32. For the Rect API, I do suggest, to implement both Rect and C compatible non exported rect32 for communication. I think a rectangle is small enough to be casted back and forth on calls, where it matters. All functions that do clipping and other calculations on rectangles should be ported to native go, to prevent CGO calls.