Il peggior linguaggio di programmazione di tutti i tempi /s

Su YouTube c'è un video di cinquanta minuti dal titolo orgoglioso «il peggior linguaggio di programmazione di tutti i tempi». Non mi stupirei se tu avessi dato per scontato che parlasse di C++. Parla davvero di C++, e l'ho visto circa mezzo anno fa, beh, «visto» è una parola grossa... l'ho scorso a 2x saltando parecchio, qualunque cosa un junior offeso possa aver blaterato lì dentro, ma il buon @alyokhinme l'ha ricordato di nuovo, e ora l'ho guardato per intero. E sai qual è la parte più spiacevole? Se togli l'intonazione da junior offeso e lasci solo gli argomenti, allora circa il settanta percento è vero. Non «discutibile», non «dipende dal contesto», ma letteralmente vero, del tipo che qualsiasi sviluppatore che abbia passato un paio d'anni con il linguaggio confermerà senza pensarci due volte.

Il paradosso è che questo video è stato fatto sul linguaggio in cui è scritta metà del mondo che ci circonda. Il browser in cui stai leggendo questo, il game engine, come potrei scrivere un articolo senza i giochi, del gioco a cui hai giocato ieri, il firmware dell'hardware su cui gira tutto, e il compilatore che ha costruito il browser, l'engine e il firmware.

Il genere «perché il C++ fa schifo» è stato bruciato fino alle fondamenta su Habr, e sullo zoo dell'Init, lo static sovraccarico, il vector chiamato in modo sbagliato, lo std::move che non sposta, la regex super lenta, la unordered_map lenta hai letto tutto una dozzina di volte. La lista stessa di questi dolori è roba vecchia, e aggiungo a titolo personale che tutte le lamentele e gli esempi qui sotto sono conseguenze di una singola decisione, e ci arriverò. Oppure apri gli spoiler, nascondono la storia del perché ogni parte del linguaggio è venuta fuori così com'è.

Molti modi di inizializzare una variabile

Cominciamo dalla parte più infernale, dall'inizio di qualsiasi programma, cioè dalla creazione di una variabile. E mentre negli altri linguaggi questa è di solito una singola operazione, in C++ ci si scrivono interi libri e ci si conducono studi, poi trascinati alle conferenze, come se non ci fossero già abbastanza altri problemi. Aiutami. Ho dimenticato qualcosa?

int f;                    // memoria automatica, spazzatura
static int f_static;      // ma in scope namespace/static è già zero (zero-init all'avvio)
std::string s;            // chiamata del costruttore di default
int* p = new int;         // heap, spazzatura
int e{};                  // 0
int e2 = {};              // 0
int* p = new int{};       // 0
int* q = new int();       // anche 0
auto t = T{};             // temporaneo, value-init
int b(5);
std::string s("hello");
T obj(a1, a2);
auto p = new T(a1, a2);
int x = static_cast<int>(3.5);   // cast, anche questo è direct-init
int y(int(5));                   // notazione funzionale
int a = 5;
std::string s = "hello";
T obj = other;
f(arg);                   // passaggio per valore, viene inizializzato il PARAMETRO della funzione
                          // non una variabile visibile
f({1, 2, 3});             // stessa cosa
return x;                 // ritorno per valore
return {1, 2, 3};         // anche, se la copy-elision non entra in gioco
throw x;                  // viene inizializzato l'oggetto eccezione
int c{5};                 // direct-list
int d = {5};              // copy-list
std::vector<int> v{1, 2, 3};
std::vector<int> v2 = {1, 2, 3};
std::vector<int> a(10);   // 10 elementi, tutti zeri
std::vector<int> b{10};   // UN elemento con valore 10
struct Point { int x, y; };
Point p{1, 2};            // puoi fare così
Point p2 = {1, 2};        // oppure puoi fare così
int arr[3] = {1, 2, 3};   // con gli zeri e senza
int arr2[3] = {};         // tutti zeri
Point p3{.x = 1, .y = 2}; // designated initializers, C++20
Point p4{1};              // x=1, y=0 (value-init della coda)
int& r = x;
const int& cr = 5;        // binding a un temporaneo + lifetime extension
int&& rr = 10;
constexpr int n = 42;     // deve essere constant-init
const int m = foo();      // può essere sia costante che dinamica
constinit int g = bar();  // C++20: garantisce static-init, ma NON la rende const
static int s = compute(); // dynamic-init, con il suo Static Init Order Fiasco
struct S {
    int x = 5;            // default member initializer
    int y{10};
    S() : y{2}, x(1) {}   // member initializer list (ordine per dichiarazione, non per lista)
};
auto [a, b] = std::pair{1, 2};   // structured bindings, C++17
for (int v : arr) { }            // anche il range-based for inizializza v

