DEV Community: Alex Rosito

I Built a Useless Data Structure in C++17 and Learned More Than Any Tutorial Taught Me

Alex Rosito — Wed, 29 Apr 2026 05:39:57 +0000

I built this because I was bored. No real use case, no production target — just a C++17 exercise to shake off the rust and explore techniques I knew existed but had never actually used. What I didn't expect was how much the implementation taught me about things I thought I already understood.

The Problem With Homogeneous Lists

Every linked list tutorial shows you the same thing: a list of integers, or a list of strings. The node holds one type, the list holds nodes of that type, done.

That works — until you want a single list to hold an integer, a float, a string, and a custom struct at the same time. Then the standard approach falls apart immediately, because the type is baked into the node at compile time.

The question becomes: how do you build a node that doesn't care what it holds?

The Polymorphic Base — The "Wow" Moment

The answer is a polymorphic base class. Instead of a templated node that holds T directly, you separate the concerns:

// Base class — type-erased, polymorphic
class Object {
public:
    virtual ~Object() = default;
    virtual void print(std::ostream& os) const = 0;
    virtual bool equals(const Object* other) const = 0;
    Object* next = nullptr;
    Object* prev = nullptr;
};

// Derived class — holds the actual value
template <typename T>
class Node : public Object {
public:
    T data;

    explicit Node(T value) : data(value) {}

    void print(std::ostream& os) const override {
        os << data;
    }

    bool equals(const Object* other) const override {
        const Node<T>* otherNode = dynamic_cast<const Node<T>*>(other);
        return otherNode && data == otherNode->data;
    }
};

Object knows nothing about the type it holds — it only defines the interface. Node<T> knows the type, stores the value, and implements the interface.

The list holds Object* pointers. From the list's perspective, every node is an Object. The actual type is invisible at that level — which is exactly what allows the list to be heterogeneous.

When I saw this working for the first time — a single list printing an integer, then a float, then a string, then a struct, all through the same listPrint() call — it was genuinely surprising. Not because it's magic, but because the abstraction is so clean.

`dynamic_cast` — Type-Safe Downcasting at Runtime

This is the part that was completely new to me, and worth documenting carefully.

Once you have a list of Object* pointers, you lose type information at the list level. That's fine for printing — print() is virtual, it dispatches correctly. But what about searching? If I want to find the integer 42 in a mixed list, I need to:

Skip nodes that aren't integers
Compare only against nodes that actually hold int

This is exactly what dynamic_cast does:

template <typename T>
Object* dlList::searchNodeInList(T value) {
    Object* current = head;
    while (current != nullptr) {
        Node<T>* typedNode = dynamic_cast<Node<T>*>(current);
        if (typedNode && typedNode->data == value) {
            return current;
        }
        current = current->next;
    }
    return nullptr;
}

dynamic_cast<Node<T>*>(current) attempts to cast the Object* pointer to a Node<T>*. If the actual runtime type of the object is Node<T> — it succeeds and returns a valid pointer. If the actual type is something else — Node<float>, Node<std::string> — it returns nullptr.

That nullptr check is the type filter. No exceptions, no undefined behavior — just a null pointer when the types don't match.

This is the critical distinction from static_cast: static_cast trusts you at compile time. dynamic_cast verifies at runtime. In a heterogeneous container where you genuinely don't know the runtime type of a node, dynamic_cast is the correct tool — static_cast would be undefined behavior waiting to happen.

One requirement: the base class must have at least one virtual function. Without it, the compiler doesn't generate the runtime type information (RTTI) needed for dynamic_cast to work. The virtual destructor in Object satisfies this.

Operator Overloading for Custom Types — Still Somewhat Esoteric

For built-in types like int, float, and std::string, everything works out of the box — operator<< and operator== are already defined. But for a custom struct, you have to teach the compiler how to handle it.

typedef struct {
    int x;
    float y;
    char z;
} myStruct;

