Guida Frequently asked questions: da dove si parte?

Personalmente preferisco quasi sempre programmare in C rispetto al C++, e nei casi in cui non mi è necessario usare C preferisco usare qualcosa di completamente differente (insomma evito C++ per quanto possibile, ma questi sono gusti personali).
Una delle motivazioni che hanno formato questo gusto è la mancanza di coraggio che secondo me al momento c'è per quel che riguarda lo sviluppo del C++.

Negli anni si sono aggiunti standard su standard, molte cose sono state deprecate, alcune rimosse (basti vedere gli standard C++11, 14 e 17). La mancanza di coraggio dov'è?
E' il rimanere legati, vuoi per retrocompatibilità e tante altre motivazioni, alle feature di C.
Al momento C++ è veramente un ammasso confusionario di sintassi enorme, ci sono veramente 10 modi differenti per fare qualsiasi cosa, di questi modi però 3 sono stilisticamente considerati balordi, 4 sono deprecati, 1 è da folli e 2 sono accettati (ovviamente è un esempio).
Ma insomma mi è capitato spesso lavorando in progetti grossi di perdere più tempo per rimanere aggiornato sullo standard e su quale sarebbe stato il modo migliore per fare una determinata cosa che altro.

Non è possibile dopo 40 anni avere un linguaggio che non ha tagliato praticamente nulla, e uno dei problemi che dice Torvalds deriva proprio da questo, molti programmatori C++ scrivono completi aborti di codice, e la colpa (o almeno parte della colpa) è dello stesso linguaggio che permette questi scempi.
Scempi giustificati perché sinceramente è abbastanza fastidioso ogni volta doversi andare a controllare lo standard attuale e ricontrollare se cose scritte 2 anni fa sono ancora considerate decenti oppure al momento sono deprecate.
E non dico che non devono esserci cose deprecate, dico che dopo 40 anni molta roba che è deprecata debba smettere di essere supportata, ed è questo il coraggio che secondo me manca.

E' assurdo che ancora per la gestione della memoria ci siano molte opzioni e soprattutto che ancora possa essere gestito tutto alla C-style, puntatori e tutto compreso. Naturalmente questo utilizzo è sconsigliato e deprecato, e allora perché continuare a permetterlo?
All'inizio aveva senso, dopo 40 anni non lo so.

C'è bisogno, secondo me, di una rigorosa, severa e coraggiosa pulizia.
 
  • Mi piace
Reazioni: SpeedJack
Sì, però tieni conto che ho volutamente citato solo un pezzo del suo messaggio.
Lui lascia intendere STL e Boost non sono portable e non sono stabili, ma è oggettivamente falso in un contesto puramente generico. È un'assunzione valida quasi solo se si parla di programmare il kernel di un sistema operativo, ma per qualsiasi altra cosa sia STL che Boost sono veramente lo state of the art. Per git ha scelto il C perché "efficiency was a primary objective" e anche il C++ era troppo high level, ma mercurial (il diretto concorrente di git) è scritto in python. Anche "C++ compilers are not trustworthy" è una frase decisamente azzardata: magari non lo erano nel '92, ma 25 anni dopo mi sembra una frase eccessiva anche se ti metti a programmare un kernel.
Per GCC hanno scelto di passare dal C al C++ (link) e già questo fa riflettere.

Personalmente non sono un fan dell'exception handling, pochi linguaggi hanno questo sistema esposto nel modo in cui piace a me, quindi non sarò io a difendere questo sistema, però "l'exception handling di C++ è uno scandalo" è una frase che va motivata. Sia STL che Boost fanno un uso sensato delle eccezioni e mi fa solo piacere sapere che non sono over-utilizzate come in Java.