Se conti le «semantiche comportamentali» dell'inizializzazione, ne vengono fuori circa dieci (= v, (v), {v}, = {v}, {}, = {}, () nel new, ecc.), e ci saranno nove categorie semantiche, e la corrispondenza tra loro non è uno-a-uno, e una singola voce {} vive contemporaneamente in value-init, list-init e aggregate-init a seconda del tipo a destra. Sul tema dell'inizializzazione è stato scritto un libro a parte di trecento pagine, e non è uno scherzo, una volta un conoscente me l'ha consigliato, esiste davvero ed è davvero lungo trecento pagine, come si dice, buon divertimento.

E ogni metodo fa qualcosa di leggermente diverso, mi piace particolarmente la differenza tra e e f, dove la presenza o l'assenza di una coppia di parentesi graffe determina se la tua variabile contiene zero oppure qualsiasi cosa sia rimasta in questo pezzo di stack dalla chiamata di funzione precedente.

struct S {
    int x = 5;     // default member initializer
    int y{10};
};

NSDMI, Non-Static Data Member Initializer, un inizializzatore per un membro dati non statico proprio nella dichiarazione della classe. Nel punto int x = 5; l'oggetto non esiste ancora e nulla viene inizializzato. Questo è un default member initializer, cioè solo un modello che verrà usato durante la costruzione, SE il costruttore non ha inizializzato lui stesso il membro nella mem-init-list, cioè è un «inizializzatore di riserva», non un'inizializzazione. Formalmente è il brace-or-equal-initializer del membro.

auto [a, b] = std::pair{1, 2};

E qui viene inizializzato un oggetto anonimo nascosto (un hidden object o decomposition object , chiamiamolo e), e a e b non saranno variabili separate, sono binding names a parti dell'oggetto anonimo. L'inizializzazione è applicata a e, non ad a/b. Una sottigliezza, ma dato che stiamo cavillando, ripeto che queste non sono proprio vere variabili ma campi di una struttura, e e stesso non è accessibile direttamente, ma fisicamente lo storage è più o meno così:

e
+---------+
| first   | <--- a
| second  | <--- b
+---------+

auto e = std::pair{1, 2};
auto& a = e.first;
auto& b = e.second;

int k, e;

int main() {
    auto [a, b] = std::pair{k, e};

    return a + b;
}

leaq    -12(%rbp), %rdi
leaq    k(%rip), %rsi
leaq    e(%rip), %rdx
callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&)

main:
        pushq   %rbp
        movq    %rsp, %rbp
        subq    $32, %rsp
        movl    $0, -4(%rbp)
        leaq    -12(%rbp), %rdi  <<<<<
        leaq    k(%rip), %rsi    <<<<<
        leaq    e(%rip), %rdx    <<<<<
        callq   std::pair<int, int>::pair<int&, int&, true>(int&, int&) <<<<<
        leaq    -12(%rbp), %rdi
        callq   tuple_element<0ul, std::pair<int, int>>::type&& std::get<0ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -24(%rbp)
        leaq    -12(%rbp), %rdi
        callq   tuple_element<1ul, std::pair<int, int>>::type&& std::get<1ul, int, int>(std::pair<int, int>&&)
        movq    %rax, -32(%rbp)
        movq    -24(%rbp), %rax
        movl    (%rax), %eax
        movq    -32(%rbp), %rcx
        addl    (%rcx), %eax
        addq    $32, %rsp
        popq    %rbp
        retq

k:
        .long   0

e:
        .long   0

E proprio quando decidi di averlo capito, salta fuori che le parentesi graffe in un contesto sono inizializzazione di aggregato, e in un altro sono std::initializer_list, e la stessissima riga di codice può restituire un tipo diverso a seconda della versione dello standard con cui compili. Non un risultato diverso, ma un tipo diverso. Benvenuto.