// Teach std::ostream how to print myStruct
std::ostream& operator<<(std::ostream& os, const myStruct& s) {
    os << s.x << " " << s.y << " " << s.z;
    return os;
}

// Teach the compiler how to compare two myStructs
bool operator==(const myStruct& a, const myStruct& b) {
    return a.x == b.x && a.y == b.y && a.z == b.z;
}

The operator<< overload is what allows Node<myStruct>::print() to call os << data without knowing anything about myStruct at compile time — as long as that overload exists, the template resolves correctly.

The stream-based syntax (os << s.x << " " << s.y) still feels somewhat counter-intuitive — you're chaining calls on an object that represents an output stream, returning a reference to itself at each step so the chain can continue. It works, it's idiomatic C++, but it takes some time before it stops feeling like incantation.

The operator== overload is what allows dynamic_cast plus value comparison to work in searchNodeInList. Without it, typedNode->data == value wouldn't compile for custom types.

The requirement is clear: any type you want to store in dllist must implement both. This is enforced at compile time — if you try to store a type that doesn't have them, the compiler tells you exactly which operator is missing.

Memory Management — Clearer Than Its Reputation

Manual memory management in C++ has a reputation for being treacherous. In practice, for a data structure with a clear ownership model, it's straightforward — as long as you follow one rule: whoever allocates, deallocates.

Insertion:

template <typename T>
void dlList::listAppend(T value) {
    Node<T>* newNode = new Node<T>(value);  // heap allocation
    if (head == nullptr) {
        head = tail = newNode;
    } else {
        newNode->prev = tail;
        tail->next = newNode;
        tail = newNode;
    }
}

Deletion of a single node:

void dlList::deleteNode(Object* node) {
    if (node->prev) node->prev->next = node->next;
    else head = node->next;

    if (node->next) node->next->prev = node->prev;
    else tail = node->prev;

    delete node;  // heap deallocation
}

Destructor — cleans up everything:

dlList::~dlList() {
    Object* current = head;
    while (current != nullptr) {
        Object* next = current->next;
        delete current;
        current = next;
    }
}

The key detail in the destructor: save current->next before deleting current. After delete current, that memory is gone — accessing current->next afterward is undefined behavior. One line of discipline prevents the entire class of use-after-free errors.

delete on an Object* that points to a Node<T> calls the correct destructor because ~Object() is virtual. Without the virtual destructor, delete on a base pointer would only call the base destructor — leaking whatever the derived class allocated. This is another reason the virtual destructor in Object is not optional.

What This Exercise Actually Taught Me

Building something redundant — std::list and std::variant already cover this problem more efficiently — turned out to be more instructive than using the standard library version would have been.

The standard library hides the machinery. Building it yourself forces you to confront exactly why each piece exists:

The polymorphic base exists because templates alone can't provide runtime type erasure
dynamic_cast exists because downcasting without runtime verification is unsafe by definition
The virtual destructor exists because delete on a base pointer without it is undefined behavior
Operator overloading exists because templates need the compiler to resolve operations on T — and for custom types, you have to tell it how

None of this is new knowledge in the sense that it's in every C++ book. But there's a difference between reading about it and building something where removing any one of these pieces breaks the entire structure in a specific and instructive way.

The Code

GitHub: https://github.com/AlexRosito67/heterogeneous-double-linked-list
Pure C++17, no dependencies, CMake build
Intended as a learning reference, not a production library

If this was useful, there's a Buy Me a Coffee link on the GitHub page.

Alex Rosito — self-taught electronics engineer and C++ developer. ATtiny85 · ESP32 · KiCad · C++

Why Most 74HC595 Display Drivers Flicker (And How QUAD7SHIFT Avoids It Without Trying)

Alex Rosito — Wed, 29 Apr 2026 02:51:26 +0000

