Interactive Programming in C(nullprogram.com)
nullprogram.com
Interactive Programming in C
http://nullprogram.com/blog/2014/12/23/
10 comments
I highly recommend the Handmade Hero series referred to in this blog post. I've been following the archives on YouTube (at 2x speed). Casey Muratori is an engaging presenter and I'm rediscovering my love of low-level programming.
See also (maybe) Runtime-Compiled C++ https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledC...
I know the Visual Studio C++ debugger has edit-and-continue functionality. It would be nice to read how that is implemented, since it's obviously much more invasive than this.
I don't know how Visual Studio does it, but Apple did implement a feature called "fix and continue" for gdb (it was very dependend on XCode, so it could not be merged to mainline). The implementation was described like this:
"It was pointed out that I never said what F&C _is_. It's a feature for debugging your program, where you can modify your sources mid-debug-session, and the debugger will "patch" in the new code. At a very high level, the source file you're modifying is built as a shared library, gdb executes inferior function calls to load that shared library into the program, gdb finds all old versions of all functions contained in that shared library and writes trampolines in the prologues to jump to the new versions of those functions, and gdb redirects all file-static (including global) variables in that shared library to point to the statics/globals in the original executable."
(From: http://osdir.com/ml/gdb.devel/2003-06/msg00518.html)
"It was pointed out that I never said what F&C _is_. It's a feature for debugging your program, where you can modify your sources mid-debug-session, and the debugger will "patch" in the new code. At a very high level, the source file you're modifying is built as a shared library, gdb executes inferior function calls to load that shared library into the program, gdb finds all old versions of all functions contained in that shared library and writes trampolines in the prologues to jump to the new versions of those functions, and gdb redirects all file-static (including global) variables in that shared library to point to the statics/globals in the original executable."
(From: http://osdir.com/ml/gdb.devel/2003-06/msg00518.html)
[deleted]
can you explain how visual studio do this ? what should I search for learning about it ?
This way of script like interactive programming in C with dynamic libraries is quite known in game programming. The game code in Quake 2, Quake 3, Doom 3, Half Life and even the rendering module in Quake 2 [0] was written that way. In addition to the obvious advantage of interactive programming, dynamic libraries also served as a great way to abstract over submodules like the render and sound engine and made it possible to have a in runtime switchable opengl- and software-renderer.
[0] http://fabiensanglard.net/quake2/quake2Polymorphism.php
[0] http://fabiensanglard.net/quake2/quake2Polymorphism.php
Haven't anyone made a framework along these lines? The main thing I would like this framework to handle for me is cross-platform capability: shared library implementation is different on each operating system, unfortunately for this method.
I have been watching the Handmade Hero stream (and following along by typing the same code locally), but I am behind about 2 weeks. So I was really surprised and delighted to see that this article turned about to be about him and his project.
The way that he is doing cross-platform code for the game is interesting. The platform layer contains main() (or WinMain() in Windows) and is rewritten for each platform. It isn't written as an abstract layer that the game calls. Instead, it sets up a buffer for one frame of video and a circular buffer for sound. Then it calls a function in the game code which is responsible for updating that. The platform code passes a pointer to the video buffer, sound buffer, playing Input (joystick/keyboard), etc. So the game code is completely portable; it is called by the platform code which is native for the actual platform. For example, the Win32 code creates the Window, handles Windows events, initializes DirectSound, and polls XInput for controller state. (It is also why this technique is possible, as they mention, the game layer does not use any external libraries and doesn't allocate its own memory using malloc.)
So, to answer your question: the way to do this, if you're doing the way they do, would be completely different between platforms (Win32 vs unix at the very least), but you don't need to implement it in a generic/abstract way that hides the operating system. They wouldn't write a framework for this. Instead, you would write it into the platform specific code in the (relatively small) platform layer.
The way that he is doing cross-platform code for the game is interesting. The platform layer contains main() (or WinMain() in Windows) and is rewritten for each platform. It isn't written as an abstract layer that the game calls. Instead, it sets up a buffer for one frame of video and a circular buffer for sound. Then it calls a function in the game code which is responsible for updating that. The platform code passes a pointer to the video buffer, sound buffer, playing Input (joystick/keyboard), etc. So the game code is completely portable; it is called by the platform code which is native for the actual platform. For example, the Win32 code creates the Window, handles Windows events, initializes DirectSound, and polls XInput for controller state. (It is also why this technique is possible, as they mention, the game layer does not use any external libraries and doesn't allocate its own memory using malloc.)
So, to answer your question: the way to do this, if you're doing the way they do, would be completely different between platforms (Win32 vs unix at the very least), but you don't need to implement it in a generic/abstract way that hides the operating system. They wouldn't write a framework for this. Instead, you would write it into the platform specific code in the (relatively small) platform layer.
You can do this in Rust too: http://doc.rust-lang.org/std/dynamic_lib/struct.DynamicLibra...
After reading the first few lines of this post, I though it would be some complicated hack about function pointers.
The actual solution is much simpler (to understand and to use, I imagine) and that made me smile, nice one!
The actual solution is much simpler (to understand and to use, I imagine) and that made me smile, nice one!
Incidentally, the Varnish HTTP cache uses this technique; whenever the config is reloaded, the config files are translated to C, compiled to a shared library, and loaded into the running server process.
Nice one. Explains why many people love and use C.
Well, this kind of thing is even easier in the Lisps, in all reality. Your can connect to the live repl and redefine any identifier at runtime.
This has been used to good effect on a few spacecraft, IIRC.
This has been used to good effect on a few spacecraft, IIRC.
Homoiconicity makes this kind of problem much easier, it is true. I remember the story of the spacecraft realtime patch too, fondly!
[deleted]