auto i = 1;      // sempre int
auto j = {1};    // sempre initializer_list<int> (copy-list-init)
auto k{1};       // C++11: initializer_list<int>;  C++17+: int

Le cose semplici non vengono fatte semplicemente

L'esempio da manuale di semplicità complicata è un numero casuale, e da qualche parte in Java o Python scrivi semplicemente random.randint(1, 100) e continui a programmare, ma non qui. È troppo semplice per essere vero.

std::random_device rd;
std::mt19937 gen(rd());                          // e cos'è mt19937?
std::uniform_int_distribution<int> dist(1, 100); // e perché separatamente?
int value = dist(gen);                           // finalmente

Il codice non è proprio illeggibile, ma devi cercarlo su cppreference una volta su due che ti serve davvero. Poi vado a googlare cosa sia questo mt19937, è il Mersenne Twister, ora vivi con questa conoscenza, e sì, ora devi conoscere il nome del generatore di numeri pseudo-casuali solo per lanciare un dado.

Problemi di casting

Il casting è tutta una canzone a parte, e dove in Java scrivi il valore tra parentesi e basta, in C++ c'è un intero set di questi cast, per tutti i gusti e colori. static_cast, dynamic_cast, reinterpret_cast, const_cast, bit_cast, e ognuno per il suo caso, e ognuno va digitato per intero a mano, e c'è anche un nascosto rvalue_cast, ma di questo più avanti.

double d = 3.9;
int i = static_cast<int>(d);        // 3, parte frazionaria scartata

Base* b = new Derived;
auto* der = static_cast<Derived*>(b); // downcast SENZA controllo
                                      // garantisci tu che sia un Derived

Base* b = get_something();
if (Derived* d = dynamic_cast<Derived*>(b)) {
    d->derived_only();              // arriviamo qui solo se è davvero un Derived
}                                   // altrimenti d == nullptr

int x = 42;
std::uintptr_t addr = reinterpret_cast<std::uintptr_t>(&x);  // indirizzo come numero

void legacy_api(char* s);           // non tocca la stringa, ma ha dimenticato const

const std::string str = "hello";
legacy_api(const_cast<char*>(str.c_str()));   // ok, dato che l'api davvero non modifica

float f = 1.0f;
auto bits = std::bit_cast<std::uint32_t>(f);  // 0x3F800000, niente UB

// come si faceva prima del C++20:
std::uint32_t old;
std::memcpy(&old, &f, sizeof f);              // stessa cosa, ma a mano

int i = (int)d;                     // compila, sembra familiare

I nuovi arrivati si stancano così tanto di questo che si impostano un breve alias per sé, e questo è considerato bad practice, perché ora il tuo codice è scritto in un tuo dialetto personale di C++ che nessuno conosce tranne te.

// antipattern: "sono stanco di scrivere static_cast"
template <class T, class U>
constexpr T sc(U&& u) { return static_cast<T>(std::forward<U>(u)); }

int i = sc<int>(3.9);               // corto, sì, corretto? no

// oppure ancora peggio:
#define CAST(T, x) static_cast<T>(x)

Questa è una vera trappola, e spesso il C++ corretto sembra scorretto, perché la soluzione corta e bella quasi sempre si rivela buggata e scorretta, mentre quella corretta sembra che tu abbia complicato inutilmente la vita al tuo team. L'intuizione per «come dovrebbe apparire il buon codice» richiede anni per svilupparsi, e finché non si sviluppa, vivi con la sensazione di stare facendo qualcosa di sbagliato. Spoiler: stai davvero facendo qualcosa di sbagliato, è il linguaggio che è fatto così.

Parole chiave che mentono

In un mondo normale una parola chiave descrive ciò che fa, ma in C++ questo è diventato un accessorio opzionale. Ricorda static.

E ricordi quanti significati ha? Fare una variabile che vive tra le chiamate di funzione, questo è uno. Fare una variabile o un metodo condivisi tra tutte le istanze di una classe, questo è due. Il terzo significato, quando static prima di una funzione in un file .cpp la rende invisibile fuori da quel file, cioè è private, ma l'hanno chiamato static. Perché non internal, non private, non file_local? Perché storicamente è semplicemente andata così, che è la risposta a circa metà delle domande di questo articolo.