A Chinese technical site cited QUAD7SHIFT as a flicker-free reference implementation. I didn't design it to solve flicker. I just built it correctly.

The Problem Nobody Talks About

Search for "74HC595 7-segment display Arduino" and you'll find dozens of tutorials. Most of them work — in the sense that the display shows numbers. But watch closely under fluorescent lighting, or point a camera at it, and you'll see it: a faint but persistent flicker, sometimes a ghost of the previous digit bleeding into the next.

This isn't a power supply issue. It isn't a loose connection. It's a structural problem in how most drivers handle the latch.

How the Naive Pattern Works

The typical approach looks something like this:

// Naive pattern — found in most tutorials
void showDigit(uint8_t segments, uint8_t digitSelect) {
    digitalWrite(LATCH_PIN, LOW);
    shiftOut(DATA_PIN, CLOCK_PIN, MSBFIRST, segments);   // first transfer
    shiftOut(DATA_PIN, CLOCK_PIN, MSBFIRST, digitSelect); // second transfer
    digitalWrite(LATCH_PIN, HIGH);
}

Two separate shiftOut() calls, then a single latch pulse. Looks fine. The problem is what happens between those two calls.

When the first shiftOut() completes, the shift register holds the new segment data — but the latch hasn't fired yet. At that exact moment, the previous digit select is still active in the storage register. If anything delays the second shiftOut() — an interrupt, a timer ISR, a millisecond of jitter — the display briefly shows the new segment pattern on the wrong digit.

That's ghosting. And even without interrupts, the asymmetry in timing between two sequential software calls is enough to produce uneven brightness across digits.

There's a deeper issue underneath this: shiftOut() is pure software bit-banging.
It drives the clock and data pins manually, one bit at a time, in a tight loop — with no hardware assistance and no atomicity guarantees. On any AVR running with interrupts enabled (which is the default — millis() depends on it), a timer ISR can fire between any two clock pulses. The transfer is not protected. This makes the window between the two shiftOut() calls not just a timing inconvenience but a structural vulnerability: the longer and more interrupt-prone your environment, the more likely you are to see artifacts.

Hardware SPI — used by QUAD7SHIFT via SPI.transfer16() — is handled by a dedicated peripheral that runs independently of the CPU. It cannot be interrupted mid-transfer by software. The 16 bits go out clean, every time.

The Timing Problem Visualized

Naive approach — two 74HC595 chips, sequential transfers:

Time →

LATCH:   ___LOW_________________________HIGH___
SRCLK:        ↑↑↑↑↑↑↑↑  ↑↑↑↑↑↑↑↑
DATA:    [segments byte ] [digit select byte ]
                         ↑
                    HERE: shift reg 1 has new segments.
                    Storage reg still holds OLD digit select.
                    Any interrupt here = ghost on wrong digit.

QUAD7SHIFT — single 16-bit atomic transfer:

Time →

LATCH:   ___LOW___________________HIGH___
SRCLK:        ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
DATA:    [segments byte | digit select byte]
                                 ↑
                    Both bytes shift as one unit.
                    Latch fires once. No intermediate state.

What QUAD7SHIFT Does Instead

The hardware is two 74HC595s in cascade — one controls the segment lines (a–g, dp), the other controls which digit is active (digit select bits). The key is that both chips share a single latch line (RCLK).

The entire transfer is packed into a single uint16_t:

void QUAD7SHIFT::transferDigit(uint16_t result) {
    writePin(LATCHPIN, LOW);

    #if defined(__AVR_ATmega328P__) || (__AVR_ATmega168__)
        SPI.beginTransaction(SPISettings(1000000, LSBFIRST, SPI_MODE0));
        SPI.transfer16(result);   // both bytes in one SPI transaction
        SPI.endTransaction();
    #endif

    writePin(LATCHPIN, HIGH);     // single latch pulse — both registers update simultaneously
}

