References

Popular Posts

RAlI - The Silent Guardian of Your C++ Code

Image
RAII - The Silent Guardian of Your C++ Code How a destructor saved my multithreaded system late at night It was late at night. A multithreaded simulation platform had just frozen solid, no crash, no exception, no log entry. Just silence. The kind of silence that means every thread is waiting for every other thread, and nothing will ever move again. A deadlock. The engineer staring at the thread dump traced it back to an early-return path buried three call levels deep. Someone had locked a mutex, hit an error condition, returned immediately, and never unlocked. Under light load the path was never triggered. Under the stress of a parallel workload with dozens of threads hammering the same subsystem, it was only a matter of time. The mutex stayed locked. The threads piled up. The system seized. The lock had been acquired manually. It had been forgotten manually. These two facts were never meant to be separated and yet they were, by twelve lines of error-handling code a...
Read more

Type Erasure in C++

Image
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...
Read more

Circular Dependency: An Anti-Pattern and Techniques to avoid it in object oriented Design

Image
When I attempted to write my first object oriented program with some meaningful complexity I was hit by the problem of cyclic/circular dependency. As the name suggests the problem definition is very simple. If we need to design two classes which need to call functions of each other directly how do we accomplish that? And what are the issues we may land up into if we do not pay proper attention to avoid circular dependency among them. I am sure this problem would have come up with many other programmers like me. In this post I would like to get in depth of this problem and explain why its call an anti-pattern and what are possible approaches to avoid it.
Read more