void counter() {
    static int calls = 0;   // inizializzata UNA VOLTA, al primo ingresso
    int local = 0;          // locale ordinaria, di nuovo a ogni chiamata
    ++calls;
    ++local;
    std::cout << "static: " << calls << ", local: " << local << '\n';
}

E c'è un comportamento di static arrivato dopo il C++11, ora il tuo staticsignifica anche un light mutex guarded. Lo sapevi di questo?

Logger& logger() {
    static Logger instance;   // una riga
    return instance;
}

Logger& logger() {
    // percorso FAST: byte basso del guard != 0 → già inizializzato
    if ((reinterpret_cast<volatile char&>(__guard_for_instance)) == 0) {

        // percorso SLOW: arriviamo qui solo la prima volta e sotto sincronizzazione
        if (__cxa_guard_acquire(&__guard_for_instance)) {
            // acquire ha restituito 1 → proprio questo thread è obbligato a inizializzare.
            // Gli altri thread ora DORMONO dentro __cxa_guard_acquire.
            try {
                ::new (&__instance_storage) Logger();          // chiamata del costruttore
                __cxa_guard_release(&__guard_for_instance);    // imposta il flag, sveglia i dormienti
                __cxa_atexit(&destroy_logger, ...);            // registra la distruzione
            } catch (...) {
                __cxa_guard_abort(&__guard_for_instance);
                throw;
            }
        }
        // i thread che hanno perso la gara sono usciti da acquire solo dopo release
    }
    return reinterpret_cast<Logger&>(__instance_storage);
}

inline un tempo chiedeva al compilatore di fare l'inlining di una funzione, ma oggi il compilatore è furbo e fa l'inlining da solo quando lo ritiene opportuno, e inline ora risolve problemi di linking e la One Definition Rule. E inline su una funzione e inline su una variabile fanno semanticamente cose opposte, e su una funzione è il permesso di duplicare codice, mentre su una variabile è un divieto di duplicare dati.

// math.h
inline int square(int x) { return x * x; }

// a.cpp
#include "math.h"
int use_a() { return square(3); }

// b.cpp
#include "math.h"
int use_b() { return square(4); }

// counter.h
inline int g_calls = 0;   // esattamente un'istanza per tutto il programma

// a.cpp
#include "counter.h"
void hit_a() { ++g_calls; }

// b.cpp
#include "counter.h"
void hit_b() { ++g_calls; }

// config.h
struct Config {
    static inline int instances = 0;          // un contatore per tutti gli oggetti, proprio nell'.h
};

inline constexpr double kPi = 3.14159265358979;  // costante header-only, un oggetto

const, che dovrebbe riguardare l'immutabilità, può essere scritto su entrambi i lati del tipo, ed entrambe le grafie significano esattamente la stessa cosa, giusto perché tu non ti rilassi. E anche mutable const è a volte codice valido. E anche la constness può essere tolta con un cast, e questa è bad practice, ma fisicamente si può fare.

Per capire a cosa si riferisce const in una dichiarazione di puntatore, al valore o al puntatore stesso, c'è una regola ufficiale «leggi da destra a sinistra». Ti ricordo che la maggior parte delle persone legge da sinistra a destra.

const int a = 5;   // "west const"
int const b = 5;   // "east const" esattamente la stessa cosa, entrambe sono costanti

const int* p = &a; // puntatore a const int
int const* q = &a; // e questo è la stessa cosa

struct Cache {
    mutable int hits = 0;   // può essere cambiato anche su un oggetto const
    int value = 0;
};

const Cache c;
c.hits++;       // OK, mutable
// c.value++;   // errore, un membro ordinario di un oggetto const

struct S {
    mutable const int* p = nullptr;  // VALIDO
};

struct Bad {
    mutable const int x = 5;  // NON VALIDO, mutable non può stare su un membro const
};

// Caso 1: l'oggetto è DAVVERO non const, ok
int x = 5;
const int& cref = x;
const_cast<int&>(cref) = 10;   // legale, x è davvero cambiato, x == 10

// Caso 2: l'oggetto è DAVVERO const, Undefined Behavior
const int y = 5;
const_cast<int&>(y) = 10;      // compila, ma questo è UB
                               // y può restare 5, crashare, o qualsiasi cosa

int x = 0, y = 0;

