Use this with C++

[Personwithhat]

Hello,

Can't find any contact info for you. So I'm posting this as an issue.

Could you please add (or let me know how) to use your library with a standard C++ program? I have little experience with cross-language interface management, F#, and C# in general.......

I'm writing a calculator for HOI4 right now, and would prefer to load unit stats directly from game files. Hence the need for a parser.

[lowbeyonder]

So I know this is from last October, but I ended up poking at this for my own project and figured I'd post what I know for anyone else who wanders in via search engine. (Disclaimer: I'm not a project contributor, just an interested third party.)

AFAIK the two options are:

1. Use C++/CLI (compiler flag /clr; in VS set Common Language Runtime Support in project properties > Advanced). Then you can set CWTools as a dependency and, in theory, directly call F# functions. It's not quite that easy in practice, and I haven't quite gotten it working yet, but this is probably the simplest route.

   The downside is you're writing C++/CLI. Which is a lot more like ANSI C++ than F# is, but it's definitely not identical.

2. Compile the F# into something C++ can reference. This can be either wrapping it with C# and producing a mixed assembly that exports native symbols, or actually getting F# to compile into native code. This blog post gives a general outline of the method, but I haven't actually gotten it to work.

   Past just getting it to build, it probably requires a bunch of tedious boilerplate to export native entry points for methods and marshalling types. So at the moment I've resigned myself to option 1 (or just learning F#, or excavating what I remember of C# from the dim recesses of my brain).

[tboby]

Out of curiosity, which parts of cwtools would you be most interested in being able to call?

I suppose one could split it into two main sections:

1. Dumb (work on any file with no context)
   1. A parser (read the files in a dumb way)
   2. A PDX Script AST with modification and pretty printing (make dumb edits and write back to file)
2. Smart ( require rules files, requires access to vanilla metadata, needs context of the whole mod)
   1. "Semantic" file understanding: List of all types and where they are defined, locations of references to other types, knowing a range in a file is a trigger, etc
   2. Validation: Get a list of all errors for a mod project
   3. Misc IDE utilities: Get scopes at position, Get completion for position, Event graphs, localisation usage

Because the parser isn't really all that complicated, and it would likely be faster to copy and rewrite (or find one of the many other implementations).

If you're after high level IDE features (or more intelligent analysis of the mod as a whole), then the current options are:

1. Use the CLI to get validation errors
2. Use the LSP implementation to get IDE features using a LSP client library in your language.

Would creating a small gRPC server make any sense? You'd still have to run cwtools alongside your application, but cwtools supports pretty much any platform, and it might be a fairly easy way to expose a number of method calls?

[lowbeyonder]

In my case, it's more the latter, higher-level features. I'm still at a very early stage, but I've been toying with the idea of a test framework for mods. So a mod author could write test scripts in a similar syntax that contain some setup and a series of expectations/triggers, then run a binary that would load their mod + vanilla files and report pass/fail on the expectations. (Instead of needing to test things out in-game, which can involve a lot of loading and fussing around to isolate a change and verify the outcome, and can't really be automated.)

So far it strikes me as a difficult problem, but not an impossible one; then again, I'm still early enough in the exploration process that maybe I just haven't found the impossible parts yet.

gRPC is certainly handy. I suspect I'm going to end up using this as an excuse to learn F# anyway though.