SPI.transfer16() shifts all 16 bits in one continuous hardware transaction. The latch fires exactly once. There is no intermediate state where one register has new data and the other doesn't.

For ATtiny85, which lacks hardware SPI and uses the USI (Universal Serial Interface), the same principle applies — two usiTransferByte() calls back to back with the latch held LOW throughout:

void QUAD7SHIFT::transferDigit(uint16_t result) {
    writePin(LATCHPIN, LOW);
    usiTransferByte(reverseBits(result & 0xFF));         // segments
    usiTransferByte(reverseBits((result >> 8) & 0xFF));  // digit select
    writePin(LATCHPIN, HIGH);
}

The latch is LOW for the entire duration of both transfers. The storage registers don't see anything until the latch goes HIGH — at which point both update atomically.

Why This Works: The 74HC595 Latch Mechanism

The 74HC595 has two internal registers:

Shift register — receives serial data on each SRCLK rising edge
Storage register — holds the parallel output, only updates on RCLK rising edge

When LATCH (RCLK) is LOW, data shifting into the shift register has zero effect on the outputs. The outputs are frozen. You can shift as much data as you want — through one chip, through ten chips in cascade — and nothing changes on the output pins until you pulse the latch HIGH.

This is the mechanism. The naive pattern doesn't violate it, but it does use it sloppily — latching between two logical operations instead of after both are complete.

QUAD7SHIFT latches once, after all 16 bits are in place.

The Multiplexing Loop

Eliminating ghosting on each individual transfer is necessary but not sufficient. You also need a stable refresh cycle.

The naive approach typically calls the display function from loop(), which means refresh rate is coupled to whatever else loop() is doing. If you add a sensor read or a serial print, the display dims or flickers because some digits get fewer refresh cycles per second.

QUAD7SHIFT decouples refresh rate from loop() timing:

void QUAD7SHIFT::printNumber(uint16_t number, uint8_t decimalPointPosition) {
    // ... digit extraction ...

    unsigned long endtime = millis() + _refreshRate;
    uint8_t i = 0;

    while (millis() <= endtime) {
        printDigit(digitsToPrint[i], i, i == decimalPointPosition);
        i = (i + 1) % numberOfDigitsToDisplay;
    }
}

Each call to print() runs the multiplexing loop for exactly _refreshRate milliseconds, cycling through all digits at a consistent rate regardless of what happened before or after. The display gets a guaranteed time slice.

See It Running

Comparison Summary

	Naive pattern	QUAD7SHIFT
Latch pulses per digit update	1 (but between two transfers)	1 (after both transfers complete)
Intermediate state where ghost can appear	Yes	No
Refresh rate coupled to `loop()`	Yes	No — fixed time slice
Works on ATtiny85	Depends on implementation	Yes (USI, bit-reversal handled)
Hardware SPI on AVR	Sometimes	Yes (`SPI.transfer16`)

I Didn't Design This to Solve Flicker

Worth being explicit about this: I didn't build QUAD7SHIFT by identifying the ghost problem and engineering a solution. I built it by reading the 74HC595 datasheet, understanding that the latch is what separates "data in transit" from "data on outputs," and constructing the transfer accordingly.

The flicker never appeared because the design never created the conditions for it.

A Chinese technical site (CSDN, April 2026) independently analyzed cascaded 74HC595 display drivers and cited QUAD7SHIFT as a reference implementation for eliminating flicker — specifically noting its "dynamic scan algorithm." They found the pattern by looking for the problem. I found it by not creating the problem in the first place.

Both paths lead to the same place. But I think the second one is more instructive: correct hardware abstractions tend to be correct in ways you didn't plan for.

The Library

QUAD7SHIFT is available on GitHub and in the Arduino Library Manager.

GitHub: https://github.com/AlexRosito67/QUAD7SHIFT
Supports Arduino Uno, Nano, and ATtiny85
Common anode and common cathode displays
Configurable refresh rate
String display, float, and integer overloads