const int* p1 = &x;        // p1: puntatore a const int
int* const p2 = &x;        // p2: puntatore const a int
const int* const p3 = &x;  // p3: puntatore const a const int

*p1 = 5;   // errore: il valore è const
p1 = &y;   // ok: il puntatore può essere reindirizzato

*p2 = 5;   // ok: il valore può essere cambiato
p2 = &y;   // errore: il puntatore è const

*p3 = 5;   // errore
p3 = &y;   // errore

const int* p;   // puntatore a const int, cambia il puntatore, non il valore
int* const p;   // puntatore const a int, cambia il valore, non il puntatore

Lo zoo dei tipi interi

Quanti tipi interi ci sono in C++? Circa cinquanta (se conti anche gli alias a larghezza fissa). E la dimensione non di tutti è fissa, ma dipende dal compilatore e dalla piattaforma.

bool                    // sì, bool — è anch'esso un tipo integrale

char                    // un tipo SEPARATO
signed char             // un tipo SEPARATO
unsigned char           // un tipo SEPARATO, questi sono tre tipi diversi, non due

char8_t                 // C++20
char16_t                // C++11
char32_t                // C++11
wchar_t

short
unsigned short
int
unsigned int
long
unsigned long
long long               // C++11
unsigned long long      // C++11

short, short int, signed short, signed short int          // 4 grafie → 1 tipo
int, signed, signed int                                   // 3 grafie → 1 tipo
long, long int, signed long, signed long int              // 4 → 1
long long, long long int, signed long long, signed long long int  // 4 → 1
unsigned, unsigned int                                    // 2 → 1

int8_t   int16_t   int32_t   int64_t        // larghezza esatta (opzionale)
uint8_t  uint16_t  uint32_t  uint64_t       // 8 di questi

int_least8_t  ... int_least64_t             // larghezza minima
uint_least8_t ... uint_least64_t            // 8 di questi (obbligatori)

int_fast8_t   ... int_fast64_t              // larghezza "veloce"
uint_fast8_t  ... uint_fast64_t             // 8 di questi

intmax_t  uintmax_t                          // il più largo
intptr_t  uintptr_t                          // dimensione-puntatore (opzionale)

std::size_t        // <cstddef>
std::ptrdiff_t     // <cstddef>
std::sig_atomic_t  // <csignal>
std::wint_t        // <cwchar>
std::streamsize, std::streamoff   // <ios>

int non è «32 bit», è «almeno 16 bit, ma forse 32», ed è garantita solo la catena short <= int <= long <= long long. Su Linux a 64 bit long è 64 bit, e su Windows a 64 bit long è ancora 32 bit, a causa della retrocompatibilità (ricorda questa frase). Per ottenere un tipo prevedibile a 64 bit, c'è int64_t, e onestamente non capisco perché abbia il suffisso _t, non siamo più negli anni novanta, ma non si può più cambiare, di più sotto lo spoiler.

I tipi carattere sono a parte meravigliosi, ce ne sono sette, e prima o poi ti imbatterai nella domanda perché un carattere possa persino essere signed e unsigned, come un numero, come char differisca da signed char e unsigned char (e questi sono tre tipi diversi, non due), cosa sia wchar_t, e quale sia la differenza tra std::string e std::wstring, e perché a causa di essa la tua codifica si romperà dal nulla, ma di questo un'altra volta.

La libreria non standard

Se volessi confondere un nuovo arrivato il più possibile, chiamerei le cose esattamente come sono chiamate nella STL. Il container più usato si chiama vector ed è il nostro array dinamico, ma un vettore nel senso ordinario è una quantità con una direzione, e lo stesso Alexander Stepanov, l'autore della STL, ha riconosciuto che il nome fu un errore.

Se volessi una tabella hash, dovrai prendere std::map, ma quello è un albero bilanciato con lookup logaritmico. E una vera tabella hash è std::unordered_map, che, spoiler, è anch'essa meglio non usare, perché è lenta, e non è che «l'implementazione è pigra», è incorporato nello standard stesso. Le garanzie che std::unordered_map è obbligata a fornire non lasciano allo sviluppatore di libstdc++/libc++ altra scelta che renderla lenta.

std::map<std::string, int> ordered;
ordered["banana"] = 1;
ordered["apple"]  = 2;
ordered["cherry"] = 3;

