Originariamente inviato da GliderKite
Che io sappia, per quanto riguarda l'utilizzo di strutture dati base (tipiche del C) rispetto all'utilizzo delle strutture dati offerte dalla STL, la scelta tra un array C-style piuttosto che l'utilizzo di un vector è da favorirsi comunque quando si ha a che fare con dimensioni non eccessivamente grandi e soprattutto quando si intende utilizzare un allocazione statica della memoria, poichè i vector si basano sull'allocazione/deallocazione dinamica della memoria e ciò comporta in ogni caso una minor efficienza.
Solo al momento dell'allocazione; e, come detto, std::array consente di avere array allocati sullo stack.
Invece per quanto riguarda l'utilizzo di allocatori automatici, come possono essere gli smart-pointer, questi sono meno efficienti dei "normali" puntatori in quanto devono garantire la mutua esclusione delle operazioni.
Dipende dal tipo di smart pointer. Uno scoped_ptr/unique_ptr (che vanno bene nella stragrande maggioranza dei casi, dove serve semplicemente semantica RAII per una risorsa locale) ha virtualmente zero overhead.
E, nonostante il fatto che alcune caratteristiche base del C++ (come e soprattutto l'utilizzo delle eccezioni) possano minare l'efficienza dell'applicazione,
Al di là di un leggero aumento delle dimensioni dell'eseguibile, le eccezioni "costano" solo nel momento in cui sono sollevate. Per il resto, se non sono sollevate quasi mai, sono anche più efficienti dell'approccio a codici restituiti perché non ci deve essere un if ad ogni chiamata a funzione, è cioè il codice del throw che si va a cercare l'handler, non c'è del codice che controlla ad ogni momento se non si è verificato un errore.
Senza contare che, nonostante il discorso di MItaly riguardo ad un "C++ migliore" se non si fosse mantenuta una piena compatibilità con il C (il che molto probabilmente è vero), tutt'oggi l'utilizzo del C++, come tutti sappiamo, consente anche lo sfruttamento di quelle che sono le migliori caratteristiche del C
Più che altro ha contribuito al suo successo il fatto di poter integrare facilmente codice legacy e di consentire a molti programmatori C di credere di saper programmare in C++.
(ad esempio un buon codice sorgente C++ potrebbe contenere funzioni come fread/fwrite, più efficienti rispetto alle read/write).
Scusa la pignoleria, ma read/write (se si parla delle syscall POSIX) di base dovrebbero essere leggermente più veloci delle relative funzioni di libreria C, dal momento che si salta un livello di astrazione.