The handle is so light! Active tips! Heats up in 2 seconds. Goes to standby mode when you put away the handle to save the tips.
There's even a lighter compatible precision handle that you can buy.
Luke Gorrie posted a bunch of Twitter threads where he compare the sizes of soldering handles. Can't find it now but https://github.com/lukego/soldering might lead you to them.
I'm still using Sourcetrail daily for inspecting C++ codebases. Works great. I paid for the first beta and was very sad that the company was not profitable. It really is a great product.
Rico Mariani gives his opinions on the future of system programming languages.
His main point is that C++ with EH introduces too much bloat; that the opaque error handling combined with no compiler assisted checking hides bugs; and that you can't write C++ codes from "the books" since it leads to more bugs!
With Rust you can write it like in the books!
"Modern C++ has so many hazards and is so costly that I can't but view it as anything less than a total failure in the systems space. I can't begin to tell you how disappointing this is to me. "
If someone is interested in what's being done to improve LLVMs debuginfo, here's a talk by Djordje Todorovic from two years ago: https://www.youtube.com/watch?v=GpMLt1oecOk. It's about tracking dwarf locations for variables by keeping around information from the parent frame. According to that presentation, at least that work has been progressing.
How does his KUTrace Linux kernel patches differ from the existing tracing infrastructure? This talk [1] seems to suggest that the reason his KUTrace is so fast is because the other tracers collect more information.
How does the tracing capabilities here compared to what the Windows WPA subsystem can offer? Does it have less overhead for collecting such traces?
Sampling profilers like Superluminal claims to be able to recognize very small delays. For how many cases do you need something like KUTrace and when is Superluminal enough?
* The exceptional path is slow (00:10:23). Facebook was using exceptions to signal parsing errors, which turned out to be too slow when dealing with loosely formatted input. Facebook found that using exceptions in this way increased the cost of parsing a file by 50x (00:10:42). No real surprise here, this is also a common pattern in the Java world and clearly the wrong way to do it. Exceptions are for the exceptional.
* Exceptions require immediate and exclusive attention (00:11:28). To me, this is a killer argument for errors over exceptions. With exceptions, you can be in your normal control flow, or the exceptional control flow, not both. You have to deal with the exception at the point it occurs, even if that exception is truly exceptional. You cannot easily stash the first exception and do some cleanup if that may itself throw an exception.
More context to that quote:
>Per Vognsen discusses how to do course-grained error handling in C using setjmp/longjmp. The use case there were for arena allocations and deeply nested recursive parsers. It’s very similar to how C++ does exception handling, but without the downsides of the costly C++ memory deallocation on stack unwinding.
I have never used setjmp/longjmp myself. And I agree with you that my first instinct would be to use it in the similar manner as in many GUI programs: they have have a catch statement in the message loop that shows a dialog box of the thrown exception. You just jump to a point where you print a user friendly error message and exit.
But I still can imagine use cases where you've isolated all other side effects (locks, shared memory, open file handles) and are just dealing with a buffer that you parse. Has anyone used setjmp/longjmp for that around here?
Given your many years in the field and Cygnus background I guess you've used it a few times? Do you happen to have any horror stories related to it? :-)
I hate setjmp/longjmp and have never needed it in production code.
Think about how it works: it copies the CPU state (basically the registers: program counter, stack pointer, etc). When you longjmp back the CPU is set back to the call state, but any side effects in memory etc are unchanged. You go back in time yet the consequences of prior execution are still lying around and need to be cleaned up. It's as if you woke up, drove to work, then longjmped yourself back home -- but your car was still at work, your laptop open etc.
Sure, if you're super careful you can make sure you handle the side effects of what happened while the code was running, but if you forget one you have a problem. Why not use the language features designed to take care of those problems for you?
This sort of works in a pool-based memory allocator.
The failures happen three ways: one is you forget something and so you have a leak. The second is that you haven't registered usage properly so have a dangling pointer. Third is by going back in time you lose access to and the value of prior and/or partial computation.
If you use this for a library, and between the setjmp and longjmp is entirely in a single invocation you can sometimes get away with it. But in a thing like a memory allocator where the user makes successive calls, unless you force the user to do extra work you can't be sure what dependencies on the memory might exist. If your library uses callbacks you can be in a world of hurt.
Trying to keep track of all those fiddly details is hard. C++ does it automatically, at the risk of potentially being more careful (e.g. deallocating two blocks individually rather than in one swoop -- oh, but that language has an allocator mechanism precisely to avoid this problem). The point is the programmer doesn't have to remember anything to make it work.
The handle is so light! Active tips! Heats up in 2 seconds. Goes to standby mode when you put away the handle to save the tips.
There's even a lighter compatible precision handle that you can buy.
Luke Gorrie posted a bunch of Twitter threads where he compare the sizes of soldering handles. Can't find it now but https://github.com/lukego/soldering might lead you to them.