for (auto& [k, v] : ordered)
    std::cout << k << ' ';       // SEMPRE: apple banana cherry, in ordine crescente di chiave

std::unordered_map<std::string, int> hashed;
hashed["banana"] = 1;
hashed["apple"]  = 2;
hashed["cherry"] = 3;

for (auto& [k, v] : hashed)
    std::cout << k << ' ';       // ordine arbitrario, dipende dall'hash e dai bucket

std::unordered_map<std::string, int> m;
m.insert({"key", 1});
m.insert({"key", 2});            // NON ha sovrascritto, ma ha restituito {iterator, false}
std::cout << m["key"];           // 1, non 2

m.insert_or_assign("key", 2);    // dopo il C++17 questo sovrascriverà
std::cout << m["key"];           // 2
m["key"] = 2;                    // oppure semplicemente così

Lo standard di fatto richiede il separate chaining (storage separato) con nodi e unordered_map è obbligata a garantire la stabilità di riferimenti e puntatori agli elementi dopo insert/erase (tranne quello rimosso), affinché un puntatore a un elemento resti valido anche quando il container fa il rehash.

E questo è possibile solo se ogni elemento è allocato separatamente sull'heap (std::pair<const Key, Value> più un puntatore al successivo), e un bucket è fatto come una lista concatenata di tali elementi. Cioè, secondo lo standard non è una «tabella hash in un array», ma un «array di puntatori a liste sparpagliate per l'heap». O un'altra gag con la stessa cosa:

std::unordered_map<std::string, int> m;
if (m["key"] == 0) { }    // se la chiave NON c'era, è stata appena inserita
                          // con il valore di default 0. Il controllo "esiste la chiave" l'ha creata.

operator[] su una chiave mancante inserisce silenziosamente un valore di default, quindi devi controllare la presenza tramite find/contains, non tramite []. Una sciocchezza, certo, ma i nuovi arrivati pestano questo rastrello regolarmente.

E anche i container hanno empty(), che sembra «svuotalo», ma è la nostra domanda «il container è vuoto?». In termini umani sarebbe is_empty(), ma no, mentre c'èremove(), che non rimuove affatto nulla, ma invece sposta gli elementi verso la fine e restituisce un iteratore, e tu rimuoverai separatamente (ciao, erase-remove idiom). E c'è anche std::stoi, std::stol, std::stoll, std::stof, std::stod, std::stold, e devi semplicemente sapere cosa sono. Lo sai, vero?

E non dimenticare i ...value

E per rendere le cose davvero belle per te, ricorda che ci sono lvalue, rvalue, glvalue, prvalue e xvalue. Li ricordi?

E ci sono anche situazioni in cui std::move fa una copia, e che a volte non ti serve std::move, ma std::move_if_noexcept. Dato che siamo in tema di spostamento, std::move ha storicamente un nome scorretto, e non sposta nulla, ma fa solo il cast di un valore a rvalue reference, permettendogli di legarsi a un costruttore di move. Avrebbe dovuto chiamarsi rvalue_cast, ah dannazione... allora avremmo un cast in più.

E anche la libreria standard ha un secondo std::move, che onestamente sposta gli elementi, quindi non confondere quello che sposta con quello che non sposta. E qualcuno mi ha persino mostrato un PDF di 70 pagine su come e quando usare correttamente entrambi gli std::move, peccato non aver ricordato il titolo.

E non sto nemmeno ancora cavillando sui nomi degli idiomi. Ricordi RAII dall'articolo su C++101? Sta per Resource Acquisition Is Initialization, cioè acquisire una risorsa è la sua inizializzazione, ma descrive esattamente il momento opposto, e nell'idioma la cosa principale non è l'acquisizione di una risorsa, ma il suo rilascio automatico nel distruttore all'uscita dallo scope. Cioè, sarebbe CADR (Constructor Acquires, Destructor Releases, «il costruttore acquisisce, il distruttore rilascia»), non RAII (crea una risorsa nel costruttore).

void process() {
    FileHandle file("data.txt");   // aperto

    if (nothing_to_do())
        return;                    // uscita anticipata — il file è chiuso automaticamente

    might_throw();                 // ha lanciato un'eccezione — il file è COMUNQUE chiuso
}                                  // fine ordinaria dello scope — il distruttore ha chiuso il file

