Untuk memulainya, akan selalu ada beberapa masalah yang lebih baik diselesaikan dalam satu bahasa daripada yang lain. Akan selalu ada bahasa yang memecahkan masalah khusus "lebih baik" daripada bahasa lain, untuk beberapa definisi "lebih baik". Namun, sejumlah besar masalah memiliki kebutuhan yang sangat mirip (beberapa I / O, beberapa perhitungan) dan menghadapi persyaratan yang serupa (keandalan yang wajar, kinerja yang wajar).
Seperti yang Anda ketahui C, untuk sebagian besar masalah di luar sana, saya menyatakan bahwa C ++ tidak memberikan kerugian yang signifikan dan sejumlah peningkatan signifikan. Berani? Beberapa orang tampaknya berpikiran demikian, tetapi sebenarnya itulah masalahnya. Mari kita mulai dengan membersihkan beberapa kesalahpahaman C ++ yang sangat umum:
C ++ lebih lambat dari C. Salah! Banyak program C juga merupakan program C ++ yang valid - dan program C seperti itu harus berjalan dengan kecepatan yang sama ketika dikompilasi dengan kompiler C atau kompiler C ++.
C ++ fitur spesifik memerlukan overhead. Salah! Yang disebut overhead yang diperkenalkan oleh fitur spesifik C ++ tertentu (seperti panggilan fungsi virtual atau pengecualian), sebanding dengan overhead yang Anda sendiri akan perkenalkan seandainya Anda mengimplementasikan fitur serupa di C.
C ++ berorientasi objek. Salah! Bahasa C ++ berisi beberapa ekstensi bahasa yang memfasilitasi pemrograman berorientasi objek dan pemrograman generik. C ++ tidak memaksa desain berorientasi objek di mana pun - hanya memungkinkannya. C memungkinkan untuk pemrograman berorientasi objek juga, C ++ hanya membuatnya lebih sederhana dan lebih rentan kesalahan.
Jadi, jika Anda percaya kepada saya, kami telah menetapkan bahwa "C ++ tidak jauh lebih buruk daripada C". Mari kita lihat apa yang membuat C ++ menjadi C yang lebih baik:
Pengetikan yang lebih kuat Sistem tipe di C ++ lebih kuat daripada di C. Hal ini mencegah banyak kesalahan pemrograman umum - ditambah dengan fitur yang sangat penting berikutnya, sistem tipe yang lebih kuat bahkan mengelola untuk tidak menjadi ketidaknyamanan.
Jenis parameterisasi Kata kunci templat memungkinkan programmer untuk menulis implementasi algoritma generik (tipe-agnostik). Di mana dalam C, orang bisa menulis implementasi daftar generik dengan elemen seperti:
struct element_t {
struct element_t *next, *prev;
void *element;
};
C ++ memungkinkan seseorang untuk menulis sesuatu seperti:
template <typename T>
struct element_t {
element_t<T> *next, *prev;
T element;
};
Tidak hanya implementasi C ++ mencegah kesalahan programmer umum (seperti menempatkan elemen dari tipe yang salah pada daftar), itu juga memungkinkan pengoptimalan yang lebih baik oleh kompiler! Misalnya, implementasi penyortiran generik tersedia di C dan C ++ -
rutin C didefinisikan sebagai:
void qsort(void *base, size_t nmemb, size_t size,
int(*compar)(const void *, const void *));
sedangkan rutin C ++ didefinisikan sebagai
template void sort(RandomAccessIterator first, RandomAccessIterator last);
Perbedaannya adalah, bahwa misalnya mengurutkan array bilangan bulat, akan, dalam kasus C, memerlukan pemanggilan fungsi untuk setiap perbandingan tunggal, sedangkan implementasi C ++ akan memungkinkan kompiler untuk menyejajarkan panggilan perbandingan bilangan bulat, karena rutinitas aktual yang sebenarnya adalah secara otomatis dipakai pada waktu kompilasi oleh kompiler, dengan jenis yang benar dimasukkan dalam argumen template.
- Pustaka standar yang lebih besar C ++ memungkinkan penggunaan penuh pustaka standar C. Ini tentu saja sangat penting, karena pustaka standar C adalah sumber yang tak ternilai saat menulis program dunia nyata. Namun, C ++ termasuk Perpustakaan Template Standar. STL berisi sejumlah templat yang bermanfaat, seperti semacam rutinitas di atas. Ini termasuk struktur data umum yang berguna seperti daftar, peta, set, dll. Seperti rutinitas sortir, rutinitas STL lainnya dan struktur data "disesuaikan" dengan kebutuhan spesifik yang dimiliki oleh programmer - yang harus dilakukan oleh programmer hanyalah mengisi jenis.
Tentu saja, STL bukanlah peluru perak - tetapi memang memberikan bantuan yang sangat sering, ketika memecahkan masalah umum. Seberapa sering Anda menerapkan daftar di C? Seberapa seringkah pohon RB akan menjadi solusi yang lebih baik, andai saja Anda punya waktu untuk melakukannya? Dengan STL Anda tidak perlu membuat kompromi seperti itu - gunakan pohon jika lebih cocok, semudah menggunakan daftar.
Ok, jadi saya hanya mendiskusikan bagian yang bagus. Apakah ada kerugian? Tentu saja ada. Namun, jumlah mereka menyusut dari hari ke hari. Biarkan saya jelaskan:
Tidak ada kompiler C ++ yang bagus Sudah seperti ini sejak lama. Tetapi Anda harus ingat, bahwa bahasa itu distandarisasi pada tahun 1998 - itu adalah bahasa yang kompleks, lebih kompleks dari C. Butuh waktu lama bagi penyusun untuk mengejar standar. Tetapi pada tulisan ini, ada kompiler yang baik tersedia untuk platform yang paling banyak digunakan di luar sana; GCC dalam versi 3.X umumnya sangat baik, dan ini berjalan pada GNU / Linux dan sebagian besar platform UNIX. Intel memiliki kompiler yang bagus untuk Win32 - ini juga cukup bagus, tetapi sayangnya masih bergantung pada MS STL yang merupakan sub-par.
Orang-orang tidak tahu C ++ yang bagus Ini bukan keluhan yang sering didengar, tetapi ini adalah sesuatu yang saya lihat banyak. C ++ adalah bahasa yang besar dan kompleks - tetapi juga merupakan bahasa yang banyak digemari, terutama pada masa "OOP memecahkan kelaparan, menyembuhkan AIDS dan kanker". Hasilnya tampaknya banyak kode C ++ yang benar-benar buruk, pada dasarnya C buruk dengan beberapa deklarasi kelas di sana-sini, ada di luar sana dan digunakan sebagai bahan pembelajaran. Ini berarti banyak orang yang percaya mereka tahu C ++ sebenarnya menulis kode yang benar-benar jelek. Itu terlalu buruk, dan ini masalah, tapi saya pikir tidak adil untuk menyalahkan ini pada C ++.
Jadi, hanya dua masalah utama dengan C ++ adalah hasil dari C ++ menjadi bahasa yang muda. Pada waktunya mereka akan lenyap. Dan untuk sebagian besar masalah di luar sana, jika Anda bisa mendapatkan programmer yang baik (atau belajar C ++ yang baik sendiri), masalahnya bukan masalah saat ini.