I am currently working on a project, which uses a Nim library, which is basically wrapping a .h file with nimterop.
My project additionally wrapped a .hxx (C++) file the classic by the book Nim way.
Now, I have the problem, that I have to compile the project with the cpp backend, to make my wrapping work, but then the Nim library using the .h file with nimterop stops compiling. When I compile it with the c backend, obviously my C++ wrapping stops working.
So, there are several ways to fix this, for example, I could re-implement the C++ wrapping by wrapping the corresponding .h file instead, replacing the wrapping of the .hxx file.
When I asked myself, what I should do, to fix this, I realised it would be helpful if the people from this great community could chime in on this issue.
What would be the "best" way to fix this? "Best", as in, whatever you personally think is best. It could be the most idiomatic or the easiest or the most compatible way of solving the problem.
I'm personally a fan of most idiomatic ways to solve something.
Nimterop: https://github.com/nimterop/nimterop
The C library wrapper or "just a thin Nim shell around the libmdbx C library" ;) https://github.com/snej/nimdbx
The C++ library my project is wrapping/using: https://github.com/hunspell/hunspell
My project: https://github.com/theAkito/steamreviewessentialiser
The C++ usage in my project: https://github.com/theAkito/steamreviewessentialiser/blob/1a64218167b2b22fd2291ebf5f32d1e90f39704b/src/steamreviewessentialiser/spellor.nim#L10-L22
Thanks for the suggestion.
Yes, using a dynamic library seems obvious, but I don't like adding such stuff to small Nim programs. It's too much bloat for such a slim program.
After thinking about the situation, I would consider either statically linking the database module with the rest of the program staying in C++, however I'm not sure if that would work flawlessly, or re-importing the Hunspell methods from C. I originally used the C++ side of Hunspell, because it's mainly a C++ program and at that moment haven't thought about the existing C library.
Before choosing a library, I was investigating which one would fit best. I was trying to find a simple one, but the simplest I found was Hunspell. I had seen your libraries, too, well, at least I remember the suggest library, but it seemed more like a paper than anything, so I didn't get the impression it would be wise to use it.
Hunspell was in the end even easier, than expected. The library looks huge, but usage is very simple. Get suggestions. Correct words. That's it. Precisely what I want.
Additionally, I already familiarised myself with the library and already know how to implement it, etc. I already set it all up. So, switching to an entirely different library would make things even more complex and time-consuming, instead of saving time due to the better Nim implementation of the alternatives.
The "American English" thing is on top of the file, because at first the program will only support (American) English, as that's the most important language for reading game reviews.
I didn't want to go deep into linguistics or language research of any kind, through that project. I literally just needed a library that corrects words and guesses what word is meant, if spelled incorrectly. I wanted to avoid review keywords getting lost, because of misspellings.
So, I would perhaps look more deeply into the alternatives, but I already implemented Hunspell successfully and am quite satisfied with it.
That said, I am trying to apply a not so time consuming method of solving this situation, but it should still be a real solution and not a quick hack or something anti-idiomatic or anti best practice.
Anyway, I appreciate your suggestions. You obviously have deep knowledge about that topic.
I agree that the instrumentation in suggest.query obscures usage and the README is more like an academic paper than instructions for how to use the software. And that package is probably the most "turn-key & go" of the alternatives I listed. It sounds like you've already decided on hunspell. So, you can take this usage vignette as just an attempt to maybe help someone else use it if they stumble across this thread.
Given a dictionary file with term frequency/probability like:
the 23135851162
of 13151942776
and 12997637966
to 12136980858
...
import suggest
proc maybe(prefix="/tmp/p", bad="slugde", dmax=2, kind=osa,
matches=6): seq[string] =
var s = suggest.open(prefix)
result = s.suggestions(bad, dmax, kind, matches)
s.close
echo maybe() # @["sludge", "slide", ..]
In the end, I just re-implemented Hunspell in C. Was the easiest idiomatic solution, but not the quickest.
https://github.com/theAkito/steamreviewessentialiser/commit/6e1df5861f416311f17e93c7a4d2b35df053cc4a
I had trouble with cstringArrayToSeq, where it incorrectly deduced the actual array length. I have to provide the array length manually to the less common cstringArrayToSeq(n: int).
https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-importcpp-pragma
Indeed, it's possible. I have thought about the solution, but the manual implicates, that this method of using C++ should be avoided, whenever possible.
https://nim-lang.org/docs/manual.html#implementation-specific-pragmas-emit-pragma
At least, I don't know of any way how to apply this:
#ifdef __cplusplus
extern "C" {
#endif
Without using the emit pragma.
The other issue with this solution is, that it more or less assumes, that a majority of the project is C++, whereas only a few exemptions are actual C.
In my project however, the opposite was the case. Interfacing with C++ was the exemption and C code was the default. It is much more likely that I would add further C libraries, rather than further C++ libraries.
I know, this does not really matter that much in Nim, but it's still a point that I consider worth thinking about.