O un altro esempio, CRTP - hai letto dentro il nome dell'idioma? CRTP è il Curiously Recurring Template Pattern, «un pattern curiosamente ricorrente», e il nome descrive non ciò che il pattern fa, ma il fatto che la persona che l'ha ideato ci si è imbattuta più volte nei progetti ed è rimasta sorpresa da questa coincidenza, e poi ha chiamato così il pattern.

Modern C++

Hai sentito che dovresti imparare il modern C++? Ma quando googli cosa sia il modern C++, atterri su libri di non so quanti anni fa.

Effective Modern C++ di Scott Meyers (2014), e proprio nel sottotitolo «42 Specific Ways to Improve Your Use of C++11 and C++14»

Modern C++ Design: Generic Programming and Design Patterns Applied

The Modern C++ Challenge

Modern C++: Efficient and Scalable Application Development

Il C++11 è stato il primo «moderno», ha portato smart pointer, lambda e semantica di spostamento (move). Poi sono arrivati 14, 17, 20, 23, e ognuno si è dichiarato il più nuovo e ora di sicuro, definitivamente «moderno». E già il libro di testo più venduto sul modern C++, «Effective Modern C++», non è più moderno, e in alcuni punti nemmeno particolarmente efficace. Nel frattempo l'industria vive da qualche parte intorno al C++17, perché nessuno vuole riscrivere milioni di righe di codice funzionante per essere «più moderno del moderno», perché fa paura.

Il risultato è che sei costretto a conoscere tutte le versioni dello standard in una volta (e differiscono, credimi), perché il vecchio codice al lavoro è scritto in un dialetto, quello nuovo in un altro, il libro di testo ne ha un terzo, il tutorial su YouTube un quarto, e nessuno di essi è modern.

Errori che non stanno in un monitor

Quando finalmente compili qualcosa, ti accolgono i messaggi di errore. Il C++ può scaricare mille righe di spazzatura illeggibile per un singolo ghirigoro fuori posto, con la vera causa sepolta da qualche parte nel mezzo, ma il tuo cervello non riesce più a percepirla, perché metà del testo sono le viscere della libreria standard trapelate all'esterno.

Un errore di istanziazione di template è cinese non convenzionale fatto di parentesi angolari, che occupa così tanto spazio orizzontale che non sta più in un monitor 4K. Ho seriamente cominciato a capire il senso dei monitor ultrawide proprio guardando questi errori, e col tempo ho anche cominciato a disattivare l'a capo automatico, perché con l'a capo era solo peggio. Non c'è da stupirsi che molti sviluppatori C++ abbiano monitor ultrawide, occhiali e un collo malandato.

Astrazioni a costo-forse-zero

Per gli ultimi vent'anni circa il C++ si è venduto come un linguaggio di astrazioni a costo zero, ma qualsiasi astrazione non è più gratuita, e std::unique_ptr è più lento di un puntatore grezzo: ha un distruttore non triviale, e un tale tipo non può essere passato in un registro secondo l'Itanium ABI. Solo attraverso lo stack, mentre un puntatore nudo volerebbe in un registro.

E questo non riguarda solo gli smart pointer, ma qualsiasi tipo con un distruttore non triviale: shared_ptr, string, vector vengono spostati per valore attraverso la memoria per lo stesso motivo. La semantica di spostamento (move) non è gratuita, il problema è nel distruttore, quando si usa il move non distruttivo, quindi l'oggetto da cui hai fatto il move esegue comunque il suo distruttore, e un codice scritto a mano equivalente sarebbe più veloce.

Le espressioni regolari nella libreria standard sono considerate una delle peggiori implementazioni esistenti, in alcuni punti decine e centinaia di volte più lente delle alternative, e già il solo includere <regex> aggiunge un buon secondo di compilazione a ogni translation unit se sei fortunato.

unordered_map è lenta perché è lenta e cache-unfriendly, e se ti serve velocità, ti tiri dentro flat_hash_map da Abseil di Google o F14 da Folly di Facebook. Noti lo schema? Un sacco di cose in C++ potrebbero diventare significativamente più veloci, ma non lo faranno. Perché romperebbe la compatibilità ABI, e qui arriviamo al punto principale.

Compatibilità a costo di tutto

