La versione 26 di C++ potrebbe essere anche una delle ultime? Forse no, ma Rust dovrà diventare lo standard

6
C++ Logo

Questa notizia potrebbe tranquillamente rientrare nella categoria delle “cose scontate, ma che scontate non sono per nulla”. Già, perché l’annuncio dell’imminente nuova release di C++, la 26, effettuato da Herb Sutter di Microsoft, mostra la vitalità di un progetto che a dispetto degli anni (è stato creato negli anni ’80 da Bjarne Stroustrup) si dimostra attivo ed in costante evoluzione.

Sebbene l’NSA ne sconsigli l’utilizzo, e della divertente questione ne abbiamo parlato in questo bell’articolo di Jacopo Prendin a cui proprio Stroustrup rispondeva alla NSA, C++ è sostanzialmente dappertutto: è il linguaggio in cui è scritto il Kernel di Microsoft Windows, o quello di macOS, è alla base dei motori di gioco come Unity e Unreal Engine, è il linguaggio di Photoshop, MySQL o PostgreSQL e ci sono miriadi di componenti che utilizzano componenti scritte in C++, vedi Mozilla Firefox o Google Chrome.

La versione 26 di cui ha parlato Sutter viene descritta come “imponente” in termini concorrenza e parallelismo.

Ma perché 26? Va sottolineato come le versioni C++ siano denominate in base all’anno di rilascio e seguano un ciclo di tre anni. La notizia della nuova promettente release arriva dal comitato di sviluppo che, nell’avviare il ciclo per la nuova versione, si è riunito a Varna (in Bulgaria) e online, con quasi 180 membri, adottando formalmente la schedulazione di C++ 26.

Nella pratica Sutter ha indicato come il criterio per la schedulazione della release sia lo stesso del C++ 23, con l’aggiunta di tre anni “ovunque”.

L’ultima data per le nuove (mai viste in precedenza) funzionalità da introdurre nel linguaggio è fissata nel terzo trimestre del 2024 e il blocco delle funzionalità è il primo trimestre del 2025.

La notizia potrebbe anche finire qui, non fosse che, come sovente accade ultimamente, a compendio dell’annuncio sono fornite diverse dichiarazioni da parte di chi governa i processi di sviluppo di questi linguaggi, ed a colpire sono parole come quelle di Mark Russinovich, CTO di Microsoft, che dice:

it’s time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated.

è ora di fermarsi dallo sviluppare nuovi progetti in C/C++ ed utilizzare Rust per quegli scenari in cui è richiesto un linguaggio non-GC (Garbage collection). In virtù della sicurezza e dell’affidabilità l’industria dovrebbe deprecare quei linguaggi.

Il che sposta l’attenzione anche su Linux e tutti i ragionamenti in merito alle implementazioni Rust che abbiamo raccontato negli ultimi mesi: Il linguaggio C (e di riflesso anche C++, almeno nativamente) non ha un sistema di Garbage Collection incorporato. I programmatori devono esplicitamente allocare e liberare la memoria utilizzando funzioni come malloc() e free() ed abbiamo tutti visto in termini di sicurezza cosa questo può comportare.

Da qui il monito: basta progettare con linguaggi che dovrebbero essere deprecati.

Siamo di fronte quindi alle prime avvisaglie di estinzione per C, C++ ed affini? In realtà no, di certo non nell’immediato. Centinaia di software sono sviluppati in quei linguaggi e tutto il codice esistente difficilmente (se non impossibilmente) sarà migrato, quindi la risposta alla provocazione nel titolo è chiara: C++ continuerà ad essere manutenuto ed evoluto per molto, molto tempo.

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

6 risposte a “La versione 26 di C++ potrebbe essere anche una delle ultime? Forse no, ma Rust dovrà diventare lo standard”

  1. Avatar Qfwfq
    Qfwfq

    Piccola provocazione: visto che i vari linguaggi sono delle espressioni regolari non dovrebbe essere difficile istruire una AI per tradurre da uno all’altro, per esempio da C++ a Rust, e poi ricompilare il tutto.

  2. Avatar Qfwfq
    Qfwfq

    Premetto che si tratta solo di una questione oziosa e che prima di metterlo in produzione ce ne vuole, però sarebbe solo una questione di validazione della AI, testata su un adeguato numero di regole di conversione e di nidificazione niente vieterebbe di provarla su grandi strutture.

  3. Avatar JaK
    JaK

    Il motivo sarebbe l’affidabilità. Non basterebbe convertire le righe di codice da un linguaggio a un altro in automatico e che poi il nuovo sorgente compili. Bisogna fare comunque una review e dei test, specialmente se si tratta di programmi utilizzati in situazioni critiche.

  4. Avatar Raoul Scarazzini

    Con le dovute limitazioni non la ritengo una boutade… Quello che scrivi ha senso.

  5. Avatar Qfwfq
    Qfwfq

    E magari una AI bene addestrata mi sa che qualche baco lo trova.

  6. Avatar JustATiredMan
    JustATiredMan

    C e C++ non moriranno mai. In ambiti industriali, e sopratutto quelli ad alto livello, dove sono richieste certificazioni EAL già sopra la 5 (se non sbaglio), non è nemmeno accettato il garbage collector o l’allocazione dinamica della memoria.
    Certamente sono situazioni estreme, dove c’è in gioco la vita, ma se ci pensate bene, una qualsiasi macchina di produzione manifatturiera può esserlo.
    A quei livelli, si vuole che tutto sia predicibile, e che quindi, quella “variabile là, deve essere memorizzata in quella locazione là” e questo, le varie allocazioni dinamiche della memoria e garbage non sono molto d’aiuto.
    https://en.wikipedia.org/wiki/Evaluation_Assurance_Level

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *