Linking C++ Code

[UrbanCyborg]

I seem to recall a thread on this topic, but can't find it, so I'll ask. Has anyone had any success in linking in code written in C++? If so, what did it take, and was it at all efficient? Thanks.

Reid

[utdgrant]

Possibly the VCV Rack Goes Pro thread?

[UrbanCyborg]

No, not that one. I remember it, though. I was looking more for something about the technical guts of linking in bits from other languages.

Reid

[ColinP]

I vaguely remember some more technical thread about this too.

JNI is the standard Java route for such things but I've not looked at it as I have no interest whatsoever in going anywhere near C++ ever again if I can help it.

I'm guessing that trying to mesh a modern virtual machine language that has garbage collection with an ancient native one is bound to throw up all manner of efficiency and reliability problems. And dread to think about what's involved in doing anything multi-threaded in such an environment.

Maybe it's easy in practice but I very much doubt it.

Unless you need to interface with some massive legacy system I don't know why you'd want to go down that path.

[UrbanCyborg]

Mainly to get access to a one-of-a-kind FFT library.

Reid

[ColinP]

Hi Reid,

If you have the source code and it uses indexed array access rather than pointers then I suspect it'd be easier to port it from C++ to Java than try to link the two languages.

[ColinP]

It's looking like I might, very reluctantly, have to travel down this road after all.

Has anyone here actually explored using JNI in VM?

[UrbanCyborg]

Just FYI, no, I very much suspect that any FFT library written in C or C++ will use pointers, since speed, speed, speed is the name of the game in things like FFTs. For C++, of course, that could take the form of safe pointer objects like shared_ptr<> or unique_ptr<>, but there's still a pointer down in the guts somewhere. Well, there ultimately is in the compiled form of Java code; take a look at Java output in Compiler Explorer (https://godbolt.org), for example.

Just the other day I had occasion to port a minor chunk of C++ code, and it turned into a real learning experience (for example, I learned to my dismay that not only are PODs second-class citizens in Java, which I already knew, but there simply aren't unsigned numerics - and please, no one mention the Integer class, because it isn't, either). I ended up implementing it without the benefit of unsigned_ptr<> and using Integer (with my fingers crossed).

Ordinarily, I keep quiet about comparisons between Java and C++. I guess that experience just got under my skin. Usually, when anyone, including the people writing Java texts, makes slam comparisons with C++, they're comparing with features that went the way of the Dodo in C++ long ago. Modern C++ is a completely different animal than what I first learned. Even Bjarne Stroustrup commented in the foreword of a recent book that it seems like a completely different language to him! Anyway, this isn't a flame, just a brief rant. No, really, I've got it under control now. Hey! What's with the straight jacket? Wait a minute....

Reid

[ColinP]

Hi Reid,

Thanks for those insights.

I've never really encountered any problems with Java not having unsigned ints. Oh I think you were actually talking about the wrapper classes and autoboxing and unboxing? I didn't really understand that part of your post.

I have little knowledge about what's going on inside a Java Virtual Machine but do realise that one should make as few assumptions as possible. I believe Java intentionally decouples abstract behaviour from underlying implementation for the sake of efficiency - so VMs can do things in whatever way makes sense on a particular platform (including ones that don't exist yet). That's why JNI becomes so important to isolate one from the difficulties this might otherwise give rise to when interfacing between Java and a native language.

I've become comfortable with the lack of pointer arithmetic. The benefits are so great that concerns about efficiency are secondary. Also optimization technology has reached a point where it can do a better job than I can at a low level. And things will improve over time to the point that I think "just leave it the AI man" will become the only sensible strategy (at least in non-native languages)

C++ was a difficult language when Stroustrup invented it and it seemes to have gotten worse over time. I look at modern C++ and think I'm really glad I don't have to deal with that anymore.

But unfortunately I'm wanting to build a specialized module that will need to do some of its work in C++.

Reading up on JNI the basic interfacing doesn't look too bad as JNI seems well thought out but I'm concerned about hidden pitfalls and getting the code to run on both PC and Mac. I also might need to do some low-level schenanigans to get the thing to run at top speed.

[UrbanCyborg]

You wouldn't normally miss unsigned numerics, but when you're porting code that absolutely relies on unsigned values to do bit-fiddling, not having it is something of a disaster. The problem with Integer as a replacement is that it just lets you pretend to be unsigned, and supplies some operations to make you think you are. Unfortunately, Integer really represents a signed object. I'm not really sanguine about the fundamental integrity of code depending on Java not to accidentally or deliberately walk on the unsigned status of the code, since Integer is fundamentally signed.

Yes, I could have replaced the unsigned parts with something that didn't require unsigned, but it would have been grotesquely less efficient. Losing the unique_ptr<> object wasn't much of a hit in this context.

If you're looking for informational help for a C++ context, the single most important web site is likely Cpp Preference https://en.cppreference.com/w/. For books, Nicolai Josuttis has a really great self-published series discussing in detail the changes made in each new version of C++ (current version is C++23), and his book on Move Semantics is a totally readable discussion of what is probably the most confusing feature of Modern C++.

Reid