Call and return by reference in CSFML

[Laurent]

On the second point ... yeahhh ... seem to remember making similar mistakes. Is there a better alternative?

I don't think so.

[Flash]

I know this is an old topic, but may I add my support to this request?
Forth is not the only language that is designed this way, it is true for Common Lisp (and other languages) as well.
The functions that get or return structs on stack would not need to be replaced, it would be OK to merely implement an alternative and make it clear in the documentation that they are only to be used for bindings.

I can do the additions myself, all I'd ask is that *if* I ever finish the Common Lisp binding, I'd be allowed to commit the changes back to CSFML, so that the binding would compatible with the main branch, without needing an additional wrapper dll.

[zsbzsb]

And this would break almost every single existing binding for SFML, not to mention introduce more issues for binding maintainers.

[Flash]

How would alternative implementations that do not change any of the functions that already exist break anything?

[Laurent]

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?

[eXpl0it3r]

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.

[Flash]

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 a while back, to make sure I'm not missing anything.

[Jebbs]

I don't know if this helps you out at all, but you could look at 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 )

Feel free to use it if you want, but some of it (the audio stuff) is a little experimental. Just a heads up.

[Flash]

I don't know if this helps you out at all, but you could look at 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 )

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. 
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.

[Laurent]

It would only add confusion

Having two versions of each function in CSFML would be confusing. Having a fork which is dedicated to this modification would be a lot clearer in my opinion.

unnecessary work of re-merging if SFML or CSFML is updated

Updating these functions every time CSFML is updated is not unnecessary work, it has to be done anyway. Of course it's easier for you if it's me who does it...

CSFML is being provided precompiled for many systems, and people would just need to download the binding + CSFML

You can provide your own releases. And since people interested in this fork would be bindings creators, I don't think they would be afraid to compile it if they can't find a precompiled version for their platform.

There's a reason SDL only passes pointers.

Did they say it is for this particular reason?

[Flash]

It would only add confusion

Having two versions of each function in CSFML would be confusing. Having a fork which is dedicated to this modification would be a lot clearer in my opinion.

unnecessary work of re-merging if SFML or CSFML is updated

Updating these functions every time CSFML is updated is not unnecessary work, it has to be done anyway. Of course it's easier for you if it's me who does it...

I'm sorry, I just realized that I made this request under false preconceptions.
For whatever reasons I thought that rogerlevy's list posted in this thread was accurate, and I still think that it would have been a good idea for ~10 functions (and little extra work to maintain).
However, knowing the CSFML source I should have known better, as this list contains none of the functions that return vectors, rects and similar stuff (I think I realized this a few weeks ago, but had forgotten, as I did not work on the binding in the meantime).
Thus I realize that having alternatives for that many functions might be confusing, and is additional work to maintain.

CSFML is being provided precompiled for many systems, and people would just need to download the binding + CSFML

You can provide your own releases. And since people interested in this fork would be bindings creators, I don't think they would be afraid to compile it if they can't find a precompiled version for their platform.

Well, I hope that the people interested in this fork would be Common Lisp Users. And it would have been nice to just download the appropriate dll, load the bindings via quicklisp and everything would work, regardless of system. Alas, that's not gonna be.

There's a reason SDL only passes pointers.

Did they say it is for this particular reason?

No, it was an assumption on my part, because I couldn't think of a better reason other than speed (but they do it even for all structs). It might be one of several reasons, or not play a role.

So I'll see what I'll do. Possibly DSFML-C is the best alternative, as I really want to avoid having yet another fork unless I really have to. As I plan to have high-level lispy abstractions modeled on SFML anyway, the deconstructed parameters would be hidden anyway.

[Jebbs]

Please be aware that DSFML-C is written specifically to interface with the D binding so it might not fit right for lisp in all cases.

[Flash]

Please be aware that DSFML-C is written specifically to interface with the D binding so it might not fit right for lisp in all cases.

How does this specificity manifest itself?
I thought it was just a normal C binding without structs.

[Jebbs]

In some cases, D is able to interface directly with C++, so I do that when I can and it makes sense. That means that some functions in DSFML-C expect C++ objects to be passed to them by address since those can be created in the D code.

[Flash]

In some cases, D is able to interface directly with C++, so I do that when I can and it makes sense. That means that some functions in DSFML-C expect C++ objects to be passed to them by address since those can be created in the D code.

OK, so I can't use it either.