Confronto e Template Avanzati

Ogni volta che un template viene istanziato (quando il compilatore scopre quali tipi gli hai passato), il compilatore deve avere a disposizione tutto il codice sorgente del template per poterne generare la variante concreta.

Questo significa che tutte le informazioni su come istanziare la classe o la funzione devono trovarsi all’interno della stessa translation unit (ovvero dello stesso file di codice) in cui il template viene invocato. Di gran lunga, il modo più popolare per risolvere questa limitazione è implementare i template interamente all’interno dei file Header (.hpp o .h).

Vantaggi dell’approccio Header-Only:

• Praticità immensa per l’utente: per usare la tua libreria generica a un programmatore basterà fare #include del tuo header file, senza doversi preoccupare di linkare object files esterni o complicati step di compilazione (la Standard Template Library - STL è quasi interamente header-only).
• Ottimizzazioni violente: Essendo tutto il codice sorgente srotolato di fronte al compilatore nel punto di chiamata, le possibilità di inlining (rimozione del costo di chiamata a funzione) ed elaborazione aggressiva a compile-time sono altissime.

Certo, i tempi di compilazione potrebbero dilatarsi a dismisura in grossi progetti commerciali, ma è un compromesso ampiamente accettato nel C++ Moderno.

Metaprogrammazione dei Template (Turing Completeness)

Quello che all’inizio era un mero sistema per “trovare e rimpiazzare tipi” si è rivelato accidentalmente un linguaggio Turing-Completo eseguito interamente a tempo di compilazione.

I cosiddetti maghi del C++ (C++ Wizards) usano la Template Metaprogramming e le “Type Functions” (funzioni che accettano un Tipo e ne ritornano un Tipo) per effettuare calcoli computazionali complessi esclusivamente durante la compilazione. Vediamo un esempio classico: il calcolo del Fattoriale interamente a compile-time, sfruttando l’istanziazione ricorsiva dei template.

Questa tecnica sfrutta la Specializzazione dei Template: puoi fornire implementazioni alternative per valori specifici dei parametri (qui Factorial<0> funziona da caso base della ricorsione). Il compilatore genera Factorial<10>, che richiede Factorial<9>, che richiede Factorial<8>, e così via fino a Factorial<0> dove si ferma.

Sebbene elegante, questa forma “classica” di metaprogrammazione è criptica e illeggibile. Le feature moderne del C++ (constexpr, consteval, e i Concepts) stanno finalmente rendendo queste tecniche più accessibili e leggibili, riducendo la necessità di ricorrere ad artifici esoterici per ottenere calcoli a compile-time.

Polimorfismo a Runtime vs Compile-Time: Un Resoconto

Hai visto due modi profondamente diversi di ottenere il Polimorfismo. Quale scegliere?

Scegli i Template (Compile-Time) se:

• Le performance in esecuzione sono l’obiettivo critico, zero compromessi.
• Conosci a priori a compile-time le possibili variazioni dei tipi o degli oggetti.
• Vuoi usare i Concepts (C++20) per interfacce rigidamente tipizzate.
• Vuoi una classe svincolata e snella (senza vtable di puntatori nascosti o puntatori in memoria che de-localizzano i dati riducendo le performance di cache).

Scegli le Interfacce Classiche (Runtime Polymorphism) se:

• Non hai idea di quali tipi la tua applicazione maneggerà finché essa non è in esecuzione (ad es. interfacce utente flessibili, plugin caricati da DLL terze parti).
• Devi inserire i tuoi oggetti all’interno di collezioni eterogenee (es. vuoi un std::vector<Shape*> che contenga contemporaneamente Triangoli, Quadrati e Cerchi derivanti tutti da un’interfaccia Shape base).
• I tempi di compilazione dilatati sono un problema, e desideri compilare il corpo del codice separatamente nei file .cpp.

Molti programmi C++ eleganti fondono i due regni, appoggiandosi a collezioni generiche fornite dai Template (come std::vector) per contenere puntatori e interfacce (Runtime Polymorphism).