Krux02- it looks like you are using a struct with a single field instead of a
distinct type for things like shader/program ids. What are the pros/cons of
that approach?
Thanks everyone, some good things to think about.
Always a good thing to have! The OpenGL spec is disappointing in this regard,
because you cannot use it to generate a particularly type safe interface with
the information that is available.
Note: instead of this:
proc rawSeq[T](s: seq[T]): ptr T =
{.emit: "result = `s`->data;".}
Use unsafeAddr(s[0])
If the compiler does not inline a proc marked inline it probably has a very
good reason, probably related to code being to big or not being in a hot path
(and avoids polluting cache lines).
So I think it's fine not to use templates here.
> because it's not guaranteed
No it is not guaranteed, the C-compiler is free to ignore inline.
But can you give examples where inline pragma does not work fine? Nim copies
procs marked with inline pragma into all C files when necessary, so inline
works fine over module boundaries. I have not s
jackmott: I really think you should use templates instead of inlined procs
here, because it's not guaranteed that proc will be inlined (even with inline
pragma)
Well, you are not the only one who wants this. I also have my opengl wrapper as
part of my program here:
[https://github.com/krux02/opengl-sandbox/blob/master/fancyglpkg/glwrapper.nim](https://github.com/krux02/opengl-sandbox/blob/master/fancyglpkg/glwrapper.nim)
I have been going through the tutorials on
[LearnOpengl.com](http://www.learnopengl.com) and building up type safe
wrappers as I go along such that I can use opengl as if it were more like a
native Nim library, removing the need for casting and making it a compile time
error should you mix up y