The Derivative That Saw It Coming Calculus · CodePuz · ~10 min read Some of the slowest days of my career happened on a pre-silicon platform, watching an OS boot that refused to hurry up. Pre-silicon emulation is not fast. A single boot can take hours, sometimes the better part of a day, depending on the platform and what's being modeled underneath. So when a performance optimization landed and the question was simple, "did this actually help?", the honest answer was often "ask me tomorrow." Nobody wants to wait a full day to find out a change made things worse. What actually helped was tracking a progress metric over time and watching how fast it was climbing, not just where it stood. Two boots can look nearly identical an hour in. One of them is quietly pulling ahead, and the raw numbers won't tell you that story. The rate at which those numbers are changing will. That rate has a name. It's a derivative. And o...

One Box, Any Type: Understanding Type Erasure in C++ Or: How std::function stores a lambda, a function pointer, and a functor in the same box C++ rewards precise thinking about types. Most of the time, that precision is a feature. But occasionally the type system and the design pull in opposite directions, and the compiler rejects code that is, by every conceptual measure, reasonable. Consider a transaction monitor for a SystemC simulation. Every time a TLM transaction arrives, four separate objects need to respond: a Logger records it, a LatencyTracker measures it, a ProtocolChecker validates it, a CoverageCollector bins it. They share no base class, and they shouldn't need one. What they have in common is purely behavioral: they all respond to a transaction. So the obvious thing gets written: std :: vector < TransactionHandler > handlers ; handlers . push_back ( Logger {}); handlers . push_back ( LatencyTracker {}); handlers . push_back ( Pr...