Abstract classes and interfaces in C++

The Checkout of this lesson charges 2,499.00 to a card and 999.00 to a wallet, and its five tests run against a fake that records every charge without touching either. It can do both because it depends on nothing but an interfaceinterface: In C++, a class with only pure virtual functions and a public virtual destructor, and no data: it says what a type can do and leaves how to the classes that implement it. C++ has no interface keyword; this is a convention.: a class of pure virtual functions that says what a payment method can do and leaves how to each class that implements it.

You will make a class abstract with pure virtual functions, build that interface and the fake that tests the code using it, keep checks and logging in one place with the non-virtual interface idiom, and see what happens when a pure virtual function is called anyway. Every example runs on Apple clang 21 and GCC 16.

Pure virtual functions make a class abstract

An abstract classabstract class: A class with at least one pure virtual function that it has not overridden. No object of it can be created, not even as a by-value parameter, but references and pointers to it can refer to objects of its concrete derived classes. is a class with at least one pure virtual functionpure virtual function: A virtual function declared with = 0 instead of a body, as in virtual std::string name() const = 0;. It makes its class abstract, and each derived class must override it before objects of that class can be created., a virtual function declared with = 0 instead of a body: virtual std::string name() const = 0;. It states what every derived class must be able to do without saying how, and the compiler refuses to create an object of it. A derived class becomes usable, or concrete, once it overrides every pure virtual function it inherits. payment.h declares the interface PaymentMethod and a Checkout that uses nothing else:

// An interface for ways to pay, and a checkout that only knows the interface.
#pragma once
#include <cstdint>
#include <format>
#include <string>

using Money = std::int64_t;  // in the smallest unit of the currency (paise, cents)

// Every way to pay can charge an amount and say what it is called. How it does that is up to each class.
class PaymentMethod {
public:
    virtual ~PaymentMethod() = default;
    // Charges amount for an order; returns a transaction id, or an empty string when the payment is declined.
    virtual std::string charge(Money amount, const std::string& order_id) = 0;
    virtual std::string name() const = 0;
};

// The checkout works with any PaymentMethod: it never names a concrete class.
class Checkout {
public:
    explicit Checkout(PaymentMethod& method) : method_(method) {}

    std::string pay(const std::string& order_id, Money amount) {
        if (amount <= 0) return std::format("{}: nothing to pay", order_id);
        const std::string transaction = method_.charge(amount, order_id);
        if (transaction.empty()) return std::format("{}: {} declined", order_id, method_.name());
        return std::format("{}: paid {}.{:02} by {} ({})", order_id, amount / 100, amount % 100, method_.name(),
                           transaction);
    }

private:
    PaymentMethod& method_;
};

PaymentMethod has no data and no code, only promises: anything that is a PaymentMethod can charge() an amount and report its name(). Because it is abstract, neither the interface itself nor a class that keeps one of its pure virtual functions can be created:

// Neither the interface nor a class that overrides only part of it can be created.
#include <string>

#include "payment.h"

class GiftCard : public PaymentMethod {
public:
    std::string charge(Money, const std::string&) override { return "gift"; }
    // name() is not overridden, so GiftCard is still abstract
};

int main() {
    PaymentMethod method;
    GiftCard card;
}

from session import run

# abstract_errors.cpp with both compilers.
run("""
clang++ -std=c++23 -Wall -Wextra -c abstract_errors.cpp
g++-16 -std=c++23 -Wall -Wextra -c abstract_errors.cpp
""")

$ clang++ -std=c++23 -Wall -Wextra -c abstract_errors.cpp
abstract_errors.cpp:13:19: error: variable type 'PaymentMethod' is an abstract class
   13 |     PaymentMethod method;
      |                   ^
./payment.h:14:25: note: unimplemented pure virtual method 'charge' in 'PaymentMethod'
   14 |     virtual std::string charge(Money amount, const std::string& order_id) = 0;
      |                         ^
