What Is Functional Programming?
Functional programming (FP) is a style where you build programs by combining functions that behave like math functions: the same input always gives the same output, and nothing else in the program changes along the way.
Five ideas carry most of the weight:
- Pure functions: no hidden inputs (globals, registers) and no hidden outputs (side effects).
- Immutable data: instead of changing a value in place, you create a new one. In firmware, this mostly means const and read-only views.
- First-class functions: a function can be stored in a variable, passed as an argument and returned from another function.
- Higher-order functions: functions that take or return other functions, like std::transform and std::accumulate.
- Composition: chaining small functions into a pipeline.
A pure function works like a calculator. Press 7 × 6 and you get 42 every time, and it never beeps the buzzer or dims the display as a side effect. Composition works like a conveyor belt: each station does one job and hands the result to the next.
The mindset shift looks like this:
- Imperative thinking: “Loop through the array, keep a counter, update a total.”
- Functional thinking: “Take the valid readings and add them up.”
Is C++ a Functional Programming Language?
Not purely. C++ is multi-paradigm, so procedural, object-oriented, generic and functional code can live in the same project. A language like Haskell stops you from mutating state. C++ trusts you, which is both its power and its danger. For firmware, that means you can adopt exactly as much functional style as your hardware can afford.
Functional Features in C++, by Standard
| Feature | Why it matters in firmware | Since |
| Lambdas | Write small callbacks and predicates right where you use them | C++11 |
| std::function, std::bind | Store and adapt callables (use with care on MCUs) | C++11 |
| Generic lambdas (auto parameters), relaxed constexpr | One lambda for many types; real logic at compile time | C++14 |
| constexpr lambdas, std::optional, std::variant, std::visit, std::invoke, std::transform_reduce | Safer results, sum types, compile-time pipelines | C++17 |
| Ranges and views, std::span, concepts, std::bind_front, consteval | Lazy pipelines with the pipe operator, read-only views | C++20 |
| std::expected, monadic std::optional, std::move_only_function | Error handling as plain values | C++23 |
- Sweet spot: C++17 for most firmware teams, and C++20 if your toolchain supports it.
What C++ Won’t Do for You
- Purity isn’t enforced. Nothing stops a function you call “pure” from touching a global. Code evaluated at compile time with constexpr is the closest thing to enforced purity.
- Immutability is opt-in. You only get it by writing const consistently.
- No guaranteed tail-call optimization. Deep recursion can overflow a small stack.
- No garbage collector. You still decide where memory lives.
Why Should Embedded Developers Care?
Functional habits solve problems firmware engineers actually have:
- Fewer hidden interactions. Shared mutable state is a classic source of “works on the bench, fails in the field” bugs. A pure function that works only on its own arguments can’t be corrupted by an interrupt, because it touches nothing shared.
- Testing without hardware. Pure functions run on your PC in milliseconds. No board, no debugger, no flashing.
- Work at compile time. constexpr builds lookup tables and runs self-tests during compilation, so the work costs nothing at runtime.
- Abstractions that cost little. With optimization on, lambdas and template-based algorithms usually inline to the same machine code as a hand-written loop.
- Readable intent. A copy_if followed by an accumulate tells the next engineer what the code does, without making them decode loop bookkeeping.
One honest caveat: functional style doesn’t replace volatile, atomics or critical sections for data that is genuinely shared with interrupts. It shrinks how much of your code needs them.
Where It Shines in Firmware
- Sensor filtering and unit conversion
- Protocol parsing and checksums
- State machines and command handling
- Control algorithms (a PID controller can be a pure “old state in, new state out” step)
- Lookup-table generation
- Configuration validation
Pure Functions: The Foundation
A pure function returns the same output for the same input and touches nothing outside itself: no globals, no hardware registers, no printing.
// BAD: hidden input (g_calibration) and hidden output (it changes on every call)
static int g_calibration = 0;
int read_temperature() {
g_calibration++; // side effect
return read_adc() + g_calibration; // same call, different answer next time
}
// GOOD: everything it needs comes in as an argument, and it only returns a value
constexpr std::uint32_t adc_to_mv(std::uint16_t counts) {
return (static_cast<std::uint32_t>(counts) * 3300u) / 4095u; // 12-bit ADC, 3.3 V reference
}
// Free, compile-time unit tests
static_assert(adc_to_mv(0) == 0);
static_assert(adc_to_mv(2048) == 1650);
static_assert(adc_to_mv(4095) == 3300);
Ask three questions to spot an impure function:
- Does it read anything besides its parameters?
- Does it change anything besides its return value?
- Would calling it twice with the same input always give the same result?
If any answer is “yes” (or “no” for the last one), it’s impure.
What you gain:
- Safe to call from any context, since there’s no shared state to corrupt
- Testable on your PC with a plain function call
- Easy for the compiler to inline and optimize
- Simple to reason about: the signature tells the whole story
Immutability: const, constexpr and Read-Only Views
In embedded work, immutability doesn’t mean copying a 1 KB buffer every time something changes. It means being explicit about who is allowed to change what.
// Fixed at build time; on most Cortex-M builds this lives in flash, not RAM
constexpr std::array<std::uint16_t, 4> kAdcChannels{0, 1, 4, 5};
// A read-only view: the function can look at the samples but cannot modify them (C++20)
std::uint32_t average(std::span<const std::uint16_t> samples);
- Make everything const by default and remove it only when you must.
- Use constexpr for tables and configuration so the compiler can place them in read-only memory. On AVR, tables still need PROGMEM to stay out of RAM.
- Pass big objects by const& or std::span instead of copying.
- Return small structs by value. Modern compilers optimize this well.
Lambdas: Small Functions on the Spot
A lambda is a small unnamed function you write right where you need it. The compiler turns it into a tiny object with a call operator, which is why it can be inlined so well.
int offset = 10;
// [capture](parameters) -> return_type { body }
auto add_offset = [offset](int x) -> int { return x + offset; };
int y = add_offset(5); // y == 15
The capture list decides what the lambda can see:
| Capture | Meaning | Use it when |
| [] | Captures nothing | Stateless helpers; converts to a plain function pointer |
| [x] | Copies x into the lambda | Small values; safe even if the lambda outlives the scope |
| [&x] | Refers to x | The lambda runs immediately, for example inside an algorithm call |
| [=] / [&] | Copies or references everything used | Short-lived lambdas; avoid in stored callbacks |
| [v = std::move(y)] | Moves y in (C++14) | Move-only or expensive objects |
A captureless lambda converts to a plain function pointer, which makes it handy for C-style HAL callbacks:
using IrqCallback = void (*)();
void register_callback(IrqCallback cb); // a C-style API, like many vendor HAL callbacks
register_callback([] { toggle_led(); }); // a captureless lambda becomes a plain function pointer
Higher-Order Functions: Functions That Take Functions
A higher-order function takes a function as an argument, returns one, or both. If you’ve ever passed a comparison lambda to std::sort, you’ve already used one.
Here’s a practical one: retrying a flaky operation.
template <typename Op>
bool retry(Op op, int max_attempts) {
for (int attempt = 0; attempt < max_attempts; ++attempt) {
if (op()) {
return true;
}
}
return false;
}
// Usage: read 2 bytes from an I2C sensor, trying up to 3 times
std::uint8_t buf[2];
const bool ok = retry([&] { return i2c_read(0x48, buf, 2); }, 3); // i2c_read: your driver function
- retry doesn’t care what the operation is (I2C read, SPI transfer, flash write). It only cares whether it returns true.
- Because Op is a template parameter, the compiler can inline the lambda: no heap, no indirect call.
Callable Options Compared: Which One for Firmware?
| Option | Runtime cost | Heap use | Can hold state? | Best for |
| Function pointer | One indirect call | None | No | C APIs, vector tables, HAL callbacks |
| Template parameter (lambda or functor) | Usually inlined, near zero | None | Yes | Algorithms, drivers, hot paths |
| std::function | Indirect call plus type-erasure overhead, larger code | May allocate for larger captures | Yes | Host tools, tests, non-real-time code |
| Fixed-footprint wrappers (etl::delegate, SG14 inplace_function) | Small and predictable | None | Yes (some only reference the callable) | Stateful callbacks on bare metal |
- In a quick host test with GCC 13’s standard library, a std::function holding a lambda that captured one int stayed off the heap, while one capturing four values triggered an allocation. The exact threshold is implementation-defined, so never assume.
- An empty std::function throws std::bad_function_call, which is a problem when you build with -fno-exceptions.
Partial Application: Fix an Argument Once (C++20)
#include
bool i2c_write(std::uint8_t addr, std::uint8_t reg, std::uint8_t value); // your driver
auto write_sensor_reg = std::bind_front(i2c_write, std::uint8_t{0x48}); // address fixed once
write_sensor_reg(0x01, 0xA0); // i2c_write(0x48, 0x01, 0xA0)
A small lambda does the same job, is just as clear, and works on C++11. Prefer either over the older std::bind.
Function Composition: Small Pieces, One Pipeline
Composition means feeding the output of one function into the next. Each piece stays tiny, testable and reusable.
// C++17 (constexpr lambdas)
constexpr std::int32_t mv_to_tenths_c(std::uint32_t mv) {
return static_cast<std::int32_t>(mv) - 500; // TMP36-style sensor: 500 mV offset, 10 mV per degree C
}
template <typename F, typename G>
constexpr auto compose(F f, G g) {
return [f, g](auto x) { return f(g(x)); }; // returns a NEW function: x -> f(g(x))
}
constexpr auto adc_to_temp = compose(mv_to_tenths_c, adc_to_mv); // counts -> mV -> tenths of a degree C
static_assert(adc_to_temp(std::uint16_t{1000}) == 305, "1000 counts should read 30.5 C");
- Each step does one job, so a bug has one place to hide.
- Reordering or swapping a step (a different sensor curve, say) is a one-line change.
- The whole chain is constexpr, so it can be checked at build time.
- On C++14 this fails to compile, because lambdas can’t be constexpr there.
The Standard Library Is Your Functional Toolkit
You may already be doing functional programming without the label. The standard algorithms are the classic functional tools:
| Functional idea | C++ tool | Header | Plain-English meaning |
| map | std::transform | | Apply a function to every element |
| filter | std::copy_if | | Keep only the elements that pass a test |
| fold / reduce | std::accumulate, std::reduce | | Combine all elements into one value |
| any / all / none | std::any_of, std::all_of, std::none_of | | Ask a yes/no question about the whole set |
| count | std::count_if | | Count elements that pass a test |
| zip and fold | std::transform_reduce | | Multiply-and-add work, such as a FIR filter |
Here’s the same job written both ways:
std::array<std::uint16_t, 5> readings{1000, 0, 1012, 995, 0};
// Imperative: you manage the loop, the index and the running total
std::uint32_t total = 0;
for (std::size_t i = 0; i < readings.size(); ++i) {
if (readings[i] > 0) {
total += readings[i];
}
}
// Functional: you say WHAT you want (fold the valid readings into one sum)
const std::uint32_t total_fold = std::accumulate(
readings.begin(), readings.end(), std::uint32_t{0},
[](std::uint32_t acc, std::uint16_t v) { return v > 0 ? acc + v : acc; });
Honest take: for a one-step loop like this, both versions are fine. The payoff arrives when you chain several steps. Here are two more building blocks:
std::array<std::uint16_t, 4> raw{1000, 1012, 995, 1003};
std::array<std::uint32_t, 4> mv{};
std::transform(raw.begin(), raw.end(), mv.begin(), adc_to_mv); // map: counts -> millivolts
const bool any_high = std::any_of(mv.begin(), mv.end(),
[](std::uint32_t v) { return v > 3000; }); // any reading above 3.0 V?
On fixed-size arrays you can't shrink the container, so copy_if into a spare buffer (and keep the count) is the cleanest way to filter. You'll see that in the full example below.
C++20 Ranges: Readable Pipelines with the Pipe Operator
Ranges let you chain steps with |, like Unix commands, without creating temporary arrays.
#include // C++20
constexpr bool is_valid_sample(std::uint16_t counts) {
return counts > 0 && counts < 4095; // reject stuck-at-0 and saturated readings
}
const std::array<std::uint16_t, 8> raw{1000, 1012, 4095, 995, 1003, 0, 1008, 997};
auto good_mv = raw
| std::views::filter(is_valid_sample) // keep trustworthy samples
| std::views::transform(adc_to_mv); // convert each to millivolts
for (std::uint32_t mv : good_mv) {
// use mv (with this data: 805, 815, 801, 808, 812, 803)
}
- Lazy: nothing is computed until you iterate, and views don’t own or copy data.
- No heap: these views live on the stack.
- Watch your toolchain: ranges need a C++20-capable compiler, and newer GCC releases have much more complete support.
- Watch your build type: debug builds (-O0) can be slow and bulky because the abstractions rely on inlining.
Error Handling Without Exceptions: std::optional and std::expected
Many firmware projects build with -fno-exceptions. Functional style handles failure as a plain return value instead.
- std::optional (C++17): “a value, or nothing.” Use has_value(), *opt or value_or(). Skip .value() in no-exceptions builds, since it throws when empty.
- std::expected<T, E> (C++23): “a value, or the reason it failed.”
#include // C++23
enum class SensorError { Timeout, CrcMismatch, OutOfRange };
std::expected<std::uint16_t, SensorError> read_sensor(); // your driver
constexpr std::expected<std::uint32_t, SensorError> check_range(std::uint32_t mv) {
if (mv > 3300) return std::unexpected(SensorError::OutOfRange);
return mv;
}
auto result = read_sensor()
.transform(adc_to_mv) // runs only if the read succeeded
.and_then(check_range); // may turn a success into an error
if (result) {
use_millivolts(*result);
} else {
handle_error(result.error());
}
- Success and failure travel together in one value, so the error path can’t be forgotten halfway down a chain.
- This compiled cleanly with -fno-exceptions -fno-rtti on GCC 13.3.
- On an older toolchain, use std::optional or the single-header tl::expected library.
std::variant and std::visit: Commands and States Without Virtual Functions
std::variant holds exactly one of several types, and std::visit handles each type with its own code.
#include // C++17
template <class... Ts> struct overloaded : Ts... { using Ts::operator()...; };
template <class... Ts> overloaded(Ts...) -> overloaded; // helper needed before C++20
struct SetLed { std::uint8_t pin; bool on; };
struct SetPwm { std::uint8_t channel; std::uint16_t duty; };
struct Sleep { std::uint32_t ms; };
using Command = std::variant<SetLed, SetPwm, Sleep>;
void execute(const Command& cmd) {
std::visit(overloaded{
[](const SetLed& c) { gpio_write(c.pin, c.on); }, // your HAL functions
[](const SetPwm& c) { pwm_set_duty(c.channel, c.duty); },
[](const Sleep& c) { delay_ms(c.ms); }
}, cmd);
}
- No heap: the variant stores its value inside itself (the size of the largest alternative plus a small tag).
- No vtables, no RTTI: dispatch is resolved at compile time.
- Exhaustive by construction: add a new command type and the compiler flags every visitor that doesn’t handle it.
- State machine tip: model each state as a variant alternative and write next(State, Event) -> State as a pure function.
constexpr: Let the Compiler Do the Work
constexpr asks the compiler to compute a result at build time. You get lookup tables with no startup code and no RAM, plus bugs caught before the firmware ever runs.
// C++17
constexpr std::uint8_t crc8_step(std::uint8_t crc) {
for (int bit = 0; bit < 8; ++bit) {
crc = (crc & 0x80) ? static_cast<std::uint8_t>((crc << 1) ^ 0x07)
: static_cast<std::uint8_t>(crc << 1);
}
return crc;
}
constexpr std::array<std::uint8_t, 256> make_crc8_table() {
std::array<std::uint8_t, 256> table{};
for (std::size_t i = 0; i < table.size(); ++i) {
table[i] = crc8_step(static_cast<std::uint8_t>(i));
}
return table;
}
constexpr auto kCrc8Table = make_crc8_table(); // built by the compiler, stored as read-only data
constexpr std::uint8_t crc8(const std::uint8_t* data, std::size_t len) {
std::uint8_t crc = 0;
for (std::size_t i = 0; i < len; ++i) {
const std::uint8_t index = static_cast<std::uint8_t>(crc ^ data[i]);
crc = kCrc8Table[index];
}
return crc;
}
// Build-time self-test: the standard CRC-8 check value for "123456789" is 0xF4
constexpr std::uint8_t kCheck[] = {'1', '2', '3', '4', '5', '6', '7', '8', '9'};
static_assert(crc8(kCheck, sizeof kCheck) == 0xF4, "CRC-8 self-test failed");
- The 256-entry table is generated during compilation, with no init code and no startup delay.
- The static_assert runs while compiling: if someone edits the polynomial by mistake, the build fails instead of the field unit.
- Use consteval (C++20) when a function must only ever run at compile time.
More compile-time ideas worth trying:
- Sine tables for PWM or waveform generation
- Baud-rate divisor calculations with a static_assert on the error margin
- Bit-mask and register-field packing
Functional Core, Imperative Shell: A Firmware Architecture That Works
The most practical way to apply functional programming in firmware is to split your code into two layers. The core makes decisions with pure functions. The shell is a thin layer that reads hardware, calls the core and writes hardware.
[ Shell: read hardware ] –> [ Pure core: filter -> convert -> decide ] –> [ Shell: write hardware ]
(impure) (pure, testable on a PC) (impure)
Here’s a tiny thermostat that follows the pattern. Notice that heater_next takes the previous state as an argument and returns the new one, so there’s no hidden variable inside it:
// PURE CORE
constexpr bool heater_next(bool heater_on, std::int32_t temp_x10) {
constexpr std::int32_t kLow = 240; // 24.0 C
constexpr std::int32_t kHigh = 260; // 26.0 C
if (temp_x10 <= kLow) return true; // too cold: heater ON
if (temp_x10 >= kHigh) return false; // warm enough: heater OFF
return heater_on; // inside the band: keep the previous state
}
static_assert(heater_next(false, 230) == true);
static_assert(heater_next(true, 270) == false);
static_assert(heater_next(true, 250) == true);
static_assert(heater_next(false, 250) == false);
// IMPERATIVE SHELL (adc_read, gpio_write, delay_ms come from your HAL)
void control_loop() {
bool heater_on = false;
while (true) {
const std::uint16_t raw = adc_read(TEMP_CHANNEL); // impure: talks to hardware
const std::int32_t temp = adc_to_temp(raw); // pure
heater_on = heater_next(heater_on, temp); // pure: old state in, new state out
gpio_write(HEATER_PIN, heater_on); // impure: talks to hardware
delay_ms(100); // impure
}
}
- Test heater_next on your PC without a board. The static_assert lines above already do it at build time.
- The two thresholds (hysteresis) stop the heater from chattering on and off around a single setpoint.
- Moving to a different MCU family? Only the shell changes. The core carries over untouched.
- The shell stays tiny, so reviews and debugging focus on the few lines that touch hardware.
Putting It Together: A Sensor Pipeline You Can Run on Your PC
Here is everything so far in one file. It filters out bad ADC samples, averages the rest and converts the result to a temperature. Save it as pipeline.cpp and build it with g++ -std=c++17 -Wall -Wextra -O2 pipeline.cpp -o pipeline.
#include
#include
#include
#include
#include
#include
// ---------- Pure building blocks ----------
constexpr std::uint32_t adc_to_mv(std::uint16_t counts) {
return (static_cast<std::uint32_t>(counts) * 3300u) / 4095u; // 12-bit ADC, 3.3 V reference
}
constexpr std::int32_t mv_to_tenths_c(std::uint32_t mv) {
return static_cast<std::int32_t>(mv) - 500; // TMP36: 500 mV offset, 10 mV per degree C
}
constexpr bool is_valid_sample(std::uint16_t counts) {
return counts > 0 && counts < 4095; // reject stuck-at-0 and saturated readings
}
template <typename F, typename G>
constexpr auto compose(F f, G g) {
return [f, g](auto x) { return f(g(x)); }; // returns a new function: x -> f(g(x))
}
constexpr auto adc_to_temp = compose(mv_to_tenths_c, adc_to_mv);
// ---------- Compile-time self-checks (they cost zero flash) ----------
static_assert(adc_to_mv(2048) == 1650, "mid-scale should be half of 3.3 V");
static_assert(adc_to_temp(std::uint16_t{1000}) == 305, "1000 counts should be 30.5 C");
int main() {
constexpr std::size_t N = 8;
const std::array<std::uint16_t, N> raw{1000, 1012, 4095, 995, 1003, 0, 1008, 997};
// 1) FILTER: keep only trustworthy samples (fixed-size buffer, no heap)
std::array<std::uint16_t, N> valid{};
const auto valid_end = std::copy_if(raw.begin(), raw.end(), valid.begin(), is_valid_sample);
const auto count = static_cast<std::size_t>(valid_end - valid.begin());
// 2) FOLD: average of the good samples
const std::uint32_t sum = std::accumulate(valid.begin(), valid_end, std::uint32_t{0});
const std::uint32_t avg = count ? sum / static_cast<std::uint32_t>(count) : 0u;
// 3) MAP + COMPOSE: counts -> millivolts -> tenths of a degree Celsius
const std::int32_t temp_x10 = adc_to_temp(static_cast<std::uint16_t>(avg));
std::printf("valid samples : %zu\n", count);
std::printf("average counts: %u\n", static_cast<unsigned>(avg));
std::printf("temperature : %d.%d C\n", temp_x10 / 10, temp_x10 % 10); // fine for positive readings
return 0;
}
Expected output:
valid samples : 6
average counts: 1002
temperature : 30.7 C
What to notice:
- No heap anywhere: fixed-size std::array buffers only.
- Every step is a small function you can test alone.
- The static_assert lines run at build time. Break a formula and the build fails.
- Only main does I/O. Replace the sample array with real ADC reads and the same logic runs on hardware.
- The temperature print is fine for positive readings. Handle the sign separately for sub-zero values.
Functional vs. Procedural vs. Object-Oriented Style in Firmware
| Aspect | Procedural C | Object-oriented C++ | Functional-style C++ |
| Where state lives | Globals and statics | Member variables inside objects | Passed in, returned out |
| Testing on a PC | Needs stubs for globals | Needs mocks or interfaces | Call the function directly |
| Interrupt and multi-context safety | Depends on discipline | Depends on locking members | Pure code is naturally reentrant |
| Best at | Register-level drivers, tiny footprints | Modeling devices and resources with lifecycles | Data transformation, decisions, protocols, math |
| Watch out for | Global coupling | Deep hierarchies, virtual dispatch cost | Hidden allocations, deep recursion |
The practical answer isn’t “either/or”. Model hardware resources as classes (constructors, destructors and RAII work well there) and write the logic that runs on their data as pure functions.
Common Pitfalls (and How to Avoid Them)
| Pitfall | Why it hurts on a microcontroller | Fix |
| std::function in hot paths or ISRs | Possible heap allocation, indirect call, throws when empty | Template parameter, function pointer or fixed-size delegate |
| Recursion instead of loops | No tail-call guarantee; small stacks overflow | Use loops and algorithms; recurse only with a proven depth limit, or at compile time |
| [&] in stored callbacks | The captured local dies, leaving a dangling reference and random crashes | Capture by value, or make sure the lambda dies first |
| Copying buffers “to stay immutable” | Wastes RAM and cycles | Pass const& or std::span |
| Templates and ranges everywhere | Code bloat | Check with your toolchain’s size tool and the linker map file |
| Judging performance at -O0 | Abstractions rely on inlining | Measure with optimization on |
| Assuming FP prevents data races | Pure functions don’t protect shared hardware state | Keep volatile, atomics and critical sections in the shell |
Best-Practice Checklist
- Start with const and constexpr by default.
- Keep hardware access in a thin shell, and decisions in pure functions.
- Prefer template parameters over std::function for callbacks in hot paths.
- Use fixed-size containers (std::array, or ETL containers) instead of std::vector where the size is known.
- Pick one error-handling style per project: return codes, std::optional or std::expected.
- Test pure functions on your PC first (Catch2, doctest or GoogleTest all work).
- Record flash and RAM usage before and after each refactor (for example with arm-none-eabi-size).
- Check your coding standard (MISRA C++:2023, AUTOSAR C++14, CERT C++) for rules on lambdas, recursion and dynamic memory.
- Inspect the generated assembly on Compiler Explorer when you’re unsure what the compiler did.
Try These Next
- Rewrite a moving-average filter as a pure function: (state, sample) -> (new state, output).
- Generate a 256-entry sine table with constexpr for PWM.
- Model a traffic-light controller with std::variant states.
- Wrap an I2C read in retry() and test it on your PC with a fake sensor.
- Compare flash and RAM before and after converting one module.
Key Takeaways
- Functional programming in C++ means pure functions, const data and functions treated as values.
- C++ supports the style well but doesn’t enforce it, so you choose the dose.
- Prefer lambdas and template parameters over std::function in performance-critical code.
- constexpr gives you compile-time tables and build-time tests.
- std::optional, std::expected and std::variant replace exceptions and virtual dispatch cheaply.
- Keep hardware access in a thin shell, and test the pure core on your PC.
- Measure flash and RAM instead of assuming.
Conclusion
Functional programming in C++ isn’t about turning firmware into Haskell. It’s a handful of habits: keep functions honest about their inputs and outputs, prefer const, build behavior from small pieces, and let the compiler do work at build time. Start small. Turn one conversion function into a pure constexpr function, test it on your PC, and notice how much calmer that part of your codebase feels.
If you want guided, hands-on practice writing modern C++ and Embedded C on real microcontrollers, explore the embedded systems training programs at the Indian Institute of Embedded Systems (IIES) in Bangalore.