Molti dei ragionamenti che fa sono relativi a quello programma lui, ma un kernel non è il tipico progetto che il programmatore medio si mette a scrivere. Quindi buona parte del ragionamento fatto da Torvalds non è rilevante per la domanda fatta da C3n21.
"l'exception handling di C++ è uno scandalo" ovviamente è una affermazione di spettanza dello sviluppo di kernel. Le eccezioni potrebbero non essere del tutto acconce per lo sviluppo di kernel perchè la sincronizzazione può essere una "mollezza" in più in quanto più difficile da garantire. L'opposto per gli error code in C.
Anche impiegare la proficua feature RAII di C++, una delle più ricche del linguaggio, potrebbe essere deleteria in un kernel. http://harmful.cat-v.org/software/c++/linus:
- the whole C++ exception handling thing is fundamentally broken. It's
_especially_ broken for kernels.
- any compiler or language that likes to hide things like memory
allocations behind your back just isn't a good choice for a kernel.

- you can write object-oriented code (useful for filesystems etc) in C,
_without_ the crap that is C++.
nel secondo punto, Torvalds ha palesato che l'automazione (più che hiding) di operazioni cruciali potrebbe comportare pessimi avvenimenti. Difatti gli sviluppatori del kernel di solito non prediligono queste caratteristiche.
 
  • Mi piace
Reazioni: DanyDollaro
"l'exception handling di C++ è uno scandalo" ovviamente è una affermazione di spettanza dello sviluppo di kernel.
Eh si... esattamente quel che dicevo prima, gran parte delle affermazioni che fa hanno senso solo se sviluppi un kernel. Il punto è che il kernel di un sistema operativo è un progetto di nicchia e non rappresenta assolutamente ciò che il programmatore medio ha interesse nello sviluppare. Di conseguenza, gran parte delle sue affermazioni non hanno alcun valore nel nostro contesto. La parte che ho scelto di riportare è quella che mi sembrava ragionevole e condivisibile per una domanda molto più generica rispetto a quella a cui lui risponde.

C'è bisogno, secondo me, di una rigorosa, severa e coraggiosa pulizia.
Eh... in realtà per il C++ non c'è bisogno proprio di niente. Sarà brutto quanto ti pare, ma è già il linguaggio principe per i progetti che richiedono performance o operazioni low level. Non è secondo a nessuno e se proprio bisogna dare consigli a qualcuno, bisognerebbe darli ai linguaggi che tentano di rimpiazzarlo. Con il C++ stanno già facendo quel che è necessario per non farlo diventare obsoleto.

E' assurdo che ancora per la gestione della memoria ci siano molte opzioni e soprattutto che ancora possa essere gestito tutto alla C-style, puntatori e tutto compreso. Naturalmente questo utilizzo è sconsigliato e deprecato, e allora perché continuare a permetterlo?
Come ho scritto nell'open post: la parola d'ordine è retrocompatibilità. In Python la codebase media è nell'ordine delle centinaia di righe di codice, con python3 (2008) hanno rotto la retrocompatibilità e 9 anni dopo abbiamo ancora due versioni di python mantenute in parallelo. In C++ la codebase media è nell'ordine delle migliaia di linee di codice, i cambiamenti da fare sarebbero più radicali e fare ciò che è stato fatto con python sarebbe del tutto insostenibile (e anche poco saggio).

Inoltre, per come la vedo io, il sistema di gestione della memoria non è una di quelle cose che rimuoverei. Ma questo è un altro discorso.
 
Non posso più modificare l'open post, ma segnalo che il link da cui si può scaricare la versione aggiornata di MinGW-w64 (windows) è winlibs.com (ringrazio @CrazyMonk per aver provato). Sul sito ufficiale le versioni precompilate non sono molto aggiornate. In alternativa si può usare MYSYS2 o Cygwin che contengono MinGW-w64, ma sono più vicini ad essere qualcosa in stile WSL. Personalmente consiglio MinGW-w64 da winlibs per chi vuole un installazione minimale e MYSYS2 per chi vuole un'esperienza unix-like pur compilando eseguibili per windows (a differenza di WSL), altrimenti sono ancora validi gli IDE segnalati nell'open post.
 
  • Mi piace
Reazioni: 0xbro e --- Ra ---