./payment.h:15:25: note: unimplemented pure virtual method 'name' in 'PaymentMethod'
   15 |     virtual std::string name() const = 0;
      |                         ^
abstract_errors.cpp:14:14: error: variable type 'GiftCard' is an abstract class
   14 |     GiftCard card;
      |              ^
./payment.h:15:25: note: unimplemented pure virtual method 'name' in 'GiftCard'
   15 |     virtual std::string name() const = 0;
      |                         ^
2 errors generated.
[exit status 1]
$ g++-16 -std=c++23 -Wall -Wextra -c abstract_errors.cpp
abstract_errors.cpp: In function 'int main()':
abstract_errors.cpp:13:19: error: cannot declare variable 'method' to be of abstract type 'PaymentMethod'
   13 |     PaymentMethod method;
      |                   ^~~~~~
In file included from abstract_errors.cpp:4:
payment.h:10:7: note: because the following virtual functions are pure within 'PaymentMethod':
   10 | class PaymentMethod {
      |       ^~~~~~~~~~~~~
  • 'virtual std::string PaymentMethod::charge(Money, const std::string&)'
    payment.h:14:25:
       14 |     virtual std::string charge(Money amount, const std::string& order_id) = 0;
          |                         ^~~~~~
  • 'virtual std::string PaymentMethod::name() const'
    payment.h:15:25:
       15 |     virtual std::string name() const = 0;
          |                         ^~~~
abstract_errors.cpp:14:14: error: cannot declare variable 'card' to be of abstract type 'GiftCard'
   14 |     GiftCard card;
      |              ^~~~
abstract_errors.cpp:6:7: note: because the following virtual functions are pure within 'GiftCard':
    6 | class GiftCard : public PaymentMethod {
      |       ^~~~~~~~
  • 'virtual std::string PaymentMethod::name() const'
    payment.h:15:25:
       15 |     virtual std::string name() const = 0;
          |                         ^~~~
[exit status 1]

Both compilers name every function that is still missing. GiftCard overrides charge() but not name(), so it inherits a pure virtual function and stays abstract. Follow the three classes of this lesson from abstract to concrete:

The rule reaches wherever an object of the class would have to exist. A function may even be declared with an abstract class as a by-value parameter or return type, but defining such a function does not compile, and neither does passing an object to such a parameter, because each would need an object of the abstract class. References and pointers to an abstract class are fine, and they are how an interface is used.

An interface is a pure abstract class

Two real implementations, and a Checkout for each:

// Two implementations of PaymentMethod, used by the same Checkout.
#include <format>
#include <print>
#include <string>
#include <utility>

#include "payment.h"

class CardPayment : public PaymentMethod {
public:
    explicit CardPayment(std::string last_digits) : last_digits_(std::move(last_digits)) {}
    std::string charge(Money amount, const std::string& order_id) override {
        // A real class would call the card network here. This one approves amounts up to 50,000.00.
        if (amount > 5'000'000) return "";
        return std::format("card-{}-{}", order_id, ++count_);
    }
    std::string name() const override { return "card ending " + last_digits_; }

private:
    std::string last_digits_;
    int count_ = 0;
};

class WalletPayment : public PaymentMethod {
public:
    explicit WalletPayment(Money balance) : balance_(balance) {}
    std::string charge(Money amount, const std::string& order_id) override {
        if (amount > balance_) return "";
        balance_ -= amount;
        return "wallet-" + order_id;
    }
    std::string name() const override { return std::format("wallet ({}.{:02} left)", balance_ / 100, balance_ % 100); }

private:
    Money balance_;
};

int main() {
    CardPayment card{"4242"};
    WalletPayment wallet{120'000};

    Checkout by_card{card};
    Checkout by_wallet{wallet};
    std::println("{}", by_card.pay("A-1001", 249'900));
    std::println("{}", by_wallet.pay("A-1002", 99'900));
    std::println("{}", by_wallet.pay("A-1003", 99'900));
}

from session import run

# checkout.cpp built and run with both compilers.
run("""
clang++ -std=c++23 -Wall -Wextra checkout.cpp -o checkout && ./checkout
g++-16 -std=c++23 -Wall -Wextra checkout.cpp -o checkout-gcc && ./checkout-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra checkout.cpp -o checkout && ./checkout
A-1001: paid 2499.00 by card ending 4242 (card-A-1001-1)
A-1002: paid 999.00 by wallet (201.00 left) (wallet-A-1002)
A-1003: wallet (201.00 left) declined
$ g++-16 -std=c++23 -Wall -Wextra checkout.cpp -o checkout-gcc && ./checkout-gcc
A-1001: paid 2499.00 by card ending 4242 (card-A-1001-1)
A-1002: paid 999.00 by wallet (201.00 left) (wallet-A-1002)
A-1003: wallet (201.00 left) declined

Checkout was written without knowing that cards or wallets exist. It calls charge() and name() through its PaymentMethod&, and each call runs the override of the object it was given: the card approves 2,499.00, the wallet pays 999.00 and then declines the same amount, because only 201.00 is left. Step through the three payments:

The drawing shows the same design as dependencies: Checkout points at the interface only, and every implementation hangs below it.

A good interface in C++ looks like PaymentMethod:

• Only pure virtual functions. Rule C.121 of the C++ Core Guidelines says that a base class used as an interface should be a pure abstract class, and rule I.25 prefers such empty classes to hierarchies that carry data.
• A public virtual destructor, so that an implementation can be deleted through the interface, for example by a std::unique_ptr<PaymentMethod>. If you declare it pure, virtual ~PaymentMethod() = 0;, you must still define it outside the class, because the destructor of every derived class calls it.
• No data members and no constructors. Data belongs to the implementations, which keeps the interface stable when they change.

Rule C.129 of the Guidelines names the distinction behind this: inheriting an interface promises what a class can do, while inheriting an implementation reuses code. An interface keeps the two apart, so a class can implement it without inheriting anything it did not ask for.

A fake tests the code without the real thing

The real payment classes would contact a card network or a wallet service. A test does not need either, because Checkout only depends on the interface. A fakefake: A small implementation of an interface written for tests, such as a payment method that approves or declines on command and records every charge, so that a test can run the code without the real service and check how it was used. is a small implementation written for tests: this one approves or declines on command and records every charge it receives.

// Tests for Checkout with a fake PaymentMethod: no card network, no wallet, and every call is recorded.
#include <print>
#include <string>
#include <vector>

#include "payment.h"

// A fake: it approves or declines as the test says, and remembers what it was asked to do.
class FakePayment : public PaymentMethod {
public:
    bool approve = true;
    std::vector<Money> charged;

    std::string charge(Money amount, const std::string& order_id) override {
        charged.push_back(amount);
        return approve ? "fake-" + order_id : "";
    }
    std::string name() const override { return "fake"; }
};

namespace {
int checks = 0;
int passed = 0;

void check(bool ok, const char* what) {
    ++checks;
    if (ok) ++passed;
    else std::println("FAILED: {}", what);
}
}  // namespace

int main() {
    FakePayment fake;
    Checkout checkout{fake};

    check(checkout.pay("T-1", 12'345) == "T-1: paid 123.45 by fake (fake-T-1)", "an approved payment is reported");
    check(fake.charged == std::vector<Money>{12'345}, "the method is charged once, with the exact amount");

    fake.approve = false;
    check(checkout.pay("T-2", 500) == "T-2: fake declined", "a declined payment is reported");

    check(checkout.pay("T-3", 0) == "T-3: nothing to pay", "a zero amount needs no payment");
    check(fake.charged.size() == 2, "a zero amount never reaches the payment method");

    std::println("{} of {} checks passed", passed, checks);
    return passed == checks ? 0 : 1;
}

from session import run

# The tests built with both compilers, the first build with the sanitizers on.
run("""
clang++ -std=c++23 -Wall -Wextra -fsanitize=address,undefined checkout_tests.cpp -o checkout_tests && ./checkout_tests
g++-16 -std=c++23 -Wall -Wextra checkout_tests.cpp -o checkout_tests-gcc && ./checkout_tests-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra -fsanitize=address,undefined checkout_tests.cpp -o checkout_tests && ./checkout_tests
5 of 5 checks passed
$ g++-16 -std=c++23 -Wall -Wextra checkout_tests.cpp -o checkout_tests-gcc && ./checkout_tests-gcc
5 of 5 checks passed

Step through the test and watch what the fake records at each payment:

The tests check more than return values. They check how Checkout used the interface: one charge per payment, the exact amount, and no charge at all for an order that costs nothing. A fake makes such questions easy to ask, and the run takes no time and needs no network. The first build also runs under AddressSanitizer and UndefinedBehaviorSanitizer, which reported nothing.

The cost of this design is small but real: every call through the interface is a virtual call, and each implementation is a separate class. For code where that cost matters, later modules show interfaces checked at compile time, with templates and concepts.

The non-virtual interface idiom keeps the checks in one place

Every exporter of a report should refuse an empty report and log each export the same way. If those steps live in each derived class, one of them will forget them. The non-virtual interface idiomnon-virtual interface idiom (NVI): A design in which a base class's public function is not virtual: it runs the steps every implementation shares, such as checks and logging, and calls private virtual hooks that derived classes override for the part that differs. (NVI) puts them in the base class instead: the public function is not virtual and does the shared work, and it calls private virtual functions, the hooks, for the part that differs.

// The non-virtual interface idiom: export_report() is public and not virtual. It checks the report and writes the
// log lines, once, for every format. Derived classes override only the private hooks.
#include <array>
#include <print>
#include <string>
#include <vector>

struct Report {
    std::string title;
    std::vector<int> values;
};

class Exporter {
public:
    virtual ~Exporter() = default;

    // The only way in: the same check and the same log lines for every format.
    bool export_report(const Report& report) const {
        if (report.values.empty()) {
            std::println("[{}] refused \"{}\": no values", format_name(), report.title);
            return false;
        }
        std::println("[{}] exporting \"{}\" ({} values)", format_name(), report.title, report.values.size());
        const std::string body = write_body(report);
        std::println("{}", body);
        std::println("[{}] done, {} bytes", format_name(), body.size());
        return true;
    }

private:
    // The hooks: each format decides what they do, but never when they run.
    virtual std::string format_name() const = 0;
    virtual std::string write_body(const Report& report) const = 0;
};

class CsvExporter : public Exporter {
private:
    std::string format_name() const override { return "csv"; }
    std::string write_body(const Report& report) const override {
        std::string out = "title,value";
        for (int v : report.values) out += "\n" + report.title + "," + std::to_string(v);
        return out;
    }
};

class JsonExporter : public Exporter {
private:
    std::string format_name() const override { return "json"; }
    std::string write_body(const Report& report) const override {
        std::string out = "{\"title\":\"" + report.title + "\",\"values\":[";
        for (std::size_t i = 0; i < report.values.size(); ++i) out += (i > 0 ? "," : "") + std::to_string(report.values[i]);
        return out + "]}";
    }
};

int main() {
    const CsvExporter csv;
    const JsonExporter json;
    const std::array<const Exporter*, 2> exporters{&csv, &json};

    const Report sales{"sales", {120, 95}};
    const Report returns{"returns", {}};
    for (const Exporter* e : exporters) {
        e->export_report(sales);
        e->export_report(returns);
    }
#ifdef CALL_HOOK
    csv.write_body(sales);  // outside code cannot skip the checks
#endif
}

from session import run

# exporter.cpp built and run with both compilers, then with -DCALL_HOOK, which calls a hook directly.
run("""
clang++ -std=c++23 -Wall -Wextra exporter.cpp -o exporter && ./exporter
g++-16 -std=c++23 -Wall -Wextra exporter.cpp -o exporter-gcc && ./exporter-gcc
clang++ -std=c++23 -Wall -Wextra -DCALL_HOOK -c exporter.cpp
g++-16 -std=c++23 -Wall -Wextra -DCALL_HOOK -c exporter.cpp
""", max_lines=14)

$ clang++ -std=c++23 -Wall -Wextra exporter.cpp -o exporter && ./exporter
[csv] exporting "sales" (2 values)
title,value
sales,120
sales,95
[csv] done, 30 bytes
[csv] refused "returns": no values
[json] exporting "sales" (2 values)
{"title":"sales","values":[120,95]}
[json] done, 35 bytes
[json] refused "returns": no values
$ g++-16 -std=c++23 -Wall -Wextra exporter.cpp -o exporter-gcc && ./exporter-gcc
[csv] exporting "sales" (2 values)
title,value
sales,120
sales,95
[csv] done, 30 bytes
[csv] refused "returns": no values
[json] exporting "sales" (2 values)
{"title":"sales","values":[120,95]}
[json] done, 35 bytes
[json] refused "returns": no values
$ clang++ -std=c++23 -Wall -Wextra -DCALL_HOOK -c exporter.cpp
exporter.cpp:68:9: error: 'write_body' is a private member of 'CsvExporter'
   68 |     csv.write_body(sales);  // outside code cannot skip the checks
      |         ^
exporter.cpp:39:17: note: declared private here
   39 |     std::string write_body(const Report& report) const override {
      |                 ^
1 error generated.
[exit status 1]
$ g++-16 -std=c++23 -Wall -Wextra -DCALL_HOOK -c exporter.cpp
exporter.cpp: In function 'int main()':
exporter.cpp:68:19: error: 'virtual std::string CsvExporter::write_body(const Report&) const' is private within this context
   68 |     csv.write_body(sales);  // outside code cannot skip the checks
      |     ~~~~~~~~~~~~~~^~~~~~~
exporter.cpp:39:17: note: declared private here
   39 |     std::string write_body(const Report& report) const override {
      |                 ^~~~~~~~~~
[exit status 1]

Step through one call of export_report() for each report, then the build that tries to skip it:

CsvExporter and JsonExporter contain no checks and no log lines, yet both refuse the empty “returns” report and log every export in the same words, because only Exporter::export_report() is public. The derived classes override private functions, which surprises many people: access controls who may call a function, not who may override it. The standard checks access at the call, with the static type, so export_report() may call its own private hooks and outside code may not, as the last two builds show.

The C++ FAQ of the Standard C++ Foundation describes this design under private virtuals: public non-virtual functions define the interface, and private or protected virtual functions define what derived classes may customise. Use it when every implementation must follow the same steps, such as checks, logging, locking or timing.

A pure virtual call during construction is undefined behaviour

A pure virtual function has no body to run. Normally no call can reach it, because every object you can create has overridden it, but there is one moment when the object is still only the abstract class: during the base class’s constructor and destructor.

// Job's constructor calls start(), which calls the pure virtual function title(). While Job is being constructed,
// the object is only a Job, and Job has no title().
#include <print>

class Job {
public:
    Job() { start(); }
    virtual ~Job() = default;
    void start() const { std::println("starting {}", title()); }

private:
    virtual const char* title() const = 0;
};

class Backup : public Job {
private:
    const char* title() const override { return "backup"; }
};

int main() {
    Backup nightly;
    std::println("this line is never printed");
}

from session import run

# pure_call.cpp: both builds compile without a warning; each program is then started on its own, so that the
# session names the signal that stops it.
run("""
clang++ -std=c++23 -Wall -Wextra pure_call.cpp -o pure_call
./pure_call
g++-16 -std=c++23 -Wall -Wextra pure_call.cpp -o pure_call-gcc
./pure_call-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra pure_call.cpp -o pure_call
$ ./pure_call
libc++abi: Pure virtual function called!
[stopped by SIGABRT]
$ g++-16 -std=c++23 -Wall -Wextra pure_call.cpp -o pure_call-gcc
$ ./pure_call-gcc
pure virtual method called
terminate called without an active exception
[stopped by SIGABRT]

Step through the creation of nightly up to the moment the program stops:

Neither compiler warns, because the call is hidden inside start(), and the standard calls the result undefined behaviourundefined behaviour: What a program does when it breaks a rule for which the C++ standard sets no requirements, such as reading past the end of an array. The compiler may assume it never happens, so the result can change with the compiler and the optimisation level. More in “Object lifetime and undefined behaviour in C++”. Here both runtime libraries stopped the program with SIGABRT, after libc++abi printed “Pure virtual function called!” and libstdc++ “pure virtual method called”. The fix is the one from the previous lesson: never call virtual functions, directly or through a helper, from constructors and destructors.

Practise: a logger interface and a fake

Thermostat logs a warning for each reading above its limit and an error from the third such reading in a row. It writes through a Logger&, but Logger is not an interface yet, so the tests cannot see what it logs.

// Exercise: make every check in logger_tests.cpp pass with both compilers. Thermostat is finished: do not change it.
#pragma once
#include <format>
#include <print>
#include <string>
#include <vector>

enum class Level { info, warning, error };

inline const char* level_name(Level level) {
    switch (level) {
        case Level::info: return "info";
        case Level::warning: return "warning";
        case Level::error: return "error";
    }
    return "?";
}

// TODO 1: make Logger an interface. write() becomes a pure virtual function, and the class gets a virtual
// destructor; the printing it does now moves to ConsoleLogger.
class Logger {
public:
    void write(Level level, const std::string& message) { std::println("{}: {}", level_name(level), message); }
};

// TODO 2: ConsoleLogger prints each entry as "<level>: <message>".
class ConsoleLogger : public Logger {};

// TODO 3: FakeLogger keeps each entry in entries() instead of printing it, so that tests can check it.
class FakeLogger : public Logger {
public:
    struct Entry {
        Level level;
        std::string message;
    };
    const std::vector<Entry>& entries() const { return entries_; }

private:
    std::vector<Entry> entries_;
};

// The code under test. It logs a warning for each reading above the limit, and an error from the third such
// reading in a row.
class Thermostat {
public:
    Thermostat(Logger& log, double limit) : log_(log), limit_(limit) {}

    void reading(double celsius) {
        if (celsius <= limit_) {
            over_ = 0;
            return;
        }
        ++over_;
        log_.write(over_ >= 3 ? Level::error : Level::warning,
                   std::format("{:.1f} °C is over the limit of {:.1f} °C", celsius, limit_));
    }

private:
    Logger& log_;
    double limit_;
    int over_ = 0;
};

// Sample tests for logger.h. Each check prints what it expects when it fails; the exit status is 0 only when every
// check passes.
#include <print>
#include <type_traits>
#include <vector>

#include "logger.h"

namespace {
int checks = 0;
int passed = 0;

void check(bool ok, const char* what) {
    ++checks;
    if (ok) ++passed;
    else std::println("FAILED: {}", what);
}
}  // namespace

int main() {
    check(std::is_abstract_v<Logger>, "Logger is an interface: no object of it can be created");
    check(std::has_virtual_destructor_v<Logger>, "Logger has a virtual destructor");

    FakeLogger fake;
    Thermostat thermostat{fake, 30.0};
    for (double celsius : {29.5, 31.0, 30.0, 32.5, 33.0, 34.0}) thermostat.reading(celsius);

    const auto& entries = fake.entries();
    check(entries.size() == 4, "four readings were over the limit, so the fake holds four entries");
    std::vector<Level> levels;
    for (const auto& e : entries) levels.push_back(e.level);
    check(levels == std::vector{Level::warning, Level::warning, Level::warning, Level::error},
          "the third reading over the limit in a row is an error");
    check(!entries.empty() && entries[0].message == "31.0 °C is over the limit of 30.0 °C",
          "a message names the reading and the limit");

    ConsoleLogger console;
    Logger& any = console;
    any.write(Level::info, "the console logger prints through the interface");

    std::println("{} of {} checks passed", passed, checks);
    return passed == checks ? 0 : 1;
}

from session import run

# The sample tests built against the starter code with both compilers.
run("""
clang++ -std=c++23 -Wall -Wextra logger_tests.cpp -o logger_tests && ./logger_tests
g++-16 -std=c++23 -Wall -Wextra logger_tests.cpp -o logger_tests-gcc && ./logger_tests-gcc
""")

$ clang++ -std=c++23 -Wall -Wextra logger_tests.cpp -o logger_tests && ./logger_tests
FAILED: Logger is an interface: no object of it can be created
FAILED: Logger has a virtual destructor
warning: 31.0 °C is over the limit of 30.0 °C
warning: 32.5 °C is over the limit of 30.0 °C
warning: 33.0 °C is over the limit of 30.0 °C
error: 34.0 °C is over the limit of 30.0 °C
FAILED: four readings were over the limit, so the fake holds four entries
FAILED: the third reading over the limit in a row is an error
FAILED: a message names the reading and the limit
info: the console logger prints through the interface
0 of 5 checks passed
[exit status 1]
$ g++-16 -std=c++23 -Wall -Wextra logger_tests.cpp -o logger_tests-gcc && ./logger_tests-gcc
FAILED: Logger is an interface: no object of it can be created
FAILED: Logger has a virtual destructor
warning: 31.0 °C is over the limit of 30.0 °C
warning: 32.5 °C is over the limit of 30.0 °C
warning: 33.0 °C is over the limit of 30.0 °C
error: 34.0 °C is over the limit of 30.0 °C
FAILED: four readings were over the limit, so the fake holds four entries
FAILED: the third reading over the limit in a row is an error
FAILED: a message names the reading and the limit
info: the console logger prints through the interface
0 of 5 checks passed
[exit status 1]

The warning: and error: lines in the output are the clue: Thermostat prints through Logger::write(), so FakeLogger never sees a thing.

1. TODO 1: make Logger an interface, with write() pure virtual and a virtual destructor.
2. TODO 2: give ConsoleLogger the printing that Logger::write() does now.
3. TODO 3: make FakeLogger store every call in entries() instead of printing it.

When both compilers print 5 of 5 checks passed, the only line before it should be the console logger’s own message. Then add a test of your own: a reading exactly at the limit must not be logged.

Then take the five ideas of this lesson, from the class that stays abstract to the call with no body, to cases it has not run. Whatever your answers show as weakest comes first, and every choice says what it gets right or misses:

Interview questions

Fresher · What is the difference between an abstract class and an interface in C++?

An abstract class is any class with at least one pure virtual function, declared with = 0, so no object of it can be created; it may also have data members, constructors and ordinary member functions with code. An interface is a convention for the strictest kind of abstract class: only pure virtual functions and a public virtual destructor, and no data. C++ has no interface keyword, so both are written as classes. Use an abstract class when implementations share code or data; use an interface when you only want to promise what a type can do, which keeps implementations independent and makes fakes for tests easy to write. A good answer mentions that a class can implement several interfaces through multiple inheritance.

The follow-ups usually test the edges of that answer: one class with two interfaces, and an interface whose destructor is pure. Decide both:

Two harder questions of this module start from this lesson: a service whose tests send real payment requests, and a crash that reports a pure virtual function call:

Key takeaways

• A pure virtual function, virtual … = 0;, makes its class abstract: no object of it can be created, and a derived class stays abstract until it overrides every pure virtual function it inherits.
• An interface in C++ is a class with only pure virtual functions and a public virtual destructor, and no data, used through references and pointers.
• Code that depends on an interface works with every implementation, including a fake that a test controls and inspects.
• The non-virtual interface idiom keeps shared steps in one public non-virtual function, which calls private virtual hooks; derived classes may override private virtual functions.
• A virtual call to a pure virtual function from a constructor or destructor is undefined behaviour; with both standard libraries here, it stopped the program.