If it's an alternative implementation, why does it have to be in CSFML? Can't you fork it and do the modifications in your own modified CSFML?
Well, of course I can do that. But what would it be good for? It would only add confusion and unnecessary work of re-merging if SFML or CSFML is updated. CSFML is being provided precompiled for many systems, and people would just need to download the binding + CSFML.
It would also enable other people with similar problems to write a binding directly to CSFML. There's a reason SDL only passes pointers.
Again, as I don't want to cause any work, I'd fork it anyway, and only ask to submit if the binding gets finished. It possibly was a bit premature to ask, as that is still a way off. ;)
I guess it might be helpful to provide a bit more information on your idea, especially since the bumped thread is like four years old. ;)
The basic idea is to just provide alternative functions that pass pointers, e.g.
CSFML_GRAPHICS_API sfRenderWindow * sfRenderWindow_create (sfVideoMode mode, const char *title, sfUint32 style, const sfContextSettings *settings)
=>
CSFML_GRAPHICS_API sfRenderWindow * sfRenderWindow_create (sfVideoMode *mode, const char *title, sfUint32 style, const sfContextSettings *settings)
and
CSFML_GRAPHICS_API sfContextSettings sfRenderWindow_getSettings (const sfRenderWindow *renderWindow)
=>
CSFML_GRAPHICS_API void sfRenderWindow_getSettings (const sfRenderWindow *renderWindow, sfContextSettings *settings)
I'm not so sure about the second example, or if it's better to create a new sfContextSettings struct and return it, but I'd rather have a "who creates it, is responsible" approach.
If anyone is interested, I asked a question on the Common Lisp side of this on StackOverflow (http://stackoverflow.com/questions/23579340/passing-and-returning-structs-to-c-functions-on-stack-from-common-lisp-with-cffi) a while back, to make sure I'm not missing anything.
I don't know if this helps you out at all, but you could look at DSFML-C (https://github.com/Jebbs/DSFML-C), which is a modified version of CSFML that removed all POD structs (sfVector2f, sfTime, etc) in lieu of using a set of scalars instead.
For example:
CSFML_GRAPHICS_API sfImage* sfImage_createFromColor(unsigned int width, unsigned int height, sfColor color);
Looks like
DSFML_GRAPHICS_API sfImage* sfImage_createFromColor(DUint width, DUint height, DUbyte r, DUbyte b, DUbyte g, DUbyte a);
(though now I realize this function passes the color in rbga order instead of rgba order :P)
Feel free to use it if you want, but some of it (the audio stuff) is a little experimental. Just a heads up.
I don't know if this helps you out at all, but you could look at DSFML-C (https://github.com/Jebbs/DSFML-C), which is a modified version of CSFML that removed all POD structs (sfVector2f, sfTime, etc) in lieu of using a set of scalars instead.
For example:
CSFML_GRAPHICS_API sfImage* sfImage_createFromColor(unsigned int width, unsigned int height, sfColor color);
Looks like
DSFML_GRAPHICS_API sfImage* sfImage_createFromColor(DUint width, DUint height, DUbyte r, DUbyte b, DUbyte g, DUbyte a);
(though now I realize this function passes the color in rbga order instead of rgba order :P)
Feel free to use it if you want, but some of it (the audio stuff) is a little experimental. Just a heads up.
Thanks, this one would actually work. :D
Deconstructing all structs seems a little overkill for my purposes, though, as I only have problems with very few functions, and you lose some readability. Still, it'd be a better alternative than having to maintain yet another fork, IMO.