Quando usiamo tipi primitivi “nudi” (int, double e simili), il significato dei valori non è esplicito. Il codice diventa più fragile: è facile scambiare due parametri e, in alcuni casi, non è nemmeno possibile rappresentare correttamente l'intento.

Per capire il problema, partiamo da un caso molto comune.

struct rectangle{    rectangle(double const width, double const height);    ...};

In questo esempio nulla impedisce di invertire accidentalmente larghezza e altezza: rectangle(800, 600) e rectangle(600, 800) sono entrambi validi per il compilatore, ma uno dei due potrebbe essere semanticamente errato. Il problema emerge soltanto durante l'esecuzione.

Proviamo allora a rendere l’intento più chiaro con nomi diversi.

struct circle{public:    explicit circle(double const radius) : m_radius{radius} {}    explicit circle(double const diameter) : m_radius{diameter/2} {} // This doesn't compile! :(    ...}

Qui i due costruttori hanno la stessa firma, circle(double): cambiano soltanto i nomi dei parametri, che non partecipano alla risoluzione dell'overload. Il codice quindi non compila e continuiamo a non avere tipi distinti per rappresentare raggio e diametro.

I tipi primitivi non rappresentano la semantica del dominio. Serve un modo per dare un'identità ai valori e rendere esplicito il significato nel punto di chiamata, riducendo errori ed effetti inattesi.

Per questo introduciamo tipi “forti” e auto-esplicativi: Width, Height, Radius, Diameter, e così via. Nelle sezioni che seguono analizzeremo una libreria header-only per C++23, st::strong_type<T, Tag, Ability...>, in cui Tag separa gli “assi semantici”, mentre le Ability abilitano in modalità opt-in solo gli operatori desiderati (aritmetici, di stream, bitwise, saturating). Così il compilatore ci aiuta a esprimere l’intento e a prevenire intere classi di bug.

Cos’è uno strong type?

Uno strong type è un wrapper di tipo che sostituisce un tipo sottostante per rendere esplicita la semantica a livello di tipo (non solo nel nome del parametro). Con st::strong_type<T, Tag, Ability...> “marchiamo” un T con un Tag (phantom type) che lo rende incompatibile con altri valori isomorfi ma semanticamente diversi, e abilitiamo solo le operazioni dichiarate in modo opt-in tramite le Ability.

Lo strong type nel codice:

namespace st {template<class T, class Tag, template<class> class... Ability>struct strong_type;} // namespace st

• T: tipo sottostante (es. double, int, std::uint32_t, un enum...).
• Tag: tipo vuoto che identifica l’asse semantico (es. width_tag, height_tag).
• Ability: feature mixins (operatori e utility opt-in). È disponibile anche il gruppo pronto all’uso st::arithmetic.

Come funziona?

• Tag barrier. Gli operatori binari tra strong type sono ammessi solo se condividono lo stesso Tag. Sommare Width e Height? Errore di compilazione.
• Ability gating. Ogni operatore/utility è protetto da un requires: entrambi gli operandi devono dichiarare l’abilità richiesta e l’underlying deve supportare davvero l’operazione (verifica sull’espressione).
• Costruttori corretti. Da T: il costruttore è explicit per default; diventa implicito solo quando la conversione a T è sicura (nessun narrowing). Da un altro strong type con lo stesso Tag: consentito se gli underlying sono convertibili; valgono le stesse regole di explicit.
• Tipo di risultato disciplinato. Gli operatori binari restituiscono un nuovo strong type con: underlying = std::common_type_t<UA, UB>; abilità = unione delle abilità dei due operandi, filtrate in base al nuovo underlying (es. lo shift solo su unsigned); stesso Tag.
• Shift sicuri. I conteggi sono normalizzati modulo la bit width (con assert sui negativi in debug), evitando UB.
• Aritmetica saturante. st::sat_add e st::sat_sub fanno clamp a min e max (percorsi dedicati per signed/unsigned) e restituiscono un tipo coerente con le regole di unione/filtraggio sopra.
• Accesso e utilità. x.value() (overload lvalue/rvalue), st::to_underlying(x) (preserva la value category), st::clamp, explicit operator bool() in stile bool-testable, st::static_strong_cast(x) (cast intenzionale tra strong type con lo stesso Tag).
• Integrazione STL. Specializzazioni coerenti di std::hash, std::formatter e std::common_type in linea con le regole precedenti.

Un esempio

Questo esempio, volutamente completo, mostra l'utilità di un header file dedicato agli strong type.

#include <cstdint>#include <expected>#include <format>#include <iostream>#include <limits>#include <numeric>#include <print>#include <ranges>#include <sstream>#include <string_view>#include <unordered_map>#include <vector>#include "strong.h"// tagsstruct distance_tag{};struct time_tag{};struct flag_bits_tag{};struct counter_tag{};// strong aliasesusing meters    = st::strong_type<int, distance_tag, st::arithmetic, st::equality_comparable, st::three_way_comparable, st::ostream_insertable>;using meters64 = st::    strong_type<long long, distance_tag, st::arithmetic, st::equality_comparable, st::three_way_comparable, st::ostream_insertable>;using meters_d = st::    strong_type<double, distance_tag, st::arithmetic, st::equality_comparable, st::three_way_comparable, st::ostream_insertable>;using seconds = st::    strong_type<int, time_tag, st::equality_comparable, st::three_way_comparable, st::ostream_insertable, st::istream_extractable>;using flags = st::strong_type<std::uint8_t,                              flag_bits_tag,                              st::bitwise_and,                              st::bitwise_and_assign,                              st::bitwise_or,                              st::bitwise_or_assign,                              st::bitwise_xor,                              st::bitwise_xor_assign,                              st::bitwise_not,                              st::shift_left,                              st::shift_left_assign,                              st::shift_right,                              st::shift_right_assign,                              st::ostream_insertable>;using flag_mask = st::strong_type<std::uint8_t,                                  flag_bits_tag,                                  st::bitwise_and,                                  st::bitwise_or,                                  st::bitwise_xor,                                  st::bitwise_not,                                  st::shift_left,                                  st::shift_right,                                  st::ostream_insertable,                                  st::bitops_extras>;using meters_u    = st::strong_type<unsigned, distance_tag, st::arithmetic, st::saturating, st::equality_comparable, st::ostream_insertable>;using meters_s_sat    = st::strong_type<int, distance_tag, st::arithmetic, st::saturating, st::equality_comparable, st::ostream_insertable>;using counter = st::strong_type<int, counter_tag, st::arithmetic, st::bool_testable, st::ostream_insertable>;// helpers[[nodiscard]] auto average_distance(const std::vector<meters> &path) -> std::expected<meters_d, std::string_view>{    if (path.empty())        return std::unexpected{"empty path"};    const auto total = std::accumulate(        path.begin(), path.end(), meters{0}, [](const meters &a, const meters &b) -> meters { return a + b; });    return st::static_strong_cast<meters_d>(total) / static_cast<double>(path.size());}[[nodiscard]] auto pairwise_sum(const std::vector<meters> &a, const std::vector<meters> &b)    -> std::expected<std::vector<meters>, std::string_view>{    if (a.size() != b.size())        return std::unexpected{"size mismatch"};    std::vector<meters> out;    out.reserve(a.size());    for (auto &&[x, y] : std::views::zip(a, b))        out.push_back(x + y);    return out;}auto main() -> int{    static_assert(std::same_as<decltype(meters{1} + meters{2}), meters>);    static_assert(std::same_as<std::common_type_t<meters, meters64>::underlying_type, long long>);    // extra compile-time sanity checks    static_assert(std::is_trivially_copyable_v<meters>);    static_assert(sizeof(flags) == sizeof(std::uint8_t));    // construction & conversions    meters a = 12;    meters b{short{30}};    meters c = meters64{42};   // strong -> strong (same tag)    meters_d d{meters64{100}}; // strong -> strong (same tag) to double    std::println("a={}, b={}, c={}, d={}", a, b, c, d);    // arithmetic + comparisons    const auto sum{a + b};    const auto diff{b - a};    const auto ord{a <=> b};    std::println("sum={}, diff={}, cmp={}", sum, diff, (ord < 0 ? "a<b" : (ord > 0 ? "a>b" : "a==b")));    // compound ops / modulo / ++ --    auto mwork = meters{5};    ++mwork;    mwork++;    mwork -= meters{1};    mwork += meters{3};    mwork %= meters{4};    std::println("mwork after ops = {}", mwork);    // scalar rebind (multiply/divide)    const auto scaled = a * 2.5;    const auto halved = scaled / 2.0;    std::println("scaled={}, halved={}", scaled, halved);    // clamp, unary -, cast, to_underlying    const auto lo{meters{5}}, hi{meters{25}};    std::println("clamp({}, {}, {}) = {}", a, lo, hi, st::clamp(a, lo, hi));    std::println("unary_minus(-{}) = {}", lo, -lo);    std::println("static_strong_cast<double> = {}", st::static_strong_cast<meters_d>(a));    std::println("sum as raw int: {}", st::to_underlying(sum));    // streams & parsing    std::istringstream iss{"77"};    seconds t{0};    iss >> t;    std::println("parsed seconds = {}", t);    // unordered_map / hash    std::unordered_map<meters, std::string_view> names;    names.emplace(a, "start");    names.emplace(b, "end");    std::println("names[a] = {}", names.at(a));    // bitwise flags    auto f = flags{std::uint8_t{0b0101}};    const auto g = flags{std::uint8_t{0b0011}};    f |= g;    f &= flags{std::uint8_t{0b0110}};    f ^= flags{std::uint8_t{0b0010}};    f <<= 42; // 42 % 8 = 2    f >>= 2;    std::println("flags final = {}", f);    // bit-ops extras    const auto mk = flag_mask{std::uint8_t{0b1101}};    std::println("mask={}, popcount={}, bit_width={}", mk, st::popcount(mk), st::bit_width(mk));    std::println("rotl({}, 3)={}, rotr({}, 2)={}", mk, st::rotl(mk, 3), mk, st::rotr(mk, 2));    std::println("countl_zero={}, countl_one={}, countr_zero={}, countr_one={}",                 st::countl_zero(mk),                 st::countl_one(mk),                 st::countr_zero(mk),                 st::countr_one(mk));    // saturating arithmetic (unsigned + signed)    const auto umax_less = meters_u{std::numeric_limits<unsigned>::max() - 5u};    const auto uplus = meters_u{100u};    const auto usat = st::sat_add(umax_less, uplus);    std::println("sat_add({}, {}) = {}", umax_less, uplus, usat);    const auto smin = meters_s_sat{std::numeric_limits<int>::min() + 10};    const auto sneg = meters_s_sat{-1000};    const auto ssat = st::sat_sub(smin, sneg);    std::println("sat_sub({}, {}) = {}", smin, sneg, ssat);    // ranges / expected    const std::vector<meters> path{meters{3}, meters{4}, meters{5}, meters{6}};    if (auto avg = average_distance(path))    {        std::println("average(path) = {}", *avg);    }    else    {        std::println("average(path) error: {}", avg.error());    }    const std::vector<meters> p2{meters{7}, meters{8}, meters{9}, meters{10}};    if (auto summed = pairwise_sum(path, p2))    {        std::println("pairwise_sum size={}, last={}", summed->size(), summed->back());    }    else    {        std::println("pairwise_sum error: {}", summed.error());    }    // bool_testable    counter cnt{2};    if (cnt)    {        std::println("counter {} is truthy", cnt);    }    --cnt;    --cnt;    if (!static_cast<bool>(cnt))    {        std::println("counter {} is falsy", cnt);    }    return 0;}// Application output/*parsed seconds = 77names[a] = startflags final = 4mask=13, popcount=3, bit_width=4rotl(13, 3)=104, rotr(13, 2)=67countl_zero=4, countl_one=0, countr_zero=0, countr_one=1sat_add(4294967290, 100) = 4294967295sat_sub(-2147483638, -1000) = -2147482638average(path) = 4.5pairwise_sum size=4, last=16counter 2 is truthycounter 0 is falsy*/

Conclusione

Gli strong type permettono di costruire API più esplicite, rilevare prima gli errori e controllare quali operazioni siano disponibili per ciascun valore. Alias concreti come using Width = st::strong_type<double, width_tag, st::arithmetic>; rendono più chiari sia il punto di chiamata sia i test, perché il compilatore può distinguere valori identici nella rappresentazione ma diversi nel significato.

In questo articolo vediamo come std::ranges e std::views, introdotti in C++20, rendano più chiara la composizione degli algoritmi sulle collezioni.

Modello computazionale

Quesito

Vogliamo scrivere un algoritmo che riceva una collezione di numeri interi e produca, in ordine inverso, soltanto quelli divisibili per 3.

La tabella seguente mostra alcuni esempi di input e output.

Soluzione pre C++20

#include <algorithm>#include <vector>#include <iostream>auto main() -> int {    const std::vector<int> numbers{3, 0, 10, 9, 12, 7, 30, 14, 6};    auto isDivisibleByThree = [](int const i) { return i % 3 == 0; };    std::vector<int> tmp{};    std::copy_if(numbers.begin(), numbers.end(), std::back_inserter(tmp), isDivisibleByThree);    std::reverse(tmp.begin(), tmp.end());    for (auto const& i : tmp)        std::cout << i << " ";    return 0;}

Questo piccolo frammento di codice esegue questi passaggi:

• Crea uno std::vector temporaneo di supporto.
• Copia in tmp tutti gli elementi di numbers che soddisfano il predicato isDivisibleByThree.
• Inverte la sequenza degli elementi di tmp.

La soluzione funziona, ma richiede un contenitore temporaneo e più passaggi separati. Con C++20 possiamo descrivere la stessa trasformazione in modo più diretto.

Soluzione con std::ranges

#include <algorithm>#include <vector>#include <iostream>#include <ranges>auto main() -> int {    const std::vector<int> numbers{3, 0, 10, 9, 12, 7, 30, 14, 6};    auto isDivisibleByThree = [](int const i) { return i % 3 == 0; };    auto result{std::views::reverse(std::views::filter(numbers, isDivisibleByThree))};    for (auto const& i : result)        std::cout << i << " ";    return 0;}

La differenza è evidente; prima di entrare nello specifico, però, conviene chiarire meglio i concetti di range e view.

Ranges

Un range rappresenta una sequenza di elementi, o più in generale qualcosa su cui è possibile iterare.

Per definizione, un range è una coppia di iteratori begin e end: il primo punta all'inizio di una collezione o sequenza, il secondo alla fine.

I contenitori della libreria standard soddisfano questa definizione e possono quindi essere usati come range.

Classificazione

I range possono essere classificati in modi diversi. Una delle distinzioni principali riguarda le capacità degli iteratori.

Avendo affrontato i concepts nel post precedente, possiamo riassumere i ranges nella tabella seguente.

La classificazione corrisponde ai relativi concept degli iteratori, come std::forward_iterator.

Views

Tre proprietà delle view sono particolarmente importanti:

• Una view è un range.
• Una view non possiede i dati a cui accede.
• Una view applica le modifiche solo quando un elemento viene richiesto (lazy-evaluation).

Una view è un range

Per definizione, una view \(w\) è un range definito su un altro range \(r\). La view può applicare trasformazioni al range osservato tramite algoritmi e altre operazioni, sfruttando la lazy-evaluation.

Una view non possiede i dati a cui accede

Quando si accede a un elemento attraverso una view, si continua a lavorare sui dati gestiti dal range sottostante.

Questo ha due implicazioni:

• Le viste sono veloci da creare, perché non hanno bisogno di copiare i dati sottostanti.
• Le trasformazioni della view non modificano la struttura del contenitore originale.

#include<iostream>#include<vector>#include<ranges>auto main() -> int {    std::vector numbers{1, 2, 3, 4, 5};    auto v{std::views::reverse(numbers)};    for (auto const& i : numbers)        std::cout << i << " ";    return 0;}// Output: 1 2 3 4 5

Come si può notare, la view non ha modificato il range numbers. È vero però il contrario: modificando il contenitore originale, il cambiamento si ripercuote su tutte le view che usano quel range.

Avremo pertanto

#include<iostream>#include<vector>#include<ranges>auto main() -> int {    std::vector numbers{1, 2, 3, 4, 5};    auto v{std::views::reverse(numbers)};    for (auto const& i : v)        std::cout << i << " ";    std::cout << std::endl;    numbers[2] = 100;    numbers[4] = 77;    for (auto const& i : v)        std::cout << i << " ";    return 0;}// Output: 5 4 3 2 1//         77 4 100 2 1

Lazy-evaluation

Una view applica le trasformazioni quando gli elementi vengono richiesti, non necessariamente nel momento in cui viene creata. Questa valutazione differita evita elaborazioni e copie non necessarie.

#include<iostream>#include<vector>#include<ranges>auto main() -> int {    std::vector numbers{1, 2, 3, 4, 5};    auto v{std::views::reverse(numbers)};    std::cout << *v.begin() << std::endl; // la view viene valutata qua    return 0;}// Output: 5

Composizione e pipeline

Qualcuno potrebbe chiedersi perché ho scritto

auto v{std::views::reverse(numbers)};

Anziché utilizzare

std::views::reverse v{numbers};

Il motivo è che std::views::reverse non è una view, ma un adattatore: prende il range sottostante, in questo caso uno std::vector, e restituisce una view su quello std::vector. Il tipo esatto della view viene nascosto dietro la keyword auto; in questo modo non dobbiamo preoccuparci di scrivere gli argomenti del template della view. Un ulteriore vantaggio di questa forma è la possibilità di concatenare più adattatori tramite pipe.

Per esempio anziché utilizzare

auto v{std::views::reverse(std::views::filter(numbers, isDivisibleByThree))};

Possiamo scrivere

auto v{numbers | std::views::filter(isDivisibleByThree) | std::views::reverse};

Esempi

Vogliamo creare una view dei primi 5 elementi di un std::vector e stampare il risultato.

#include<iostream>#include<vector>#include<ranges>auto main() -> int {    std::vector numbers{1, 2, 3, 4, 5, 6, 7, 8, 9, 10};    auto v{numbers | std::views::take(5)};    for (auto const& i : v)        std::cout << i << " ";}// Output: 1 2 3 4 5

Vogliamo sfruttare un algoritmo range based per stampare un std::vector invertito e ripulito da tutti i valori negativi.

#include <algorithm>#include <iostream>#include <ranges>#include <vector>auto main() -> int {    std::vector numbers{-1, 3, -100, -4, 0, 3, -7, 1};    auto predicate = [](int const i) -> bool {        return i >= 0;    };    auto printer = [](int const i) {        std::cout << i << " ";    };    std::ranges::for_each(numbers | std::views::reverse | std::views::filter(predicate), printer);}// Output: 1 3 0 3

Concetti avanzati

Range factory

La libreria standard include anche adattatori capaci di generare una view senza partire da un range esistente.

Una tra le svariate è std::views::iota, che crea una view incrementale di interi.

#include <iostream>#include <ranges>auto main() -> int {    for (int const i : std::views::iota(1, 7)) {        std::cout << i << " ";    }}// Output: 1 2 3 4 5 6

Zip Views

std::views::zip, introdotta in C++23, permette di combinare più range in un'unica view. Ogni elemento prodotto è una tupla che contiene i valori corrispondenti dei range di origine.

Cerchiamo di capire meglio con un esempio.

#include <iostream>#include <ranges>#include <vector>auto main() -> int {    std::vector numbers{1, 2, 3, 4};    std::vector english{"cat", "dog", "table", "sun"};    std::vector italian{"gatto", "cane", "tavolo", "sole"};    for (const auto& i : std::views::zip(numbers, english, italian)) {        std::cout << std::get<0>(i) << ". "                  << std::get<1>(i) << ": "                  << std::get<2>(i) << '\n';    }    return 0;}

Conclusione

Range e view permettono di descrivere una pipeline di trasformazioni senza introdurre contenitori temporanei non necessari. Per una panoramica completa degli adattatori e degli algoritmi disponibili, si può consultare la documentazione della libreria ranges.

Questo articolo introduce i concept, una delle funzionalità più utili di C++20 per il codice generico. Vedremo la terminologia essenziale e come usarli per esprimere in modo esplicito i requisiti di un template.

Per un riferimento completo, cppreference raccoglie la documentazione su vincoli e concept.

Motivazione

La prima domanda è semplice: a cosa servono i concept?

Quando scriviamo codice vogliamo, quasi sempre, che gli algoritmi e le strutture dati che implementiamo siano generici, cioè utilizzabili con tipi di dato diversi. Vogliamo quindi un'unica soluzione generica, senza doverla reimplementare per tipi di dato specifici. Questo offre diversi vantaggi:

• maggiore manutenibilità;
• riutilizzo dello stesso codice con tipi diversi;
• possibilità per chi usa l'API di fornire tipi personalizzati.

Gli esempi più comuni sono gli algoritmi generici e le strutture della libreria standard, come std::swap e std::vector.

In C++ questa astrazione viene espressa con un template, che può essere istanziato con tipi diversi. Spesso, però, il tipo non può essere scelto arbitrariamente: l'implementazione può richiedere operazioni o proprietà specifiche.

Supponiamo di avere un algoritmo che, dati due valori dello stesso tipo, voglia eseguire l'operazione di addizione binaria e restituire il risultato.

#include <iostream>#include <format>template <typename T>auto add(T const& a, T const& b) -> T {    return a + b;}auto main() -> int {    std::cout << std::format("{}\n", add(1, 2));    // std::cout << std::format("{}\n", add("foo", "bar")); -> compilation error    return 0;}

Il parametro generico T del template non è vincolato: dal punto di vista della compilazione può essere istanziato con qualsiasi tipo di dato. Tuttavia, se si richiede l'istanziazione di questa funzione con certi tipi di dato, il compilatore genererà un errore.

Questo avviene perché il template della funzione in questione richiede implicitamente che i tipi di dato passati come parametro debbano fornire l'operatore binario di addizione. Quindi passando un tipo di dato che non presenta l'operatore di addizione binaria, il compilatore riscontra l'impossibilità di generare la funzione.

In quale punto fallisce il compilatore?

Non nella dichiarazione del template, ma durante la sua istanziazione, nel punto in cui l'implementazione tenta di usare un'operazione non disponibile.

Questo produce messaggi di errore complessi da decifrare e causa parecchia frustrazione. In codebase medio-grandi, con strutture dati annidate, la situazione peggiora esponenzialmente.

Per risolvere questo inconveniente dobbiamo introdurre dei vincoli, così da definire in modo esplicito i requisiti dei parametri del template.

Terminologia

Modello (template)

Un modello è un costrutto che genera un tipo o una funzione normale in fase di compilazione in base agli argomenti forniti dall'utente per i parametri del modello. Gli argomenti di un modello possono essere vincolati.

Requisiti

Sono espressi tramite la parola chiave requires, che descrive le condizioni che un tipo o un'espressione devono soddisfare. Per i dettagli rimando alla documentazione di cppreference su requires.

Vincolo (constraint)

Un vincolo è un insieme di requisiti sugli argomenti di un modello.

Questi sono usati per:

• Selezionare correttamente gli overloading delle funzioni.
• Decidere la specializzazione più appropriata per un modello.

Concetti (concepts)

Un concetto è un predicato che racchiude un insieme di vincoli. Ogni concetto viene valutato in fase di compilazione e diventa parte dell'interfaccia di un modello in cui viene usato sotto forma di vincolo.

Inoltre:

• Un tipo di dato che soddisfa tutti i requisiti (e quindi i vincoli) di un concetto si dice che modella tale concetto.
• Un concetto che è composto da un altro concetto e da vincoli aggiuntivi si dice che rifinisce il concetto (o i concetti).

Sintassi

A seconda della complessità di un vincolo, possiamo usare tre sintassi diverse per esprimerlo. Tutte le definizioni di seguito sono equivalenti ed è possibile combinarle insieme. Si tenga presente che std::integral è un concetto predefinito.

Dichiarazione completa ed esplicita

Molto utile se si devono imporre vincoli multipli.

template <typename T, typename Q>    requires std::integral<T> and std::integral<Q>auto add(T const t, Q const q) {    return t + q;}

Dichiarazione intermedia

template <std::integral T, std::integral Q>auto add(T const t, Q const q) {    return t + q;}

Dichiarazione compatta

auto add(std::integral auto const t, std::integral auto const q) {    return t + q;}

Soluzione

Per risolvere il problema dichiariamo il concept Addable e lo applichiamo ai parametri della funzione add. In questo caso usiamo la forma compatta.

#include <iostream>#include <concepts>template <typename T> concept Addable = requires(T a, T b) { a + b; // requisito 1};auto add(Addable auto const t, Addable auto const q) {    return t + q;}auto main() -> int {    std::cout << add(5, 6) << std::endl;    //std::cout << add("foo", "bar") << std::endl;  -> compilation error    return 0;}

Il template rifiuta in fase di compilazione qualsiasi tipo che non soddisfi il requisito. Rispetto alla versione non vincolata, il compilatore può produrre un errore più vicino all'interfaccia della funzione e quindi più semplice da interpretare.

Conclusione

Abbiamo visto come usare concept e vincoli per rendere espliciti i requisiti dei template e ottenere errori di compilazione più comprensibili. Per approfondire il tema, cppreference offre una guida completa a vincoli e concept.

Dopo aver lasciato Arch Linux sono passato a openSUSE Tumbleweed, che nel tempo è diventato il mio sistema operativo principale. L'ho usato per diversi mesi nello sviluppo software, per il gaming, nelle attività d'ufficio e nell'uso quotidiano.

La caratteristica che apprezzo di più è l'equilibrio tra aggiornamenti frequenti e affidabilità. Tumbleweed è una distribuzione rolling release, ma usa un processo di test che riduce molti dei problemi normalmente associati a questo modello.

Dopo aver provato diverse distribuzioni negli anni, Tumbleweed si distingue soprattutto per l'integrazione con KDE Plasma, gli strumenti di amministrazione e la qualità degli aggiornamenti. In questo articolo raccolgo gli aspetti che ho apprezzato e i compromessi incontrati.

Cosa funziona bene

Stabile e all'avanguardia

openSUSE Tumbleweed è una distribuzione rolling release, o a rilascio continuo, che offre agli utenti le caratteristiche e gli sviluppi più recenti del mondo Linux: kernel, driver, ambienti desktop e applicazioni aggiornate.

Questo è utile per utenti avanzati, sviluppatori software e videogiocatori che hanno bisogno di pacchetti recenti.

Tumbleweed viene aggiornato continuamente, quindi non richiede grossi avanzamenti di versione ogni sei mesi come accade con altre distribuzioni GNU/Linux.

Questa distribuzione non utilizza rigidi cicli di rilascio periodici, ma si basa su Factory, la base di sviluppo di openSUSE, aggiornata frequentemente.

Ogni aggiornamento, che segue un rigido standard industriale e un rigoroso processo di garanzia di qualità, viene pubblicato dopo aver superato test approfonditi e controlli di qualità attraverso la piattaforma openQA.

In sostanza, ogni nuova versione di un pacchetto viene testata individualmente e insieme ad altri gruppi di versioni, assicurando così la coerenza complessiva del sistema.

Inoltre, openSUSE utilizza un filesystem moderno come Btrfs, che consente agli utenti di creare istantanee dello stato del sistema e di eseguire il rollback a uno stato precedente in caso di problemi.

Tutto questo rende Tumbleweed un sistema adatto all'uso quotidiano anche se resta una rolling release. Una volta installato e configurato, può essere usato con continuità, a patto di mantenerlo aggiornato.

YaST e Snapper

Tumbleweed include YaST, un pannello di controllo molto completo. YaST, acronimo di Yet another Setup Tool, permette di gestire utenti, stampanti, sorgenti software, boot loader, partizioni, servizi, rete, virtualizzazione, AppArmor e altre parti del sistema da un'unica interfaccia.

OST mette a disposizione anche Snapper, creato da Arvin Schnell, per gestire le istantanee dei subvolumi del file system Btrfs e dei volumi LVM thin-provisioned. Oltre a creare ed eliminare istantanee, anche pianificate e automatiche, Snapper permette di confrontarle e ripristinare le differenze. In pratica consente di visualizzare versioni precedenti dei file e recuperare modifiche in modo controllato.

Insieme, YaST e Snapper semplificano l'amministrazione del sistema e rendono più semplice recuperare una configurazione funzionante dopo un aggiornamento problematico.

Configurazione intuitiva

Partiamo dall'installazione. L'installer di Tumbleweed è, a mio avviso, il più completo e semplice che ho mai incontrato. Permette di avere pieno controllo su quello che verrà installato e fornisce una configurazione di default più che sufficiente per la maggior parte degli utenti. Io prediligo e consiglio sempre di abilitare la cifratura completa del disco e il Logical Volume Management per gestire al meglio le risorse fisiche.

A installazione ultimata, se si dovesse avere bisogno di codec di terze parti, basterà installare opi, un front-end per accedere all'Open Build Service di openSUSE. Per ottenere direttamente tutti i codec, basterà usare il comando opi codecs, che abiliterà nuovi repository e installerà i codec.

Se dovessero servirvi i driver per la vostra scheda grafica NVIDIA, potranno essere installati direttamente da YaST oppure con il semplice comando zypper install-new-recommends --repo NVIDIA.

I lati negativi

Uno dei principali svantaggi di Tumbleweed è la possibile incompatibilità temporanea con alcuni moduli del kernel di terze parti o driver proprietari, soprattutto quelli grafici. Il kernel viene aggiornato frequentemente e alcuni componenti esterni potrebbero non essere subito compatibili con la nuova versione. La soluzione è compilare direttamente da sorgente tali moduli o driver, oppure evitare di usarli completamente.

Inoltre, l'installazione di software di terze parti non presenti nei repository, anche attraverso YaST Software, provoca un errore di integrity check. L'errore può essere facilmente ignorato e il software verrà comunque installato correttamente.

Nota dolente: il continuo scontro tra PackageKit e YaST Software. Rimuovendo il pacchetto PackageKit il problema sparisce.

openSUSE rimane una distribuzione di nicchia, quindi la documentazione di terze parti è meno abbondante. La documentazione ufficiale è ottima, anche se può risultare più essenziale rispetto a quella di distribuzioni come Fedora o Ubuntu.

Chiudo con un fastidio più che con un vero problema. Abilitando repository di terze parti, soprattutto Packman, possono comparire conflitti tra versioni dei pacchetti e aggiornamenti di sistema. Di solito basta aspettare qualche giorno prima di aggiornare oppure usare le versioni Flatpak delle applicazioni interessate.

Conclusione

Nella mia esperienza, openSUSE Tumbleweed offre pacchetti recenti senza sacrificare l'affidabilità del sistema. openQA, Btrfs, Snapper e YaST formano una base solida per una distribuzione rolling release.

I compromessi principali riguardano i moduli esterni al kernel e i possibili conflitti tra repository. Per ridurre questi problemi preferisco limitare i repository di terze parti e usare Flatpak per le applicazioni che richiedono codec proprietari. Con queste accortezze, Tumbleweed si è dimostrata una buona distribuzione per il lavoro e l'uso quotidiano.

F-Droid è spesso raccomandato dagli appassionati di sicurezza e privacy, e immagino che molti lo usino per scaricare, installare e aggiornare le proprie app preferite su smartphone. Anch'io ho usato F-Droid per molto tempo, ma dopo aver letto l'articolo di PrivSec sui problemi di sicurezza dell'applicazione ho deciso di cercare un'alternativa.

All'inizio usavo i feed RSS per seguire gli aggiornamenti delle applicazioni che mi interessavano. Scaricavo l'app direttamente dalla pagina GitHub o GitLab dello sviluppatore, mi iscrivevo al feed RSS e aspettavo le notifiche sugli aggiornamenti. Quando usciva una nuova release, tornavo alla pagina dedicata, scaricavo l'APK e installavo manualmente l'aggiornamento. In poco tempo, però, mi sono accorto che era un processo macchinoso, lento e snervante.

Mi serviva uno strumento capace di fare la stessa cosa automaticamente dopo una configurazione iniziale. La soluzione che ho scelto è Obtainium.

Cos'è Obtainium?

Obtainium è un'app che automatizza il download e l'installazione degli aggiornamenti delle app Android direttamente dai siti web di origine, cioè dai siti in cui i file sono disponibili per il download diretto.

Come scaricare Obtainium?

Per installare Obtainium bisogna partire dalla pagina ufficiale di GitHub.

Nella sezione di installazione selezioniamo "Get it on GitHub", apriamo gli asset della release e scegliamo l'APK adatto al dispositivo. Per un Google Pixel, per esempio, la variante è generalmente app-arm64-v8a. Al termine del download possiamo procedere con la normale installazione. Terminata l'installazione, sarà possibile aprire l'app. Consiglio di consentire la ricezione delle notifiche: vengono gestite localmente e non richiedono i servizi di Google Play.

L'interfaccia

Quando ho aperto Obtainium per la prima volta, sono rimasto piacevolmente sorpreso dal design.

Il progetto viene aggiornato spesso, quindi nomi e disposizione delle schermate potrebbero cambiare, ma il flusso generale resta simile.

L'app presenta una bottom navigation con queste voci:

• Apps, l'elenco completo delle app aggiunte a Obtainium.
• Add App, per registrare una nuova app da tracciare.
• Import/Export, per importare o esportare la lista delle app e la configurazione di Obtainium.
• Settings, per configurare l'applicazione.

Aggiungere un'app

Per aggiungere una nuova applicazione, clicchiamo su "Add App". In basso c'è un pulsante per vedere le fonti supportate. Alcune, come GitHub e Codeberg, sono etichettate come ricercabili: in questi casi si può cercare direttamente da Obtainium. Ci sono due campi di testo: nel primo possiamo inserire direttamente l'URL di origine dell'app che vogliamo aggiungere, mentre il secondo permette di cercarla tramite una stringa alfanumerica.

In questo caso cerchiamo NewPipe, dato che il progetto è su GitHub. La ricerca può restituire molti risultati, soprattutto per un progetto popolare; nel mio caso il primo era quello ufficiale del team di NewPipe. Per sicurezza, suggerisco sempre di verificare che il progetto sia quello corretto; ancora meglio, si può cercare la pagina dal browser e inserire manualmente l'URL.

Una volta convalidata la fonte, possiamo selezionarla premendo "Select".

Appare poi una sezione con opzioni aggiuntive. Tra le più importanti:

• Include prereleases, da abilitare soltanto se si desidera ricevere versioni di anteprima potenzialmente instabili.
• Fallback to older releases, è utile quando gli sviluppatori su GitHub non eseguono correttamente i rilasci e potrebbero avere un rilascio per iPhone e uno per Android. Se sono elencate in release diverse, quando Obtainium va a controllare qual è la versione più recente, se quella per iPhone è stata rilasciata per ultima, vedrà che non c'è un APK per Android disponibile da installare.
• Filter Release Titles by Regular Expression, per filtrare i titoli delle versioni in base a un'espressione regolare. È un caso limite, ma può capitare che nell'URL inserito siano presenti più applicazioni scaricabili.
• Track Only, solo tracciamento e niente aggiornamenti automatici. Io lascio questa opzione disattivata perché voglio che Obtainium scarichi gli APK per me, così da poterli installare automaticamente.

Ora possiamo selezionare "Add". L'applicazione viene scaricata sul dispositivo e, al termine, viene mostrata la schermata con i relativi dettagli. Cliccando su "Install", Android chiederà di abilitare l'installazione da sorgenti sconosciute per Obtainium. Accettiamo e installiamo l'app.

Terminata l'installazione, tornando all'elenco delle applicazioni possiamo vedere che NewPipe è ora monitorata, con l'ultima versione installata correttamente.

Sembra un processo lungo, ma una volta capiti i passaggi principali si fa tutto in pochi secondi.

E se Obtainium fosse affetto da malware?

Come sempre, bisogna essere scettici nei confronti di tutto ciò che si scarica dal web, che sia open source o meno. Una precauzione aggiuntiva consiste nell'installare manualmente la prima versione dalla fonte ufficiale e aggiungerla soltanto dopo a Obtainium. Android accetta infatti gli aggiornamenti solo quando la firma corrisponde a quella dell'app già installata; un APK firmato con una chiave diversa verrebbe rifiutato.

Limitazioni

Ci sono alcune limitazioni da tenere presenti. La prima è che le installazioni delle app avvengono in modo asincrono e non è possibile determinare direttamente il successo o il fallimento di un'installazione. Questo implica che gli stati e le versioni dell'installazione non siano sincronizzati con il sistema operativo fino al lancio successivo o fino a quando il problema non viene corretto manualmente. In sostanza, bisogna riavviare l'applicazione.

La seconda è che per alcune fonti, i dati sono raccolti tramite web scraping, che può facilmente fallire a causa di cambiamenti nel design del sito web. Chiunque abbia usato NewPipe avrà notato che, a ogni cambiamento dell'interfaccia di YouTube, l'extractor di NewPipe rischia di rompersi e di non riuscire più a estrarre dati fondamentali. Con Obtainium può succedere qualcosa di simile: è una conseguenza della natura fragile del web scraping.

Conclusione

Obtainium permette di seguire gli aggiornamenti direttamente dalle fonti ufficiali e riduce il lavoro manuale necessario per scaricare nuove release. Richiede attenzione nella scelta dei repository e non elimina i rischi legati alla distribuzione degli APK, ma offre un buon compromesso per chi vuole gestire applicazioni open source fuori dagli store tradizionali.

Dopo essere passato a GrapheneOS ho deciso di sostituire molte app con alternative più rispettose della privacy. Mi sono accorto, però, di quanto dipendessi dalle applicazioni delle grandi piattaforme.

Le applicazioni che usavo di più sul mio vecchio Samsung S10 erano queste:

• WhatsApp.
• Suite Google: Mail, Calendar e Drive.
• Suite Google Workspace.
• YouTube.
• Google Maps.
• Google Play Store.

Ovviamente queste sono solo alcune delle applicazioni principali che utilizzavo. In pratica, buona parte della mia vita digitale passava da Google, Microsoft e Meta.

Ho quindi cercato alternative open source e più attente alla privacy, accettando alcuni compromessi rispetto ai servizi che usavo in precedenza.

Sostituire WhatsApp

Questa è stata la fase più difficile, non per la scelta dell'app ma per la migrazione. Oggi quasi tutti usano WhatsApp, che per molte persone è diventato il canale principale. Ho dovuto avvisare tutti i miei contatti del cambiamento e del fatto che a breve non sarei più stato reperibile su WhatsApp. Le domande non sono mancate. Alla fine sono passato a Signal Messenger e mi hanno seguito in pochi. Per me non era un grande problema: chi voleva contattarmi poteva comunque chiamarmi, invece di mandarmi messaggi o audio interminabili.

Perché Signal e non alternative come Session, Briar, Element o SimpleX Chat?

In breve:

Gli elenchi di contatti su Signal sono crittografati utilizzando il PIN di Signal e il server non ha accesso ad essi. Anche i profili personali sono crittografati e condivisi solo con i contatti con cui si chatta. Signal supporta i gruppi privati, in cui il server non ha alcuna traccia dell'appartenenza al gruppo, dei titoli del gruppo, degli avatar del gruppo o degli attributi del gruppo. Signal ha metadati minimi quando è abilitato il Sealed Sender. L'indirizzo del mittente è crittografato insieme al corpo del messaggio e solo l'indirizzo del destinatario è visibile al server. Sealed Sender è abilitato solo per le persone presenti nell'elenco dei contatti, ma può essere abilitato per tutti i destinatari, con un rischio maggiore di ricevere spam.

Inoltre, il protocollo è stato sottoposto a verifiche indipendenti e le sue specifiche sono pubbliche.

Ciliegina sulla torta: l'interfaccia utente di Signal è molto simile a quella di WhatsApp.

Sostituire la suite Google: Mail, Calendar e Drive

Questi sono alcuni dei provider che ho valutato, suddivisi per categoria.

Servizi email:

• Proton Mail
• Tutanota
• Mailbox.org

Servizi cloud storage:

• Proton Drive
• Tresorit
• Peergos

Servizi di calendario:

• Proton Calendar
• Tuta (calendario di Tutanota)

Le opzioni erano due: separare tutti i servizi o affidarsi a un'unica azienda.

Ho quindi fatto la mia scelta, passando al pacchetto di Proton. Le motivazioni che mi hanno portato a questa conclusione sono molteplici. Ho scelto Proton perché riunisce posta, calendario e spazio cloud in un unico servizio, con applicazioni curate e un modello orientato alla privacy.

In sintesi ho sostituito Gmail, Google Calendar e Google Drive con Proton Mail, Proton Calendar e Proton Drive.

Rimpiazzare la suite Google Workspace

Purtroppo per questa non ho trovato una valida alternativa. La scelta che ho fatto è stata abbinare Collabora Office per l'editing dei documenti a Syncthing per la sincronizzazione.

Questo perché Collabora Online (Office) non è un software autonomo. Al contrario, la suite per ufficio online si integra in un'infrastruttura esistente e richiede una soluzione cloud come base (NextCloud, Dropbox, ecc...).

Rimpiazzare YouTube

Uso YouTube principalmente per documentarmi, ma anche per svago. In questo caso continuo a usare la piattaforma di Google, ma attraverso un client di terze parti.

Fortunatamente non ho dovuto fare molta ricerca: usavo già NewPipe da diversi anni.

NewPipe è un'applicazione open source, ricca di funzioni e rispettosa della privacy, che permette di guardare i video pubblicati su YouTube. L'app offre molte funzioni dell'esperienza YouTube senza annunci invasivi e senza le autorizzazioni richieste dall'app ufficiale. In più è open source e il codice è consultabile su GitHub.

Rimpiazzare Google Maps

Qui l'unica soluzione è passare a un client basato su OpenStreetMap.

Le alternative sono:

• OsmAnd
• Organic Maps
• Magic Earth

Le prime due sono eccezionali sia nella consultazione delle mappe che nelle funzionalità offerte, tuttavia peccano nella navigazione in tempo reale. Durante la navigazione, spesso consigliano strade secondarie molto scomode o selezionano percorsi che allungano inutilmente il tragitto. La terza eccelle dove le altre falliscono, tuttavia il codice sorgente di questo applicativo non è consultabile.

Uso principalmente Organic Maps per l'interfaccia pulita e per le escursioni. Quando devo guidare su percorsi stradali che non conosco, preferisco invece Magic Earth.

Rimpiazzare Google Play Store

Come per YouTube, una soluzione consiste nell'usare un client alternativo per accedere al catalogo del Play Store. L'unica app che svolge questa mansione impeccabilmente è Aurora Store. Aurora Store è una alternativa gratuita al Google Play Store. Con questa app è possibile scaricare applicazioni, aggiornare quelle già esistenti, ricevere dettagli sui tracker in-app, nascondere la propria posizione, cercare applicazioni e fare molto altro. Gli sviluppatori di Aurora hanno anche curato molto il design e l'interfaccia dell'app.

Conclusione

Sostituire le applicazioni più diffuse richiede compromessi: a volte si perde comodità, altre volte si guadagna controllo. Per me il passaggio ha avuto senso perché ha ridotto la dipendenza dalle piattaforme principali senza rendere lo smartphone scomodo da usare.

Nel giugno del 2023 il mio vecchio Samsung Galaxy S10 ha deciso di passare a miglior vita dopo una rovinosa caduta dalle scale.

Stavo già pensando di sostituirlo e cercavo un dispositivo sul quale avere maggiore controllo, con un sistema orientato alla sicurezza e alla privacy.

Ho quindi confrontato diversi sistemi basati sull'Android Open Source Project (AOSP), modificati con obiettivi differenti in materia di privacy e sicurezza.

Alla fine ho ristretto la scelta a tre alternative: CalyxOS, LineageOS e GrapheneOS.

Dopo averle valutate ho scelto GrapheneOS e acquistato un dispositivo ufficialmente supportato.

Vediamo che cos'è GrapheneOS, come si installa e quali funzionalità mi hanno convinto a sceglierlo.

Cos'è GrapheneOS?

GrapheneOS è un sistema operativo basato su Android Open Source Project, con molte funzionalità aggiuntive per sicurezza e privacy. È open-source, supporta ufficialmente tutti i dispositivi Google Pixel più recenti e può essere installato con grande facilità per sostituire il sistema operativo del Pixel di Google.

Per impostazione predefinita non include né applicazioni né servizi Google: in sostanza, spezza il controllo che Google esercita sul dispositivo mobile.

Il risultato è un dispositivo spartano, in senso positivo: solo applicazioni stock del progetto AOSP, tutto da configurare e senza vincoli imposti da terzi.

Come installare GrapheneOS?

Il progetto fornisce un'interfaccia web minimale che permette di installare il sistema operativo seguendo istruzioni molto chiare.

Per iniziare si parte dalla guida ufficiale e si sceglie tra l'installazione tramite WebUSB e quella classica da terminale.

Successivamente basta seguire la guida passo passo che viene fornita.

Alcune funzionalità di GrapheneOS

Quella che segue è una panoramica non esaustiva delle funzionalità di GrapheneOS. Per i dettagli conviene consultare la pagina ufficiale delle funzionalità.

Protezione contro le vulnerabilità zero-day, oltre a funzionalità aggiuntive per utenti e rete.

GrapheneOS protegge i suoi utenti dalle vulnerabilità zero-day. Per ottenere questo risultato GrapheneOS riduce la superficie di attacco rimuovendo il codice non necessario dal sistema operativo.

Per la gestione delle applicazioni, GrapheneOS include toggle dedicati per i permessi di rete e dei sensori, quasi assenti nelle ROM personalizzate basate su AOSP.

A livello di rete, il sistema operativo supporta la randomizzazione dell'indirizzo MAC per ogni connessione e una modalità solo LTE che consente di disattivare le reti meno recenti o più nuove, riducendo la superficie di attacco. Il Wi-Fi e il bluetooth (come il mobile hotspot) supportano la disattivazione automatica se non sono collegati a un dispositivo, risparmiando la durata della batteria e prevenendo potenziali attacchi wireless esterni.

Degna di nota è la funzione di screenshot privato che disattiva l'inclusione di metadati sensibili.

Sandboxing e protezione dalla corruzione della memoria.

Per ridurre notevolmente le vulnerabilità del sistema operativo, il gruppo dietro a GrapheneOS dedica notevoli risorse allo sviluppo di linguaggi e librerie sicuri per la memoria, strumenti di analisi statica e dinamica e molto altro.

In GrapheneOS viene applicato il sandboxing a vari livelli, rafforzando il kernel e i componenti del sistema operativo. In sostanza, i componenti vengono isolati in ambienti separati, limitando l'accesso delle applicazioni e l'impatto di eventuali vulnerabilità.

Le applicazioni

GrapheneOS fornisce una serie di applicazioni rinforzate, pensate per ridurre permessi e superficie di attacco.

Innanzitutto, c'è il WebViewer e il browser Vanadium. Vanadium è una variante di Chromium rafforzata con ulteriori misure di sicurezza e privacy.

Secure Camera, realizzata dal team di GrapheneOS, è la fotocamera predefinita del sistema. Include le funzioni tradizionali e aggiunge opzioni extra per privacy e sicurezza, come la scansione QR senza permessi di rete o accesso ai media e la rimozione opzionale dei metadati EXIF da foto e video.

Auditor fornisce invece una verifica basata sull'hardware dell'integrità del software e del firmware del dispositivo. È una funzione speciale, utile soprattutto per persone esposte a rischi mirati.

Infine, Secure PDF Viewer è un lettore PDF che non richiede permessi e opera in ambiente sandbox.

Gestione dei profili migliorata

GrapheneOS ha migliorato la funzionalità dei profili utente e sta migliorando il monitoraggio di altri profili.

Nel dettaglio fornisce le possibilità di:

• Aggiungere più profili.
• Terminare la sessione.
• Disabilitare l'installazione di app in determinati profili.
• Installare le app disponibili di un profilo verso un altro.
• Inoltro delle notifiche dai profili non in uso verso la sessione corrente.

Google in sandbox

Le app di Google possono essere installate su GrapheneOS attraverso un livello di compatibilità dedicato. Le app verranno private dell'accesso speciale o dei privilegi che di solito hanno. È possibile utilizzare le applicazioni e i servizi di Google, ma saranno modificati per ottenere elevati standard di privacy e sicurezza.

Conclusione

Uso GrapheneOS da circa un anno e l'esperienza è stata positiva. I prodotti orientati alla privacy spesso richiedono compromessi significativi nell'usabilità; in questo caso l'impatto sull'uso quotidiano è rimasto contenuto.

Non ho dovuto cambiare radicalmente il modo in cui uso il telefono. Il passaggio più scomodo è stato sostituire molte applicazioni legate all'ecosistema Google, tema che merita un post a parte.

Il limite principale riguarda le applicazioni che dipendono dai servizi Google Play. Senza installare il livello di compatibilità dedicato, alcune funzioni, come le notifiche push basate su Firebase, possono non essere disponibili.

Nel complesso ho ottenuto un telefono più controllabile, orientato alla sicurezza e alla privacy, senza rinunciare alle funzioni che uso ogni giorno.

Un kill switch impedisce al traffico di uscire attraverso la connessione ordinaria quando il tunnel WireGuard non è attivo, evitando di esporre accidentalmente l'indirizzo IP reale.

Dopo il passaggio da iptables a nftables, ho dovuto tradurre le regole nella configurazione del peer di wg-quick. Dato che non ho trovato informazioni utili al momento della configurazione, ho deciso di condividere la soluzione che ho usato.

Configurazione

Questa configurazione presuppone che le regole nftables vengano ricaricate tramite il sistema di init.

Nel file di configurazione di wg-quick aggiungiamo queste due righe.

PostUp = nft insert rule <family> <table> <chain> ip oifname != "%i" mark != $(wg show %i fwmark) fib daddr type != local counter rejectPostDown = systemctl restart <service>

Queste righe vanno adattate al vostro sistema e al vostro firewall.

PostUp

Eseguiamo nft list ruleset e cerchiamo la catena che contiene type filter hook output.

Ora adattiamo la riga PostUp con le informazioni trovate. Nel mio caso questa istruzione si trova nella tabella firewalld, parte della famiglia inet, nella chain filter_OUTPUT.

PostDown

Nella riga PostDown inseriamo il comando necessario a ricaricare il firewall. Nell'esempio viene usato systemd.

Esempio

PostUp = nft insert rule ip inet firewalld filter_OUTPUT oifname != "%i" mark != $(wg show %i fwmark) fib daddr type != local counter rejectPostDown = systemctl restart firewalld.service

nftables è il framework del progetto Netfilter introdotto nel kernel Linux come successore di iptables. Nasce per offrire un'interfaccia più coerente e flessibile, sostituendo strumenti separati come iptables, ip6tables, arptables ed ebtables.

Con iptables era necessario mantenere separati i set di regole IPv4 e IPv6, gestiti rispettivamente da iptables e ip6tables.

A parte una nuova sintassi e alcuni aggiornamenti, il funzionamento di nftables è simile a quello del suo predecessore.

Catene e regole

Le tabelle più comuni di iptables usano catene predefinite come INPUT, OUTPUT e FORWARD. Ogni catena contiene regole valutate in ordine; se nessuna corrisponde, viene applicata la politica predefinita, per esempio ACCEPT o DROP.

iptables può diventare inefficiente perché i pacchetti attraversano le catene previste anche quando alcune non sono realmente necessarie, introducendo controlli superflui.

nftables mantiene un modello basato su tabelle, catene e regole, ma non impone catene predefinite: è possibile creare soltanto quelle necessarie e collegarle agli hook del kernel appropriati.

Differenza di sintassi

La sintassi di iptables può diventare difficile da leggere quando le regole crescono. nftables usa una grammatica più uniforme e permette di esprimere molti casi con meno duplicazioni.

Per creare una nuova rule si usa una forma simile a questa:

nft add rule family_type table_name chain_name handle handle_value statement

Vediamo alcuni esempi equivalenti tra iptables e nftables.

Blocco di una connessione

Questo comando blocca il traffico in ingresso dall'indirizzo IP 192.168.7.5.

# iptablesiptables -A INPUT -s 192.168.7.5 -j DROP# nftablesnft add rule ip filter INPUT ip saddr 192.168.7.5 counter drop

Abilitare la connessione SSH in entrata

Questo comando abilita la connessione SSH in entrata.

# iptablesiptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT# nftablesnft add rule ip filter INPUT tcp dport 22 ct state new,established counter accept

Questo comando abilita la connessione SSH in entrata per tutta la rete 192.168.155.0/24.

# iptablesiptables -A INPUT -p tcp -s 192.168.155.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT# nftablesnft add rule ip filter INPUT ip saddr 192.168.155.0/24 tcp dport 22 ct state new,established counter accept

Abilitare la connessione MySQL sull'interfaccia di rete eth0

Con questo comando si abilitano le connessioni sull'interfaccia di rete eth0 verso il server di MySQL.

# iptablesiptables -A INPUT -i eth0 -p tcp --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT# nftablesnft add rule ip filter INPUT iifname eth0 tcp dport 3306 ct state new,established counter accept

Abilitare il traffico HTTP e HTTPS

Con questo comando si abilita il traffico sulla porta 80 e sulla 443.

# iptablesiptables -A INPUT -p tcp -m multiport --dports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT# nftablesnft add rule ip filter INPUT ip protocol tcp tcp dport { 80, 443 } ct state new,established counter accept

Conclusione

nftables offre un modello più uniforme per gestire IPv4, IPv6 e altri protocolli, con una sintassi più leggibile e una configurazione più flessibile. Per approfondire la creazione di tabelle e catene si può consultare la documentazione di Arch Linux.

Durante lo sviluppo di Enne 2D Engine mi sono chiesto più volte perché continuassi a usare gli header guard quando avrei potuto scrivere semplicemente #pragma once.

Ho quindi confrontato le due soluzioni, i loro vantaggi e i rispettivi limiti.

Perché serve proteggere i file di dichiarazione?

Principio ODR

La One Definition Rule è una regola fondamentale del C++.

In forma semplificata, stabilisce che una funzione, una variabile o un tipo debbano rispettare precisi vincoli sul numero di definizioni presenti nel programma.

Violare il principio ODR può causare errori di "multiple definitions" in compilazione o problemi in fase di linking, quando il linker non riesce a stabilire quale definizione usare.

Nell'esempio seguente, con tre file definiti, la compilazione fallisce a causa di una definizione multipla di struct foo.

File alpha.hpp

struct foo {};

File bravo.hpp

#include "alpha.hpp"

File charlie.hpp

#include "alpha.hpp"#include "bravo.hpp"

Il preprocessore, terminate le opportune sostituzioni, restituisce il seguente risultato.

struct foo {};struct foo {};

Come facciamo quindi a rispettare l'ODR?

La prima soluzione che viene in mente, anche se molto spartana, è gestire manualmente la gerarchia delle direttive #include. Nell'esempio precedente dovremmo evitare l'inclusione di alpha.hpp in charlie.hpp. È una tecnica fragile e non scala su progetti medio-grandi.

Esistono due soluzioni comuni:

• Header guards.
• Direttiva #pragma once.

Header guards

La soluzione prevista dallo standard consiste nell'uso degli header guard. Queste protezioni impediscono che un header venga incluso più di una volta nella stessa unità di compilazione. Per ottenere questo risultato utilizzano le macro del preprocessore per verificare se l'intestazione è già stata inclusa in precedenza. Nel caso in cui fosse già stata inclusa, queste clausole impediscono una successiva reinclusione.

Il #define crea una macro, ovvero l'associazione di un identificatore o un identificatore con parametri con una stringa di token. Dopo che la macro è stata definita, il compilatore può sostituire la stringa di token per ogni occorrenza dell'identificatore presente nel file di origine.

Riprendendo l'esempio precedente, con poche modifiche otteniamo:

File alpha.hpp

#ifndef ALPHA_HPP#define ALPHA_HPPstruct foo {};#endif // ALPHA_HPP

File bravo.hpp

#ifndef BRAVO_HPP#define BRAVO_HPP#include "alpha.hpp"#endif // BRAVO_HPP

File charlie.hpp

#ifndef CHARLIE_HPP#define CHARLIE_HPP#include "alpha.hpp"#include "bravo.hpp"#endif // CHARLIE_HPP

Il preprocessore terminate le opportune sostituzioni, restituisce il seguente risultato.

struct foo {};

Quando si lavora su progetti grandi, è importante definire linee guida chiare per il nome della macro: usare solo il nome del file può portare facilmente a conflitti. Altri problemi nascono quando si copia un header e ci si dimentica di aggiornare la macro, oppure quando manca la direttiva #endif. Per questo è utile affidarsi anche a strumenti come clang-tidy.

Io ad esempio per definire il nome di una macro seguo questo schema <PROJECT_ROOT>_<RELATIVE_PATH_TO_HPP_FILE>_<FILE_NAME>_HPP_.

Questo schema evita che due file con lo stesso nome producano lo stesso identificatore.

Supponiamo di avere la seguente struttura, con root directory CPP_PROJECT, e due file con lo stesso nome in directory diverse.

.├── libfoo│   ├── CMakeLists.txt│   ├── docs│   │   └── CMakeLists.txt│   ├── include│   │   └── libfoo│   │       ├── detail│   │       │   └── alpha.hpp│   │       └── common│   │           └── alpha.hpp

Il nome della macro sul file alpha.hpp nella directory detail sarà:

#define CPP_PROJECT_LIBFOO_INCLUDE_LIBFOO_DETAIL_ALPHA_HPP_

Il nome della macro sul file alpha.hpp nella directory common sarà:

#define CPP_PROJECT_LIBFOO_INCLUDE_LIBFOO_COMMON_ALPHA_HPP_

Pragma once

L'alternativa agli header guard, molto diffusa anche se non parte dello standard C++, è la direttiva #pragma once.

File alpha.hpp

#pragma oncestruct foo {};

File bravo.hpp

#pragma once#include "alpha.hpp"

File charlie.hpp

#pragma once#include "alpha.hpp"#include "bravo.hpp"

Il preprocessore terminate le opportune sostituzioni, restituisce il seguente risultato.

struct foo {};

Si scrive meno codice e si eliminano i possibili conflitti tra i nomi delle macro. Questa soluzione, però, non offre soltanto vantaggi.

Non proprio: questa direttiva non fa parte dello standard, quindi i compilatori non sono obbligati da ISO C++ a supportarla.

Ma perché non fa parte dello standard?

La risposta è nella complessità che un compilatore affronta per rilevare correttamente e coerentemente l'uguaglianza dei file. Uno dei problemi noti riguarda l'identificazione dello stesso file attraverso percorsi o collegamenti simbolici diversi. In alcuni casi il compilatore potrebbe non riconoscere che si tratta dello stesso header e includerlo più volte. Si veda https://en.m.wikipedia.org/wiki/Pragma_once#Caveats.

Non vi è, poi, garanzia che il supporto di #pragma once sia lo stesso tra i diversi compilatori, il che può essere un problema per alcuni sviluppatori.

Header guards o pragma once?

Dipende dal caso.

La scelta dipende dai requisiti di portabilità e dalle convenzioni del progetto.

Gli header guard sono standard e funzionano ovunque, a costo di qualche riga in più e di una convenzione affidabile per le macro. #pragma once è più conciso ed è supportato dai compilatori più diffusi, ma non fa parte dello standard.

Conclusione

Nei progetti in cui la portabilità è prioritaria preferisco gli header guard. In contesti con una toolchain ben definita, #pragma once resta comunque una scelta pragmatica e ampiamente supportata.

Supponiamo di stare lavorando a un progetto con Git. Per errore o distrazione può capitare di creare un commit che non doveva esistere. In quella situazione bisogna annullarlo nel modo corretto, scegliendo tra due approcci molto diversi.

I comandi principali sono:

• Il comando revert
• Il comando reset

Comando revert

Il comando revert crea un nuovo commit che annulla le modifiche del commit selezionato.

La forma base è:

git revert <commit to revert>

Vediamo i passaggi.

1. Lanciare il comando git log.
2. Ricercare il commit che si vuole ripristinare.
3. Copiare l'hash del commit da annullare.
4. Usare il comando git revert <commit to revert>.

Esempio.

cd project_with_a_dot_git_foldergit log### Esempio di stampa post git log## commit 2596f783998c8ec230b38a044b49e39d07770901 (HEAD -> main, origin/main)# Author: Foo <foo@bar.com># Date:   Tue Apr 9 14:47:17 2024 +0200##     Add something bad## commit 2ce5e2e7e36f23673b32ccef7f908f161527142b# Author: Foo <foo@bar.com># Date:   Tue Apr 2 23:33:27 2024 +0200##     Update somethinggit revert 2ce5e2e7e36f23673b32ccef7f908f161527142b

Dopo l'esecuzione viene creato un nuovo commit che applica le modifiche inverse, senza riscrivere la cronologia esistente.

Comando reset

L'alternativa è il comando reset. git reset modifica la cronologia locale e va quindi usato con attenzione, soprattutto se i commit sono già stati condivisi. Il comando sposta HEAD al commit indicato; il comportamento dei file e dell'indice dipende dall'opzione scelta.

Soft reset

L'opzione --soft sposta HEAD mantenendo nell'indice le modifiche introdotte dai commit rimossi.

git reset --soft HEAD~1

Hard reset

L'opzione --hard riallinea indice e directory di lavoro al commit indicato, eliminando anche le modifiche locali non salvate.

git reset --hard HEAD~1

Conclusione

git revert è la scelta più sicura per una cronologia già condivisa, perché aggiunge un nuovo commit senza riscrivere quelli esistenti. git reset è utile soprattutto per correggere una cronologia locale, prima che venga pubblicata.

Dopo la scoperta della backdoor in XZ Utils (CVE-2024-3094), in molti suggerivano di eseguire direttamente xz --version per controllare la versione installata.

Se si sospetta che un eseguibile possa essere compromesso, è preferibile non avviarlo nemmeno per conoscerne la versione. Il package manager può fornire la stessa informazione senza eseguire il binario.

Vediamo dunque come verificare correttamente la versione di un pacchetto installato su sistemi GNU/Linux. Per comodità ho separato le distribuzioni in base al gestore dei pacchetti.

Tenete presente che i comandi seguenti filtrano esplicitamente i pacchetti con xz nel nome.

Debian

Questi comandi funzionano su tutte le distribuzioni basate su Debian.

# aptapt list xz# or with more detailsapt show xz# or with dpkgdpkg-query -l '*xz*'# ordpkg-query -l | grep xz

Fedora

Questi comandi valgono per Fedora e per le distribuzioni che usano RPM e DNF. Si può usare anche RPM Package Manager (RPM).

# dnfdnf list installed xz*# ordnf list installed | grep xz# or with yumyum list installed | grep xz# or via RPMrpm -qa | grep xz

Arch Linux

Questi comandi funzionano anche per le distribuzioni basate su Arch. Tra cui Manjaro, EndeavourOS e persino SteamOS.

# pacmanpacman -Qs xz# orpacman -Q | grep xz

openSUSE Tumbleweed

I comandi sono validi anche per le distribuzioni basate su SUSE e openSUSE come GeckoLinux e Linux Kamarada. Si può anche usare RPM.

# zypperzypper info xz# orrpm -qa | grep xz

Da quando ho iniziato a lavorare con Qt, mi sono chiesto come si potesse implementare un meccanismo signal/slot usando il C++ moderno.

Wikipedia lo definisce così.

[...] a language construct [...] which makes it easy to implement the Observer pattern while avoiding boilerplate code. The concept is that GUI widgets can send signals containing event information which can be received by other controls using special functions known as slots.

-- Wikipedia

In termini più semplici, il meccanismo signal/slot consente agli oggetti di comunicare attraverso eventi. Esistono già ottime librerie che implementano questo pattern; in questo articolo presento una piccola soluzione personale, costruita soprattutto per comprenderne meglio il funzionamento.

Diagramma UML

Il diagramma seguente riassume la struttura del progetto.

Codice

Poiché l'implementazione usa classi template, il codice si trova interamente in un file header. I commenti nel sorgente descrivono responsabilità e comportamento dei componenti principali.

#ifndef LIBSIGSLOTPP_INCLUDE_LIBSIGSLOTPP_SIGNAL_HPP_#define LIBSIGSLOTPP_INCLUDE_LIBSIGSLOTPP_SIGNAL_HPP_#include <functional>#include <memory>namespace sigslotpp {typedef std::size_t IDType;/** * @brief Interface ISlotConnection * It provides a simple interface that identifies the Slot and its main * connectivity operations. * ISignal can access private and protected regions for design purposes. */class ISlotConnection { private:  friend class ISignal;  IDType id_;         ///< identifier and index into the signal slots vector.  bool isConnected_;  ///< slot connection status.  bool isBlocked_;    ///< slot connection block status. protected:  /**   * @brief Getter for the identifier   * @return id_   */  IDType id() const noexcept { return id_; }  /**   * @brief Getter/Setter for the identifier   * @return a reference to id_   */  IDType &id() noexcept { return id_; }  /**   * @brief Clears the slot connection   * Where the real disconnection happens.   * This gets called by the ISlotConnection::disconnect() function, the   * implementation depends on the child subclasses.   */  virtual void clear() noexcept = 0; public:  ISlotConnection() = delete;  // not needed but better for compilation error  /**   * @brief Primary constructor   * @post id_ == id   * @post isConnected__ == isConnected   * @post isBlocked_ == isBlocked   */  explicit ISlotConnection(const IDType id, const bool isConnected = true,                           const bool isBlocked = false) noexcept      : id_(id), isConnected_(isConnected), isBlocked_(isBlocked) {}  /**   * @brief Destructor   */  virtual ~ISlotConnection() {} public:  /**   * @brief Checks the connection status   * Used to see if a slot is still connected to a Signal   */  virtual bool isConnected() const noexcept { return isConnected_; }  /**   * @brief Checks if the connection is blocked   * Used to temporarily disable slot invocation.   * @return true if the slot invocation is blocked else false.   */  bool isBlocked() const noexcept { return isBlocked_; } public:  /**   * @brief Blocks the slot invocation   * @post isBlocked_ == true   */  void block() noexcept { isBlocked_ = true; }  /**   * @brief Unblocks the slot invocation   * @post isBlocked_ == false   */  void unblock() noexcept { isBlocked_ = false; }  /**   * @brief Disconnects the slot from the signal   * @post isConnected_ == false   */  void disconnect() {    if (isConnected_) {      isConnected_ = false;      clear();    }  }};/** * @brief Class Connection * This class allows interaction with an ongoing signal-slot connection and * exposes an interface to manipulate and query the status of this connection. * Note that Connection is not a RAII object, one does not need to hold one * such object to keep the signal-slot connection alive. */class Connection { private:  std::weak_ptr<ISlotConnection> slot_;  ///< the slot to manipulate and query public:  Connection() = delete;  // not needed but better for compilation error  /**   * @brief Primary constructor   * @param slot that will be handled by this connection   */  explicit Connection(std::weak_ptr<ISlotConnection> &&slot) : slot_(slot) {}  /**   * @brief Destructor   */  virtual ~Connection() {} public:  /**   * @brief Checks if this connection is still valid   * To have this information just see if the std::weak_ptr is expired   * @return true if the connection is valid else false   */  bool isValid() const noexcept { return !slot_.expired(); }  /**   * @brief Checks if the slot is still connected to its signal   * @return true if the slot is still connected else false   * @see ISlotConnection::isConnected()   */  bool isConnected() const noexcept {    std::shared_ptr<ISlotConnection> d = slot_.lock();    return d && d->isConnected();  }  /**   * @brief Checks if the slot connection is blocked   * @return true if the slot connection is blocked else false   * @see ISlotConnection::isBLocked()   */  bool isBlocked() const noexcept {    std::shared_ptr<ISlotConnection> d = slot_.lock();    return d && d->isBlocked();  }  /**   * @brief Blocks the slot invocation   * @see ISlotConnection::block()   */  void block() noexcept {    std::shared_ptr<ISlotConnection> d = slot_.lock();    if (d) d->block();  }  /**   * @brief Unblocks the slot invocation   * @see ISlotConnection::unblock()   */  void unblock() noexcept {    std::shared_ptr<ISlotConnection> d = slot_.lock();    if (d) d->unblock();  }  /**   * @brief Disconnects the slot from its signal   * @see ISlotConnection::disconnect()   */  void disconnect() {    std::shared_ptr<ISlotConnection> d = slot_.lock();    if (d) d->disconnect();  }};////////////////////////////////** * @brief Interface ISignal * It provides a simple interface that identifies the Signal and its essential * functions. */class ISignal { protected:  /**   * @brief Getter for specified ISlotConnection identifier   * @return id of the specified slot   */  IDType idOf(ISlotConnection *const slotPtr) const noexcept {    return slotPtr->id();  }  /**   * @brief Getter/Setter for specified ISlotConnection identifier   * @return a reference to id of the specified slot   */  IDType &idOf(ISlotConnection *const slotPtr) noexcept {    return slotPtr->id();  } public:  /**   * @brief Destructor   */  virtual ~ISignal() {}  /**   * @brief Disconnect the slot from this signal   * @param slot a pointer to the slot to disconnect from   */  virtual void disconnect(ISlotConnection *const slot) = 0;};/** * @brief Interface ISlot * It provides a simple interface that identifies the Slot and its core * invocation functionality. * @tparam Args... the argument types of the function to call */template <typename... Args>class ISlot : public ISlotConnection { private:  ISignal &signal_;  ///< reference to the signal protected:  /**   * @brief Clears the slot connection   */  virtual void clear() noexcept override { signal_.disconnect(this); }  /**   * @brief Invokes the function   * Where the function is really invoked.   * This gets called by the ISlot::operator()() function, the   * implementation depends on the child subclasses.   * @param args the arguments of the function to call   */  virtual void invoke(Args... args) = 0; public:  ISlot() = delete;  // not needed but better for compilation error  /**   * @brief Primary constructor   * We have a reference that must be initialized, so no default constructor   * allowed here.   * @param id the slot identifier   * @param signal the reference of the signal connected to this slot   * @post signal_ points to the signal connected to this slot   * @see ISlotConnection   */  ISlot(const IDType id, ISignal &signal) noexcept      : ISlotConnection(id), signal_(signal) {}  /**   * @brief Invokes the function   * Invokes or calls the function stored in the slot.   * Take note that i add an extra template here for flexibility and design   * purposes. As mentioned in Signal::emit() we use the signature here.   * At the end it is used std::forward to forward lvalues as either lvalues   * or as rvalues, depending on Params.   * @see Signal::emit()   * @param params the parameters of the function to call   * @tparam ...Params types of the parameters of the function to call   */  template <typename... Params>  void operator()(Params &&...params) {    if (ISlotConnection::isConnected() && !ISlotConnection::isBlocked())      invoke(std::forward<Params>(params)...);  }};/** * @brief Class SimpleSlot * Basic slot that does not track anything and thus it is imperative that what * is called by the std::function must exceeds the lifetime of signal this * slot is connected to. * @tparam Args... the argument types of the function to call */template <typename... Args>class SimpleSlot final : public ISlot<Args...> { private:  std::function<void(Args...)>      function_;  ///< function to be invoked by this slot protected:  /**   * @copydoc ISlot::invoke()   */  void invoke(Args... args) override final {    function_(std::forward<Args>(args)...);  } public:  SimpleSlot() = delete;  // not needed but better for compilation error  /**   * @brief Primary constructor   * @param id the slot identifier   * @param function to be invoked by this slot   * @param signal the reference to the signal this slot is connected to   * @see ISlot   */  SimpleSlot(const IDType id, std::function<void(Args...)> &&function,             ISignal &signal) noexcept      : ISlot<Args...>(id, signal),        function_(std::forward<std::function<void(Args...)>>(function)) {}};/** * @brief Class TrackingSlot * Tracking slot that tracks an object with a std::weak_ptr, it is auto * disconnected upon expiration of the std::weak_ptr thus no need to take care * of complex object lifetime managment. * @tparam T the type of the object to track * @tparam Args... the argument types of the function to call */template <typename T, typename... Args>class TrackingSlot final : public ISlot<Args...> { private:  std::function<void(Args...)>      function_;  ///< function to be invoked by this slot  std::weak_ptr<T>      objectPtr_;  ///< the pointer to the object this slot is tracking protected:  /**   * @copydoc ISlot::invoke()   */  void invoke(Args... args) override final {    // this is probably useless in signle thread    auto sp = objectPtr_.lock();    if (!sp) {      ISlotConnection::disconnect();      return;    }    if (ISlotConnection::isConnected()) {      function_(args...);    }  } public:  TrackingSlot() = delete;  // not needed but better for compilation error  /**   * @brief Primary constructor   * @param id the slot identifier   * @param objectPtr the pointer to the object to track   * @param function to be invoked by this slot   * @param signal the reference to the signal this slot is connected to   * @see ISlot   */  TrackingSlot(const IDType id, std::weak_ptr<T> &&objectPtr,               std::function<void(Args...)> &&function,               ISignal &signal) noexcept      : ISlot<Args...>(id, signal),        function_(std::forward<std::function<void(Args...)>>(function)),        objectPtr_(std::forward<std::weak_ptr<T>>(objectPtr)) {} public:  /**   * @brief Checks if the connection still there   */  bool isConnected() const noexcept override final {    return !objectPtr_.expired() && ISlotConnection::isConnected();  }};/** * @brief Class Signal * This class manages a collection of ISlots * @tparam R the return type of the function to call * @tparam Args... the argument types of the function to call */template <typename R, typename... Args>class Signal final : public ISignal { private:  std::vector<std::shared_ptr<ISlot<Args...>>>      slots_;  ///< slots connected to this Signal  /**   * @brief Disconnects the specified slot   * @param slot the pointer to the slot to disconnect from   * @post slots_.size() decremented by one   */  void disconnect(ISlotConnection *const slot) noexcept override final {    IDType index = idOf(slot);    if (!slots_.empty()) {      std::swap(slots_[index], slots_.back());      idOf(slots_[index].get()) = index;      slots_.pop_back();    }  } public:  /**   * @brief Default constructor   * @post slots_.size() == 0   */  Signal() noexcept : slots_() {}  /**   * @brief Destructor   */  virtual ~Signal() noexcept { disconnectAll(); }  /**   * @brief Move constructor   * @see Signal::operator=()   */  Signal(Signal &&other) noexcept : slots_() { *this = std::move(other); }  /**   * @brief Move assignment operator   * @return a reference to this   * @post slots_ == other.slots_   */  Signal &operator=(Signal &&other) noexcept {    if (this != &other) {      slots_ = std::move(other.slots_);    }    return *this;  }  /**   * @brief Connects a slot to the signal   * Connects a std::function to the signal.   * @param function the signal connects to   * @return a Connection instance for managment purposes   * @post slots_.size() incremented by one   */  Connection connect(std::function<R(Args...)> &&function) noexcept {    IDType id = slots_.size();    std::shared_ptr<ISlot<Args...>> slot =        std::make_shared<SimpleSlot<Args...>>(            id, std::forward<std::function<R(Args...)>>(function), *this);    slots_.push_back(slot);    return Connection(std::weak_ptr(slots_[id]));  }  /**   * @brief Connects and tracks a slot to the signal   * Connects a std::function to the signal but this time the slot is tracked   * by a std::weak_ptr pointing to the object of type T. The purpose is to   * disconnect this slot automatically upon said object destruction.   * @param function the signal connects to   * @param objectPtr pointer to the object to be tracked   * @tparam T the type of the object to track   * @return a Connection instance for managment purposes   * @post slots_.size() incremented by one   */  template <typename T>  Connection connect(std::weak_ptr<T> &&objectPtr,                     std::function<R(Args...)> &&function) noexcept {    IDType id = slots_.size();    std::shared_ptr<ISlot<Args...>> slot =        std::make_shared<TrackingSlot<T, Args...>>(            id, std::forward<std::weak_ptr<T>>(objectPtr),            std::forward<std::function<R(Args...)>>(function), *this);    slots_.push_back(slot);    return Connection(std::weak_ptr(slots_[id]));  }  /**   * @brief Connects and tracks a slot to the signal   * Convenience method to connect a member function.   * Connects a function pointer to the signal.   * The slot is tracked by a std::weak_ptr pointing to the object of type T.   * The purpose is to disconnect this slot automatically upon said object   * destruction.   * @param function pointer the signal connects to   * @param objectPtr pointer to the object to be tracked   * @tparam T the type of the object to track   * @return a Connection instance for managment purposes   * @post slots_.size() incremented by one   */  template <typename T>  Connection connect(std::shared_ptr<T> &objectPtr,                     R (T::*function)(Args...)) noexcept {    T *const ptr = objectPtr.get();    return connect(std::weak_ptr<T>(objectPtr),                   [ptr, function](Args... args) -> R {                     return (ptr->*function)(args...);                   });  }  /**   * @brief Connects and tracks a slot to the signal   * Convenience method to connect a const member function.   * Connects a function pointer to the signal.   * The slot is tracked by a std::weak_ptr pointing to the object of type T.   * The purpose is to disconnect this slot automatically upon said object   * destruction.   * @param function pointer the signal connects to   * @param objectPtr pointer to the object to be tracked   * @tparam T the type of the object to track   * @return a Connection instance for managment purposes   * @post slots_.size() incremented by one   */  template <typename T>  Connection connect(std::shared_ptr<T> &objectPtr,                     R (T::*function)(Args...) const) noexcept {    T *const ptr = objectPtr.get();    return connect(std::weak_ptr<T>(objectPtr),                   [ptr, function](Args... args) -> R {                     return (ptr->*function)(args...);                   });  }  /**   * @brief Disconnects all the slots   * Disconnects all the slots this signal is connected to.   * @post slots_.empty() == true   */  void disconnectAll() noexcept { slots_.clear(); }  /**   * @brief Emits the signal   * All non blocked and connected slot functions will be called   * with supplied arguments.   * Important explanation!   * A template is used here, this is for flexibility and design purposes.   * To this function can be passed rvalues or lvalues but if we use the Args   * type it is basically precluding us to emit the signal when it is a   * different types from Args. Suppose Signal<bool, int, double&> the matched   * function is std::function<bool(int, double&)>. Now i can't emit something   * like emit(5, 5.0) because 5.0 is a non const lvalue.   * @see ISlot::operator()()   * @param params arguments to emit   * @tparam ...Params type of the parameter to emit   */  template <typename... Params>  void emit(Params... params) {    for (auto const &it : slots_) {      it->operator()(params...);    }  }  /**   * @brief Gets the number of connected slots   * @return slots.size()   */  std::size_t connectedSlots() const noexcept { return slots_.size(); }};}  // namespace sigslotpp#endif  // LIBSIGSLOTPP_INCLUDE_LIBSIGSLOTPP_SIGNAL_HPP_

Utilizzo

Per comprendere come utilizzare la soluzione implementata vi mostro gli unit tests che ho scritto.

const std::string ff = "free function";const std::string mf = "member function";const std::string smf = "static member function";const std::string mo = "member operator";const std::string l = "lambda";const std::string gl = "generic lambda";void f() { fmt::print("{}\n", ff); }struct s {  void m() { fmt::print("{}\n", mf); }  static void sm() { fmt::print("{}\n", smf); }};struct o {  void operator()() { fmt::print("{}\n, mo"); }};TEST_CASE("slots can be added and removed from the signal") {  std::shared_ptr<s> d;  auto lambda = []() { fmt::print("{}\n", l); };  auto gen_lambda = [](auto &&...a) { fmt::print("{}\n", gl); };  sigslotpp::Signal<void> sig;  SUBCASE("connecting slots to signal increases connected slots") {    auto c1 = sig.connect(f);    sig.connect(d, &s::m);    sig.connect(&s::sm);    auto c2 = sig.connect(o());    sig.connect(lambda);    sig.connect(gen_lambda);    CHECK(sig.connectedSlots() == 6);  }  SUBCASE("discconnecting all slots from the signal put size to zero") {    auto c1 = sig.connect(f);    auto c2 = sig.connect(o());    sig.connect(lambda);    sig.connect(gen_lambda);    sig.disconnectAll();    CHECK(sig.connectedSlots() == 0);  }  SUBCASE("disconnecting slots from signal decreases connected slots") {    auto c1 = sig.connect(f);    auto c2 = sig.connect(o());    c1.disconnect();    CHECK(sig.connectedSlots() == 1);  }}TEST_CASE("signal can be emitted") {  int x{0};  auto lambda = [&x](int value) { x = x + value; };  sigslotpp::Signal<void, int> sig;  sig.connect(lambda);  sig.emit(5);  CHECK(x == 5);  sig.emit(1);  CHECK(x == 6);  sig.emit(-6);  CHECK(x == 0);}int sum = 0;struct x {  void f(int i) { sum += i; }};TEST_CASE("signal can be automatically disconnected") {  auto a = std::make_shared<x>();  sigslotpp::Signal<void, int> sig;  sig.connect(a, &x::f);  sig.emit(4);  sig.emit(3);  sig.emit(-2);  CHECK(sum == 5);  a.reset();  sig.emit(9);  CHECK(sum == 5);  CHECK(sig.connectedSlots() == 0);}TEST_CASE("signal connection to slot can be blocked") {  int x{0};  auto lambda = [&x](int value) { x = x + value; };  sigslotpp::Signal<void, int> sig;  auto c1 = sig.connect(lambda);  sig.emit(5);  CHECK(x == 5);  c1.block();  sig.emit(1);  CHECK(x == 5);  c1.unblock();  sig.emit(-6);  CHECK(x == -1);}

Analisi

Le classi coinvolte sono:

• ISlotConnection
• ISlot
• SimpleSlot
• TrackingSlot
• ISignal
• Signal
• Connection

Non serve analizzare ogni classe riga per riga; due elementi, però, meritano una spiegazione più attenta: TrackingSlot e Connection.

Classe TrackingSlot

Questa classe permette, tramite un std::weak_ptr, di tracciare l'esistenza in memoria di un oggetto specifico. Per questo la soluzione presuppone l'uso degli smart pointer, in particolare di un std::shared_ptr per creare l'oggetto da tracciare.

Quando il weak_ptr non riesce più a eseguire il lock, significa che l'oggetto tracciato ha terminato il suo ciclo di vita.

Lo slot non viene rimosso immediatamente quando l'oggetto termina il suo ciclo di vita, ma al successivo emit del signal a cui è connesso.

Va chiarito che questa classe non modifica il ciclo di vita dell'oggetto tracciato.

Classe Connection

Questa classe non segue il pattern RAII. Serve come punto di accesso esplicito alla connessione tra signal e slot. Connection mantiene un riferimento, un weak_ptr, allo slot creato in seguito a una chiamata signal.connect(...).

La classe può operare sulle seguenti funzioni dello slot:

• Disconnessione
• Blocco/sblocco della ricezione di un'emissione di signal
• Verifica dello stato dello slot

Va chiarito che il ciclo di vita di questa classe non modifica il ciclo di vita dello slot.

Problemi aperti

Vi sono nell'immediato alcune lacune dal punto di vista funzionale, poiché:

1. Non è thread safe.
2. Non posso disconnettermi direttamente dallo slot (immaginiamo un segnale che deve essere emesso una sola volta).
3. Overloading dei metodi.
4. Metodi con valori default.
5. Non c'è modo di recuperare il valore di ritorno degli slot.

Il punto 1 non viene affrontato qui, data la complessità della gestione thread-safe.

Sul punto 4 non ho ancora trovato una soluzione soddisfacente.

Il problema 5 nasce solo per motivi progettuali, ho preferito non implementarlo perché superfluo per lo scopo della classe Signal. Nella mia implementazione è possibile connettersi a slot con valore di ritorno, che vengono poi trasformati in slot con ritorno void. Per implementare il valore di ritorno servirebbe un vettore di appoggio in cui salvare il ritorno di ogni slot e mettere a disposizione dei metodi per leggerlo. Ogni emit sovrascriverebbe quel vettore.

Problema: disconnessione diretta dallo slot

La classe Connection risolve questo problema in modo diretto. Basta aggiungere una classe ExtendedSlot che abbia come membro una variabile di tipo Connection, così da poterla iniettare all'interno della funzione invoke. Tuttavia c'è un compromesso, ovvero dovremmo disporre di funzioni che abbiano come parametro un tipo Connection.

Vediamo una possibile soluzione.

Aggiungiamo una classe ExtendedSlot.

template <typename... Args>class ExtendedSlot final : public ISlot<Args...> { private:  std::function<void(Args...)>      function_;  ///< function to be invoked by this slotConnection connection_ ///< connection handle injected into the slot protected:  void invoke(Args... args) override final {    function_(connection_, std::forward<Args>(args)...);  } public:  ExtendedSlot(const IDType id, std::function<void(Args...)> &&function,             ISignal &signal) noexcept      : ISlot<Args...>(id, signal),        function_(std::forward<std::function<void(Args...)>>(function)) {}  // Not ideal, but enough for this implementation.  void setConnection(Connection connection) { connection_ = connection }};

Modifichiamo Signal e aggiungiamo un metodo connectExtended.

 Connection connectExtended(std::function<R(Args...)> &&function) noexcept {  IDType id = slots_.size();  std::shared_ptr<ISlot<Args...>> slot =      std::make_shared<ExtendedSlot<Args...>>(          id, std::forward<std::function<R(Args...)>>(function), *this);  slots_.push_back(slot);  auto c = Connection(std::weak_ptr(slots_[id]));  slots_[id]->setConnection(c);  return c;}

E per utilizzarlo avremo.

int main() {  int i = 0;  sigslot::signal<void> sig;  auto f = [](auto &con) {    i += 1;    con.disconnect();  };  sig.connectExtended(f);}

Rimane il limite di dover aggiungere sempre quel parametro di tipo Connection a ogni slot, per di più come primo argomento.

Problema: overloading

Aggiungendo le seguenti funzioni di supporto possiamo risolvere anche questo caso.

template <typename T, typename R, typename... Args>constexpr auto overload(R(I::*ptr)(Args...)) {    return ptr;}template <typename R, typename... Args>constexpr auto overload(R(*ptr)(Args...)) {    return ptr;}

Il parameter pack, una volta espanso, permette di identificare il metodo corretto in modo univoco:

struct obj {  void operator()(int) const {}  void operator()() {}};struct foo {  void bar(int) {}  void bar() {}  static void baz(int) {}  static void baz() {}};void moo(int) {}void moo() {}int main() {  sigslot::signal<void, int> sig;  foo ff;  sig.connect(overload<int>(&foo::bar), &ff);  sig.connect(overload<int>(&foo::baz));  sig.connect(overload<int>(&moo));  sig.connect(obj());  sig(0);  return 0;}

Conclusione

Abbiamo visto come implementare un meccanismo di signal/slot. La soluzione ha limiti evidenti, ma offre un'interfaccia d'uso semplice e senza meccanismi nascosti.

Con questa base possiamo implementare l'observer pattern in modo chiaro e controllabile.

A questo link trovate la cartella di progetto che potrete compilare con CMake.

Prima o poi ogni progetto C++ deve fare i conti con CMake, dipendenze, librerie interne e applicazioni costruite sopra quelle librerie. Nei miei primi progetti perdevo spesso troppo tempo a organizzare le directory e a mantenere coerenti i vari CMakeLists.txt. Quando la struttura non è chiara, basta aggiungere un modulo o una dipendenza per rendere la build più fragile del necessario.

Dopo aver studiato le pratiche di altri sviluppatori, ho trovato una struttura che mi piace per semplicità e chiarezza.

Quella che segue non è l'unica soluzione possibile. È una struttura pensata per:

• Evitare schemi che causano conflitti.
• Evitare di complicare la compilazione.
• Semplificare la lettura.

Strumenti usati

Per l'esempio userò tre strumenti:

CMake

CMake è un software libero multipiattaforma per l'automazione dello sviluppo il cui nome è un'abbreviazione di cross platform make. Questo software nasce per rimpiazzare Automake nella generazione dei Makefile, cercando di essere più semplice da usare. Infatti, nella maggior parte dei progetti, non esiste un Makefile incluso nei sorgenti, dato che questo non è portabile.

-- Wikipedia

Lo useremo per generare la build e compilare il progetto.

Non sarà una guida completa a CMake: qui mi interessa soprattutto mostrare come organizzare il progetto. Per approfondire, il riferimento migliore resta il sito ufficiale di CMake.

Conan

Conan is a dependency and package manager for C and C++ languages. It is free and open-source, works in all platforms ( Windows, Linux, OSX, FreeBSD, Solaris, etc.), and can be used to develop for all targets including embedded, mobile (iOS, Android), and bare metal. It also integrates with all build systems like CMake, Visual Studio (MSBuild), Makefiles, SCons, etc., including proprietary ones.

-- Conan

Lo useremo per gestire dipendenze e pacchetti.

Per approfondire, la documentazione parte dal sito ufficiale di Conan.

Prima di procedere, vediamo i passaggi minimi per usarlo nel progetto.

Si inizia generando un profilo Conan, che descrive compilatore, configurazione di build, architettura e altre impostazioni dell'ambiente.

conan profile detect --force

Al termine, sui sistemi Unix, nella home directory sarà presente la cartella .conan2 con il profilo generato.

Per installare le dipendenze usiamo il comando seguente.

conan install . --output-folder=build --build=missing

Conan esegue due operazioni principali:

• Installa le librerie specificate nel conanfile.txt dal server remoto, in genere Conan Center, se disponibili. Il server contiene sia le recipe Conan, che descrivono come costruire le librerie, sia i pacchetti binari riutilizzabili.
• Genera diversi file nella directory build.
  • CMakeDeps genera i file necessari per far sì che CMake trovi le librerie che abbiamo scaricato.
  • CMakeToolchain genera un file toolchain per CMake per poter costruire il nostro progetto con CMake.

Doxygen

Doxygen è una applicazione per la generazione automatica della documentazione a partire dal codice sorgente di un generico software. È un progetto open source disponibile sotto licenza GPL, scritto per la maggior parte da Dimitri van Heesch a partire dal 1997.

-- Wikipedia

Doxygen genera la documentazione a partire dai commenti presenti nel codice.

Anche qui non serve una guida completa: per i dettagli rimando al sito ufficiale di Doxygen.

Struttura

La struttura del progetto ha la seguente forma.

.├── CMakeLists.txt├── conanfile.txt├── conan_provider.cmake├── libfoo│   ├── CMakeLists.txt│   ├── docs│   │   └── CMakeLists.txt│   ├── include│   │   └── libfoo│   │       └── foo.hpp│   ├── src│   │   └── foo.cpp│   └── tests│       ├── foo.test.cpp│       └── main.cpp└── standalone    ├── CMakeLists.txt    └── main.cpp

Vediamola più da vicino.

L'idea di fondo è separare i componenti del progetto per directory. Ogni cartella contiene un eseguibile o una libreria e definisce il relativo target.

standalone è il target eseguibile e usa la libreria libfoo. Rappresenta un'applicazione costruita sopra una o più librerie principali.

libfoo è una libreria statica usata da standalone, ma è organizzata come un componente autonomo, con interfaccia pubblica, implementazione, test e documentazione. Ogni libreria dovrà:

• Seguire una struttura prevedibile.
  • Directory include per le dichiarazioni pubbliche, cioè l'interfaccia della libreria.
  • Directory src per le definizioni e gli header privati.
• Garantire la generazione della documentazione con Doxygen.
• Fornire un ambiente di testing con doctest (o similari).

L'immagine seguente mostra l'idea generale: gli eseguibili app usano librerie core, ma ogni componente rimane separato.

TopLevel CMakeLists.txt

Il file CMakeLists.txt nella root contiene la configurazione principale del progetto.

cmake_minimum_required(VERSION 3.27)### Projectproject(cpp_project_structure VERSION 1.0 LANGUAGES CXX)set(CMAKE_CXX_STANDARD 17)set(CMAKE_EXPORT_COMPILE_COMMANDS ON)### Packagesfind_package(fmt REQUIRED)find_package(doctest REQUIRED)find_package(Doxygen REQUIRED)### Subdirectories (the order is important)add_subdirectory(libfoo)add_subdirectory(standalone)

Abbiamo un solo progetto e specifichiamo a CMake di ricercare altri file di configurazione nelle sottocartelle libfoo e standalone, rispettivamente "core" e "app". Impostiamo quindi le opzioni comuni e usiamo find_package per individuare le dipendenze necessarie alla compilazione.

Gestione dipendenze

Il file conanfile.txt specifica i pacchetti che serviranno ai vari target del nostro progetto. Nel nostro caso fmt viene usato sia da libfoo che da standalone, doctest viene richiesto da libfoo per gli unit tests. Il contenuto di seguito.

[requires]fmt/10.2.1doctest/2.4.11[layout]cmake_layout

Per usare Conan con CMake, utilizziamo il wrapper cmake-conan, in particolare siamo interessati al file conan_provider.cmake che salviamo nella root del progetto. Questo file ci tornerà utile in seguito.

Target libfoo

Il target libfoo che nel caso in analisi si presenta come una libreria statica, segue la forma canonica di una libreria standard. Tornando al concetto di un target per subdirectory, il nostro CMakeLists.txt diventa questo.

### Library libfooadd_library(libfoo STATIC src/foo.cpp        include/libfoo/foo.hpp)add_library(libfoo::libfoo ALIAS libfoo)set_target_properties(libfoo PROPERTIES VERSION 0.0)target_include_directories(libfoo PUBLIC include PRIVATE src)target_link_libraries(libfoo PRIVATE fmt::fmt)target_compile_options(libfoo PRIVATE -Wall -Wextra -pedantic -Werror)target_compile_features(libfoo PRIVATE cxx_std_17)### Testing libfooadd_executable(libfoo_tests tests/main.cpp)target_link_libraries(libfoo_tests PRIVATE doctest::doctest)target_compile_options(libfoo_tests PRIVATE -Wall -Wextra -pedantic -Werror)target_compile_features(libfoo_tests PRIVATE cxx_std_17)### Subdirectoriesadd_subdirectory(docs)

Abbiamo tre sezioni:

• Definizione della libreria e della sua configurazione.
• Impostazione e creazione del target per gli unit tests.
• Abilitazione e configurazione di Doxygen per la generazione della documentazione.

Per completezza, questo è il contenuto del CMakeLists.txt nella cartella docs.

set(DOXYGEN_ALPHABETICAL_INDEX NO)set(DOXYGEN_BUILTIN_STL_SUPPORT YES)set(DOXYGEN_CASE_SENSE_NAMES NO)set(DOXYGEN_CLASS_DIAGRAMS NO)set(DOXYGEN_DISTRIBUTE_GROUP_DOC YES)# set(DOXYGEN_EXAMPLE_PATH "")set(DOXYGEN_EXCLUDE bin)set(DOXYGEN_EXTRACT_ALL YES)set(DOXYGEN_EXTRACT_LOCAL_CLASSES NO)set(DOXYGEN_FILE_PATTERNS *.hpp)set(DOXYGEN_GENERATE_TREEVIEW YES)set(DOXYGEN_HIDE_FRIEND_COMPOUNDS YES)set(DOXYGEN_HIDE_IN_BODY_DOCS YES)set(DOXYGEN_HIDE_UNDOC_CLASSES YES)set(DOXYGEN_HIDE_UNDOC_MEMBERS YES)set(DOXYGEN_JAVADOC_AUTOBRIEF YES)set(DOXYGEN_QT_AUTOBRIEF YES)set(DOXYGEN_QUIET YES)set(DOXYGEN_RECURSIVE YES)set(DOXYGEN_REFERENCED_BY_RELATION YES)set(DOXYGEN_REFERENCES_RELATION YES)set(DOXYGEN_SORT_BY_SCOPE_NAME YES)set(DOXYGEN_SORT_MEMBER_DOCS NO)set(DOXYGEN_SOURCE_BROWSER YES)set(DOXYGEN_STRIP_CODE_COMMENTS NO)doxygen_add_docs(        libfoo_docs        "../include/"        ALL        COMMENT "Generate HTML documentation for libfoo")

Target standalone

La configurazione del target standalone è più semplice:

add_executable(standalone main.cpp)target_link_libraries(standalone PRIVATE fmt::fmt libfoo::libfoo)target_compile_options(standalone PRIVATE -Wall -Wextra -pedantic -Werror)target_compile_features(standalone PRIVATE cxx_std_17)

Compilazione

cmake -B build -S . -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=conan_provider.cmake -DCMAKE_BUILD_TYPE=Debugcmake --build build --config Debug

Con il primo comando eseguiamo la fase di configurazione out-of-tree, generando un sistema di compilazione. Con il secondo costruiamo il progetto chiamando lo strumento di compilazione di sistema, make su Unix.

Ricordate il file conan_provider.cmake enunciato in precedenza? Ebbene utilizzando l'impostazione -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=conan_provider.cmake nel processo di configurazione di cmake, questo invoca automaticamente il comando conan install semplificandoci la gestione del progetto.

Conclusione

Ora nella cartella build, sotto la root del progetto, troveremo i file binari e le librerie che abbiamo compilato, oltre alla documentazione doxygen e all'eseguibile degli unit tests.

La struttura può essere estesa aggiungendo, per esempio, una pipeline di integrazione continua, altri eseguibili o nuove librerie.

Il repository di esempio contiene il progetto completo descritto nell'articolo.

Per molto tempo mi sono chiesto se avessi davvero qualcosa di utile da scrivere. Alla fine sono arrivato a una conclusione semplice: senza iniziare non avrei mai potuto scoprirlo.

Questo è quindi il mio primo articolo pubblico.

Non contiene ancora un approfondimento tecnico, ma segna l'inizio di uno spazio in cui raccogliere ciò che imparo, i progetti su cui lavoro e le idee che meritano di essere sviluppate con più calma.

Scriverò soprattutto di informatica, sviluppo software e tecnologia, lasciando spazio anche ad appunti personali e ad altri argomenti che trovo interessanti.

Grazie per essere passati. Buona lettura.

Nicolò