Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C and C++ Hot-Reload/Live Coding

liveplusplus.tech

Post reply on HN
Print view View original

31–40 of 102 posts

Re: C and C++ Hot-Reload/Live Coding

#31

Post by norir »

mjburgess wrote: post #28
cangeroo wrote: post #21

Earlier quoted context omitted.

One problem is that modern software architectures are highly coupled and stateful, such that it isn't possible to hot reload a component. It would require the host (e.g. when using a DLL) to detect a change, save state, unload, reload, load state. Multi-threading may also make things more difficult, requiring more synchronization during changes. I agree with your sentiment, but it's really hard to communicate it to t…

well, i think the issue is as least as much that the developers who create these architectures do not start from this pov --- consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms. This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_s…

I feel like to some extent the problem here is the dynamic linking model that is almost universally used. If programs were designed from the perspective of the linker, then the linker could maintain a graph of function dependencies and have a cascading invalidation upon update. It is hard to retrofit this onto a project that is already a standard make based project.

Re: C and C++ Hot-Reload/Live Coding

#32

Post by reactordev »

adra wrote: post #29
throwup238 wrote: post #17

Earlier quoted context omitted.

> Doing it in C/C++ land is heroic. Not to diminish the accomplishment or anything but is it that much easier in C# and Java? It was always really easy to use the libloaderapi in Windows. Throw a vtable on it and baby, you got a stew going!

At least for java, you can spin out a new class loader which intercepts all class loading tasks and basically shim the dynamic module from the permanent runtime platform very trivially. For unloading, you'll likely need conventions on how to shut it down cleanly to not leave a ton of garbage around. Want a new version? Spin up a new class loader, rinse and repeat. If you need stateful between versions, you clearly ne…

Class loading from a DLL is one thing, persisting the state and reloading that state on-top is another. In Java, you can use the class loader to load new instances of a class, but it's up to you to transfer state before giving that class over to your program again. In C# it's a similar story with System.Runtime.CompilerServices. The trivial bits are the fact that you can use reflection to do this rather easily in both Java and C#. In C++ isn't not as simple. The struct/data signature may change, you need a temporary storage vessel (old object?) to copy to the new class object. While it's still "digital plumbing", it's not that easy to do and then hot-reload the whole stack.

Re: C and C++ Hot-Reload/Live Coding

#33

Post by PhilipRoman »

I'm a fan of the opposite approach - serializing the program's state and launching a new instance which reads it. For one particular application I just had it keep all of it's useful state in /dev/shm (mmapped as a struct), double buffering it on every iteration of the main event loop. Of course that doesn't scale too well if you have dynamic allocations.

This also has the advantage of not requiring platform specific code and being able to create checkpoints and time travel.

Re: C and C++ Hot-Reload/Live Coding

#34

Post by cangeroo »

mjburgess wrote: post #28
cangeroo wrote: post #21

Earlier quoted context omitted.

One problem is that modern software architectures are highly coupled and stateful, such that it isn't possible to hot reload a component. It would require the host (e.g. when using a DLL) to detect a change, save state, unload, reload, load state. Multi-threading may also make things more difficult, requiring more synchronization during changes. I agree with your sentiment, but it's really hard to communicate it to t…

well, i think the issue is as least as much that the developers who create these architectures do not start from this pov --- consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms. This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_s…

Yes, but:

Components depend on other components, and they all have to support hot reloading. And what about side effects? For example, an open network connection, or a window. You could store the state (handles etc.), but what about callbacks during the reloading phase? They'd have to block and wait.

Ultimately, what you need is a message passing architecture that supports all this. Smalltalk. Alan Kay has been a vocal critic of our modern architecture. See his talk "Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet".

But that architecture is computationally inefficient.

I suspect the problem is that computers weren't fast enough for the last 30 years. So we focused on performant computing. We still do that, with high fps gaming. And adding better quality graphics. Soon we'll have Apple Vision Pro with a 4k display for each eye.

My personal hope is that WebAssembly and the Component Model will drastically change things, by introducing API virtualization and effectively decoupled modules, but this will require that tree-shaking/deadcode removal is disabled.

Re: C and C++ Hot-Reload/Live Coding

#35

Post by Jeaye »

Folks interested in this should absolutely look at the open source Cling project, which uses Clang/LLVM to JIT compile C++ in-process. https://github.com/root-project/cling

I'm using Cling, as part of jank, a native Clojure dialect on LLVM, with C++ interop. This allows me to have truly interactive, dynamic programming, while still reaching into native code. jank source compiles to C++, which is then JIT compiled by Cling. In recent benchmarks, it can be several times faster than Clojure JVM. https://jank-lang.org/

Re: C and C++ Hot-Reload/Live Coding

#36

Post by mgaunard »

mananaysiempre wrote: post #24
kleiba wrote: post #18

In one of the earlier episodes of the Handmade Hero series, Casey Muratori writes a hot-reloading functionality for C from scratch in about an hour (while giving detailed explanations of what he's doing). The following two episodes then improve upon the initial results. https://www.youtube.com/watch?v=WMSBRk5WG58

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…

in C or C++ the bigger problem is ABI breakage or ODR violations.

Re: C and C++ Hot-Reload/Live Coding

#38

Post by [deleted] »

foooorsyth wrote: post #19
mjburgess wrote: post #6

fyi, "hot reload" is a native part of every operating system (consider, even trivially, forking or https://en.wikipedia.org/wiki/Dynamic_loading ). It's a sign of how bad developer tooling has been that live reload is sold as an add-on feature. DX seems always to see-saw between bill gate's c. 1990 demo of VB, and the compile-time speeds of a N' Wirth. At a guess, when the internet happened, all DX had to be thrown a…

>I support being paid for your work, but live reload is a fairly trivial thing to write for yourself -- I spent one day this gone weekend writing a debugger in C which does it. Major Dropbox “who would pay for this over just using rsync?” vibes here. Never change, HN.

[deleted]

Re: C and C++ Hot-Reload/Live Coding

#39

Post by pjmlp »

cangeroo wrote: post #34
mjburgess wrote: post #28

Earlier quoted context omitted.

well, i think the issue is as least as much that the developers who create these architectures do not start from this pov --- consider how these architectures would be designed if must-have condition was sub-100ms iteration -- which should be trivial all-but-for codebases of at least 1mil+ lines; them, well, maybe it's 200ms. This design isnt hard -- what's hard about save_frame(), save_state(), or w/e, and restore_s…

Yes, but: Components depend on other components, and they all have to support hot reloading. And what about side effects? For example, an open network connection, or a window. You could store the state (handles etc.), but what about callbacks during the reloading phase? They'd have to block and wait. Ultimately, what you need is a message passing architecture that supports all this. Smalltalk. Alan Kay has been a voc…

Something like COM, XPC or Binder, no need for WebAssembly "re-inventing" it.

Re: C and C++ Hot-Reload/Live Coding

#40

Post by tsmeets »

You don't need anything complicated for this. All you need is to compile your code to a shared library that exports an 'update' method.

See https://github.com/TomSmeets/quest-for-nothing/blob/master/a...

You have to be careful with global variables however, they will get cleared to zero when the code is reloaded. To solve this either don't use globals or just restore them on reload.

Post reply on HN