Walter Bright Wrote:
> 3. Implementation is unambiguous, straightforward, and easy to get right.
If that was a vote for method 3, then I cast there as well. I think keeping
the precision as a parameter of the object is most intuitive.
I don't feel strongly about rounding, but both the scopi
Sergey Gromov Wrote:
> I hope that you actually not "removed your extern(Windows)" but replaced
> it with extern(C). Otherwise you risk getting D linkage for those
> functions which is neither C nor C++.
This is just going to sound silly now, but I was following along the ".h to D"
conversion g
Sergey Gromov Wrote:
> I just wanted to double-check that you did the conversion correctly. So
> I ended up finding out what the hell TCOD was. Sorry for the spoiler!
> :D
Hah, no biggie. Good news though, I removed my extern(Windows) and tried the
code against the coffimplib altered library
Sergey Gromov Wrote:
> You're talking about Doryen Library project, right?
>
> My thought is that TCOD_console_flush is actually cdecl and must be
> declared as extern(C), while you seem to declare it as extern(Windows)
> which is stdcall. What you get with linkdef is corrupted stack. This
> is
Sergey Gromov Wrote:
> "Want to create an import library? Ask me how!"
Well since you offered... ;)
I tried out coffimplib, but it's not yeilding the results I need. I compared
the linkdef generated .def files with coffimplib's and the missing part is
pretty clear:
linkdef:
EXPORTS
_tcod
I'm working on a wrapper to a C dll and I think that I'll need to create a .lib
file eventually to connect my D code to the C library.
I've experimented with this a little, including using ipmlib to create the lib,
which creates a lib but not one that works right (I think it mangles the names
