Messages - Jebbs

Why does openForWriting exist in the InputSoundFile header? It seems to be a leftover from SoundFile and has no definition in the cpp file. InputSoundFile should provide read-only access to the file anyway, so this is a weird method to have.

So I rebuilt both for 64 bit this time, and implib is only for 32 bit, correct?

Correct. DMD's 32 bit linker(optlink) only accepts import libraries in a certain format, but 64 bit code uses a different linker. DMD uses the MSVC toolchain for 64 bit code, so make sure you're using the right compiler for that.

Quote

I'm confused on a few things though.1. What to do with the "dsfmlc-XXX-2.dll"?Link to them in the search directories or do they need to be placed in the /debug and /release dirs?

Those go in the same directory as your compiled .exe

Quote

2. The -I switch, isn't it redundant when you're already specifying the folders to refer to? Or is Code Blocks just not doing what it's supposed to, so you have to explicitly specify where to look?Also what things am I exactly linking to?The search directories to the src or the libraries or both?

Sorry if I wasn't clear. When I mentioned the -I switch, I was referring to it being used already (in your log) and that the -L switch was not being used even though you specified the directories in your linker settings. You'll need to manually add the linker options to include those directories to the searched list since Codeblocks doesn't appear to be doing it.

Quote

Also if you could be a little hand-holdy with the specifics that'd be nice.I really need to learn more manual compiler stuff after this.

The -I switch is for specifying where source code is, but there isn't any linker switches in there. You might try adding those in manually and see if that works. It should look like this: -L+lib/location/here. You'll need to link the DSFMLC libraries too in order to get everything to work correctly(you showed linking only to the DSFML libs in your steps).

Additionally, it looks like you're producing 32 bit libs. I didn't see this in your steps, so don't forget to run implib(which I've bundled with DSFMLC) on your dll's to make import libraries optlink can use.

Let me know if you need any other help! And if anything is ever unclear, please shoot me an email so I can update the tutorials.

This is because of the newest D compiler. They fixed a few long standing bugs, but it ended up breaking the way the import system was doing some things. What was actually happening is that it was using Object.toString() instead of dsfml.system.string.toString() because the compiler will search locally for symbols before checking any imported packages, even packages imported in the same scope. You just need to make sure you're a little more explicit with your calls where there is an ambiguity of function names.

I put the fixes in the code just a couple of minutes ago, so once dub updates its DSFML package you should be good to go.

The true solution would be a template based on std::is_integral and SFINAE or tag-dispatching. But I don't really like that for something so simple (and I'm sure Laurent does so even less ), furthermore we would need to re-implement the type trait because we're in C++98.

Why std::is_integral? Wouldn't std::is_arithmetic be better for this? That way you have only a single function for each operator instead of floats plus integer types. It would include double, but people should be aware of the implications and still allowed to use it if they want in my opinion.

This is an important milestone for the project though. There was a ton of bug fixes (mostly with the api), and I even managed to put up a (crappy) website featuring documentation, tutorials, and downloads. It also passes all unit tests, meaning everything should be functional now.

Checkout the repo here and the C binding this wrapper uses as a backend here.