This is pretty cool, Szabolcs, thanks for sharing this with the community.

One thing you might consider adding in future is something we've been taking advantage of for the neural network implementation we're working on for 11, which is to use the new, fast RawJSON import/export facility to handle things like multiple return values, associations, lists of strings, lists of booleans, tuples of mixed types, and other such things that don't have a native LibraryLink representation.

You can use Developer`ReadRawJSONString and Developer`WriteRawJSONString on the Mathematica side to efficiently serialize/deserialize all but large numeric tensors to/from UTF8 JSON strings, which can then be sent/received to the C++ side. On the C++ side you can use a header-only JSON parsing library to parse these and with a few simple functions turn them into things like std::vectors or hashmaps of strings and so on. It's possible to use templates to even make JSON (de)serializers that handle arbitrary kinds of nested vectors, tuples, hashmaps and so on without having to write any boilerplate.

As long as the bottleneck isn't serialization, it makes it much easier to work with weird data types using this technique. Large tensors of course are better suited to going through the normal LibraryLink mechanism, and returning multiple such tensors is better suited to your current approach.

Alternatively, you can use the ExpressionJSON variants of the above Developer functions to send arbitrary symbolic expressions over, so that your C++ program can process and emit things that aren't just lists and associations of the basic types, but could be e.g. polynomials or Entities or Quantities or what-have-you.

LibraryLink has picked up support for RawArrays, though that's not documented since RawArrays are themselves not documented. Let me know if you are interested in that and I'll share how to do that.

I also have a snippet of code that let's you write debugf("fmtstring", arg1, arg2...) from the C/C++ side and have that print immediately to your notebook on the Mathematica side, that's invaluable when debugging. This can be turned on and off via an EnableDebugPrint[] function so you can leave it in production code and turn it out when you need to.

- Congratulations! This post is now a Staff Pick as distinguished by a badge on your profile! Thank you, keep it coming!

Thank you! I'm looking forward to it as I am quite curious about what RawArrays can be used for.

I have never used RawArrays before, partly because they are undocumented and partly because they did not seem all that useful for pure-Mathematica programming. Today I spelunked a bit, looked at the RawArray functions in Developer`, noticed that Normal and equality comparison (==, ===) works on them.

I am hoping to be able to use them to represent special data structures directly, but also memory-efficiently, as an (immutable) Mathematica expressions, and thus integrate them much better into Mathematica.

Currently LTemplate is very much focused on working with opaque and mutable objects. The memory is allocated and managed completely on the C side, and Mathematica only has a reference to C-side objects (as in integer, using managed library expressions). These mutable objects are not a good fit for pure-Mathematica programming, so when I used LTemplate in a published package, I completely hid them from the end user.

What can we do with RawArrays in Mathematica other than create them, convert them to a list, or compare them?

I imagine applications such as representing the state of a fast random number generator, and integrating it to Mathematica's RNG framework. I once wanted to do this with LTemplate and used the managed library expression ID as the Mathematica-side "state". But it turned out that Mathematica's RNG framework requires that states be comparable with == (this doesn't seem to be documented, but if they are not equality-comparable, things break). So it won't work this way. It would be necessary to represent the state as a Mathematica list. But that is messy and more work than I'd want to do because Mathematica integers (mint) may not map to what a particular RNG implementation might use internally, and also the mint size differs between platforms. I don't think 32-bit platforms will go away just yet: the Raspberry Pi is 32-bit. With a RawArray whose internal type is known and fixed this would be easier. I guess in principle a RawArray["Byte",...] could store an arbitrary C++ POD type. (Of course there's also applications like storing images, sounds, compressed byte-stream, etc.)

I will be away for ~10 starting today, so I'll only be able to check responses afterwards.

LibraryLink has picked up support for RawArrays, though that's not documented since RawArrays are themselves not documented. Let me know if you are interested in that and I'll share how to do that.

Yes, I would be quite interested in this if you are willing to share, and debugf as well :-) It is a good idea to make it possible to turn on/off such output.