3 ms·
I think templated or generic handle classes are pretty good for dealing with foreign objects. They can handle any bookkeeping a VM requires. The background is
by sjmulder 8y ago
I think templated or generic handle classes are pretty good for dealing with foreign objects. They can handle any bookkeeping a VM requires.
The background is that I've been playing with C to write Win32 apps that are highly backwards compatible (back to 3.11/Win32s if possible) but also modern when running on newer Windows versions.
For the latter I've been manually writing COM exports which was painful but it works. This made me consider C++ as an alternative where I'd be able to use templated types (and destructors!) to great effect. I can limit my use of the standard library to keep it freestanding.
However I would still be limited to writing native code, which is why I'd like something that can target the Android Runtime and such.
- lmm 8y ago> I think templated or generic handle classes are pretty good for dealing with foreign objects. They can handle any bookkeeping a VM requires. What do you mean by this?
- sjmulder 8y agoWith C++' destructor call guarantee and its templating features, it's feasible to implement shared_ptr-like types for foreign object types. Microsoft's ComPtr for example takes care of COM referencing counting. If some VM would require you to pin and unpin objects before and after use, you can do that in such a handle.
- lmm 8y agoHmm, you're talking about calling into a VM language from a manual-ownership language like C++? At that point any VM language would be fine, but I'm not sure that scenario makes sense in the first place - if the outer program is in C++ that's presumably because it has some requirement avoid GC, and embedding a VM that has to do GC would undermine that.