Tutte le lamentele qui sopra, dai nomi storti ai container lenti, dallo zoo di static alle copie invisibili, convergono in un unico punto. La gente pensa che il C++ sia un linguaggio che mette la performance al primo posto, ma in realtà mette la retrocompatibilità al primo posto. Fanculo la performance, fanculo l'ergonomia dello sviluppo, fanculo la developer experience, fanculo tutto in generale.

È proprio l'impegno verso la compatibilità che ha trasformato il linguaggio in un mostro, quando non puoi rinominare vector perché si romperebbe un miliardo di righe di codice, e non puoi velocizzare unordered_map perché cambierebbe l'ABI, e non puoi assolutamente fare il move distruttivo, perché il momento è stato perso una decina d'anni fa, e non puoi rompere ciò che esiste. Ogni bruttura del linguaggio è un fiore di pietra di una decisione sbagliata del passato che non si può buttare via, perché ci sta già sopra qualcosa: la lib di qualcuno, un engine, un gioco o una pipeline.

Ma proprio la proprietà per cui il C++ viene sgridato è proprio la proprietà grazie a cui metà del mondo è scritta in esso. La compatibilità è sia la malattia sia il motivo della sopravvivenza, perché il codice che hai scritto vent'anni fa, con qualche danza e un tamburello, compilerà ancora. Una libreria abbandonata nel 2008 fa ancora il link, e per l'industria dei videogiochi, dove il costo di riscrivere si misura in persona-decenni, questo non è un bug, è un muro portante.

E Rust invece?

Qui nei commenti mi hanno chiesto di dire la mia su Rust. Spero si possa fare a meno delle guerre di religione, è semplicemente diverso.

Rust è di un ordine di grandezza migliore per design. Un compilatore standard, una build standard, un package manager standard, niente file header, i migliori messaggi di errore che abbia visto, default sensati, l'assenza di conversioni implicite, UTF-8 come si deve, sum type, e memory safety a tempo di compilazione. Molti problemi che in C++ non sono risolti e probabilmente non lo saranno nei prossimi dieci anni, in Rust erano già risolti ieri.

Ma «migliore per design» non equivale a «dovresti prenderlo». Lo sviluppo di videogiochi è iterazione rapida, caos creativo e «proviamo così», e Rust non te lo dà, e onestamente - nemmeno il C++ te lo dà più, per quanto nuovo e moderno possa essere. Ecco perché i giochi sono passati a script, DSL e programmazione dichiarativa.

E Rust è fondamentalmente sulla correttezza e la disciplina, e questo conflitto è fondamentale, il che ha portato al fatto che c'è un mucchio crescente di giochi che sono partiti su Rust e ne sono usciti. In più l'ecosistema, per quanto lo giri e rigiri, CUDA, engine, tooling, gazillioni di righe di codice già pronto, tutto ciò è C++, e lo sarà per molto tempo ancora.

Il [P/M]eggior linguaggio di programmazione di tutti i tempi?

Il C++ è un linguaggio terribile. Prolisso dove non serve, e silenzioso anche dove non serve. Con uno zoo di tipi, parole chiave bugiarde, copie invisibili, errori illeggibili e inferno di build.

Per scriverci correttamente ti serve una memoria enciclopedica per le eccezioni, e una volta imparate le eccezioni, separatamente per le eccezioni alle eccezioni. Ma il C++ è più vivo di tutti i vivi, e baratterà via altri diversi decenni, perché ha un'inerzia mostruosa ed è uno dei pochi che ha scelto la compatibilità a ogni costo, probabilmente a costo di tutto. E questa scelta l'ha reso simultaneamente insopportabile e insostituibile. Metà del mondo ci gira sopra, e ci girerà per molto tempo, che mi piaccia o no.

Scrivo in questo linguaggio terribile, romanticizzando la sua complessità e dimostrando a me stesso di essere intelligente. E continuerò a scriverci, perché nel mio campo è finora l'unico che fornisce la performance necessaria, essendo diventato un muro portante. E sostituire questo muro portante in una casa "abitata" e "viva" non è semplicemente «riscrivi un paio di stanze in un linguaggio alla moda», è demolire tutta la dannata casa e costruirne una nuova al suo posto, avendo vissuto un paio d'anni fuori in strada in una baracca.

Quindi sì, il linguaggio è terribile, allora forza, apri già il tuo IDE terribile, e continua a scrivere nel peggior linguaggio di programmazione.