3 ms·

It's not (just) a low-level synchronization problem, though; it's a larger structural problem. Simple example: If someone has a reference to your function that

It's not (just) a low-level synchronization problem, though; it's a larger structural problem. Simple example: If someone has a reference to your function that free()s some pointer, and your function has been replaced with an inert no-op, that pointer is no longer freed when it should be, and you have a memory leak. Extrapolate this to more complex code. Put another way, assume that you solve low-level threadsafety/data race issues. You still have to design the library from the start to be unloadable; you can't unload code that isn't expecting to be unloaded without undesirable side effects.

slaymaker1907 4y ago
You typically wouldn't replace a function with a no-op since changing who allocs/frees memory is almost certainly an API change which I never claimed my solution would support. The thing my solution would be useful for is for fixing small errors that are tedious to go through a whole compile cycle for. It would be a replacement for modifying values directly in the debugger to try and fix issues (to see if the fix works) and not turn C++ into LISP.