Perché #include <iostream.h> è male?

Stavo leggendo un altro thread in cui un ragazzo ha chiesto informazioni sui libri in C ++ per principianti e uno dei programmatori che ha risposto ha scritto questo:

Alcuni avvertimenti: evita tutti i libri che presentano un "ciao mondo"

#include <iostream.h>

Ho aperto il mio libro C ++ e sicuramente includeva l'intestazione iostream come nell'esempio sopra.

Perché è così male? Quali altri suggerimenti dovrei tenere a mente durante l'apprendimento del C ++?

Contesto: sono esperto di C e inizierò a imparare C ++ nel prossimo semestre.

L'intestazione iostream.h è un'intestazione non standard e non esiste su tutte le piattaforme. È un dato di fatto che non esiste sul mio sistema (usando g ++ e GNU libstdc ++). Quindi qualsiasi codice che lo utilizza semplicemente non si compila sul mio sistema.

L' iostream.hintestazione era comune prima che il C ++ fosse standardizzato per la prima volta nel 1998. Ma poiché lo standard 98 è stato utilizzato al <iostream>posto di <iostream.h>, quest'ultimo è caduto in disgrazia (essendo non standard e tutti) e non è più supportato su tutte le piattaforme. Il codice che lo utilizza deve essere considerato un codice legacy non standard e non è portatile. I libri che lo insegnano dovrebbero essere considerati obsoleti ed evitati.

#include <iostream.h>è un segno che il libro è stato scritto prima del primo standard C ++ nel 1998 (l'intestazione standard è iostream).

Il problema è che il vecchio codice C ++ tende ad essere scritto in modi che oggi sono considerati cattive pratiche. In particolare,

• L'uso di array in stile C anziché di classi contenitore come std::stringe std::vector.
• L'uso di closefunzioni esplicite piuttosto che RAII.

iostream.hnon è la cosa peggiore che un libro precedente al 1998 sbaglierà, ma è probabilmente la prima cosa che un libro precedente al 1998 sbaglierà.

Forse questo arriva un po 'in ritardo, ma per quello che vale, su un box unix / linux ls /usr/{local/,}include/c++/*o simili, in base al layout e ai percorsi. Puoi grepcercare di cercare l'intestazione in questione, come:

ls /usr/{local/,}include/c++/* | grep iostream 

Ciò comporta una ricerca iostream.he qualsiasi altra superstringa.

O esegui find / -type f -name iostream 2> /dev/null | grep includeo locate iostream | grep include(a condizione che il database sia aggiornato, altrimenti anteponi con una chiamata a updatedb) - questi, tuttavia, stamperanno anche inclusioni non a livello di sistema, quindi ti preghiamo di adattarle in modo appropriato. Il percorso di inclusione C ++ effettivo si trova facilmente con qualcosa del tipo:

g++ -v 2>&1| sed -rn 's/.+gxx-include[^=]+=([^ ]+).+/\1/p' # adjust iff empty

Equivalentemente su Windows e altre macchine. Immagino che l'idea sia chiara: un file che iostream.hnon esiste nel sistema include più il percorso di default, tuttavia, puoi ancora trovare le distribuzioni libc ++ legacy con iostream.hsoft-link iostreamo come copia. Quindi questa non è una questione di stile, ma piuttosto delle circostanze. Puoi spedire il tuo iostream.hcon il tuo progetto solo assicurandoti che sia contenuto nel percorso include in cui il compilatore cerca le <...>intestazioni.

Sto solo lasciando cadere i miei 2 centesimi. Non penso che ci sia una correlazione tra ".h" e la qualità di un libro. Questo è un problema minore di sintassi. In passato era in realtà il sinocchio corretto.

È possibile avere un ottimo libro con iostream.h? sì

È possibile avere un libro terribile con iostream? sì

Mi affiderei alle recensioni degli utenti online (e alla mia recensione dopo la lettura) per giudicare la qualità di un libro.