On one hand, I appreciate Muratori showing that loading code into your program dynamically isn’t actually difficult. On the other, the hard part of general hot reloading on systems that have tried it (from Smalltalk to VC++ Edit-and-Continue) is migrating obsolete state—or at least reliably telling the user when you can’t, so as to avoid leaving them to debug a mad world that could never be encountered in a fresh run. As far as I remember, Muratori basically does not touch on that at all.
There is a tsoding daily video with hot code reloading in C [0].
He dicusses techniques for this. one of which is a "migration" approach, similar to database migrations. Where, for example, you have a version number in your struct. and a function for migrating from an old version to a new version. I don't think he implements it in that video though.
To migrate from one class version to another, I found the easiest way was to provide a callback method in the constructor where one could save the state from the old class, and read it into the new class. For example:
https://github.com/jheruty/hscpp/blob/master/examples/simple...
Ultimately though the limitations of hot-swapping this way limits its usefulness. My understanding is that liveplusplus is much more full-featured.
Hm. I have mixed feelings about this project (judging solely from the video presentation). On one hand, it is very impressive, no question about that. The sheer amount and diversity of stuff in it would require a degree of focus that makes me feel envious even after this very superficial examinaton. On the other hand, the choice of which stuff to put in just disagrees with how the boundaries are drawn in my head—I’d would have thought a file monitor and a build system/dependency tracker were separate tools, while expecting at least the simple part of migration boilerplate to be generated.
But I guess that’d require hooks into the compiler frontend, which is not just goes against your goal of being relatively compiler-agnostic but is also fantastically difficult for C++. (I wonder if DWARF contains enough data to at least transfer over identically-named fields?.. It’s also something of a bear, but nowhere near a full C++ frontend.) I don’t know how this could be useful to you, sorry. Thank you for showing your project, I’m grateful for the food for thought in any case.
Now, can we just all take a moment to appreciate that you needed a Smalltalk-style become:[1] and ended up making an object table, precisely the classic Smalltalk way? In the end it’s either that or precise pointer tracing, there isn’t (AFAIK) a lot of choice, but it’s still amusing to see an ostensibly high-level mechanism reproduced in a very different environment.
