Get rid of DSFMLC?

[Jebbs]

Since version 2.066, D compilers have the ability to call non-virtual member functions for c++ classes. This should mean that we no longer need to wrap each class in a C struct. There will still need to be some kind of compatibility layer, but nothing like what currently exists.

I'm hoping that we can work towards not needing anything except the SFML bins and have D take care of the rest.

[SyntaxColoring]

Out of curiosity, what was the rationale for creating DSFMLC instead of using the official C binding?

[Jebbs]

Pretty much this - https://issues.dlang.org/show_bug.cgi?id=5570

I'm not sure where this bug stands as of right now, but it would need to be fixed 100% in order for DSFMLC to be dropped.

[aberba]

That will help. Current process is tedious :(

[aubade]

A quick progress report on this matter: We're still not quite there as far as C++ interop goes; We can't yet call C++ constructors directly from D, which means we still need some C++-side glue code for certain sorts of object construction and disposal (Mainly the classes that refer directly to GL/AL resources like SoundBuffer and Texture, and ones that interact with the OS)

For the classes that have "pure" constructors, we can just reimplement the constructors D-side. For the ones that need C++-side construction, if we want to go ahead with this now, we have two choices:

1. keep them as wrapped classes, though alias this can still bring us some of the benefits of direct binding.
2. Implement them as directly bound classes with @disable this(), and force construction by factory functions until/unless D gains the ability to call C++ constructors or a way to override the new operator.

As far as I know though, the Linux64 ABI issue is still present.

[aubade]

Hrm. A trivial test says that enough of the ABI issue might have been fixed. I was able to successfully pass a 28-byte structure from DMD 2.077.1 to C.

@Jebbs I'll leave it up to you if (and with which approach) you want me to start pulling the trigger on this; it'd be a pretty massive pull request, just to warn.

And we will still have DSFMLC, but DSFMLC will be much smaller.

[Jebbs]

We can't yet call C++ constructors directly from D, which means we still need some C++-side glue code for certain sorts of object construction and disposal

Until this is fixed, I don't see the need to try to reduce the glue code that currently exists. I think that our time could be put to better use working on other parts of the library.

The next release should show that we can have the glue code but not have it impact the process too much. That's the hope, anyway.

Edit: Not to say you shouldn't work on that if it's interesting to you. It is something I would pull since we'll eventually move in that direction eventually.

[aubade]

It's an exciting thought, but honestly I'm happy to have the excuse not to, since i don't think there are any good .hpp translators yet, so it'd be a lot of work. :)