Kapan menggunakan C lebih dari C ++, dan C ++ lebih dari C?

164

Saya telah diperkenalkan ke Ilmu Komputer selama kurang lebih satu tahun sekarang, dan dari pengalaman saya tampaknya C dan C ++ keduanya dianggap sebagai bahasa "ultra cepat", sedangkan yang lain seperti Python dan bahasa skrip semacam itu biasanya dianggap agak lambat .

Tetapi saya juga telah melihat banyak kasus di mana proyek perangkat lunak atau bahkan yang kecil akan interleave file di mana sejumlah n file tersebut akan ditulis dalam C, dan sejumlah m dari file-file tersebut akan ditulis dalam C ++.

(Saya juga memperhatikan bahwa file C ++ hampir selalu memiliki header yang sesuai, sedangkan file C tidak begitu banyak). Tapi pertanyaan utama saya adalah untuk mendapatkan intuisi umum tentang kapan tepat menggunakan C lebih dari C ++, dan ketika lebih baik menggunakan C ++ lebih dari C. Selain fakta bahwa (1) C ++ berorientasi objek sedangkan C tidak, dan (2) sintaksisnya sangat mirip, dan C ++ sengaja dibuat menyerupai C dalam banyak hal, saya tidak yakin apa perbedaannya. Tampaknya bagi saya bahwa mereka (hampir) dapat dipertukarkan dengan sempurna di banyak domain.

Jadi akan sangat dihargai jika seseorang dapat menjernihkan situasi! Terima kasih

c++ c Dark Templar
sumber
4
Menggunakan C inline dalam kode C ++ biasanya untuk modul tertentu yang perlu sangat dioptimalkan, melakukan pekerjaan tingkat rendah lebih dekat ke perangkat keras, atau sangat penting untuk integritas data atau bahkan keselamatan manusia dan perlu diaudit dan terbukti benar. Daripada melakukan semuanya dalam C, sebagian besar proyek dapat mengambil keuntungan dari fitur C ++ untuk desain yang fleksibel, sambil mendapatkan manfaat dari keketatan C di tempat-tempat di mana ia dibutuhkan.
kylben
30
@kylben: Banyak orang C ++ akan memberi tahu Anda: (1) Kinerja bukan alasan untuk turun ke C (mungkin untuk menghindari virtualdan beberapa fitur lain yang mencegah optimalisasi, tetapi misalnya non- virtualkelas tidak inheren tidak efisien, dan templat adalah alat abstraksi kuat yang benar-benar dapat menyebabkan lebih efisien - misalnya qsortvs std::sort). (2) Pentingnya kebenaran adalah alasan untuk menggunakan C ++ (ketelitian, constketelitian, privateRAII untuk membuat pengelolaan sumber daya dapat dikelola, dll.) Di atas C. Atau dalam hal ini, gunakan Ada atau sesuatu di tempat pertama.
11
@ Pubby8 Saya tidak setuju dengan ini. Jika saya mengerjakan file .c dan saya melihat orang-orang melakukan ini, saya cenderung menandai mereka secara mental karena tidak tahu apa yang mereka lakukan. Misalnya, tidak perlu melakukan cast dari void*ke tipe pointer lain dalam kode C, itu sangat mengganggu dan tipikal orang yang tidak tahu C.
asveikau
4
@kylben: (Anda mungkin ingin belajar untuk dengan benar mengatasi orang lain dalam balasan komentar Anda, sehingga mereka memiliki kesempatan untuk benar-benar melihatnya .) Bahwa "seorang programmer yang sangat akrab dengan bagaimana kompiler mengubah C menjadi asm" akan bekerja untuk C ++ sama seperti baik. Tapi itu sama sekali tidak relevan: Jika Anda ingin mencoba-coba asm, cukup tulis asm alih-alih meminta kompiler membuatnya dari bahasa lain. Bagaimanapun caranya cara ini mungkin berubah dengan setiap pembaruan kompiler.
sbi
9
Menurut pendapat saya yang sederhana ... Anda menggunakan C saat Anda menginginkannya, bagi saya: C jauh lebih sederhana dan lebih mudah digunakan daripada C ++ ... C ++ mungkin terlihat seperti "C Dengan kelas", tetapi sekarang tidak lagi, sekarang sudah bahasa yang sangat kompleks, dengan hal-hal seperti Konstruktor dan Template Virtual.
dysoco

Jawaban:

184

Anda memilih C kapan

  • Anda memerlukan assembler portabel (yang merupakan C, benar-benar) untuk alasan apa pun,
  • platform Anda tidak menyediakan C ++ (kompiler C jauh lebih mudah diimplementasikan),
  • Anda perlu berinteraksi dengan bahasa lain yang hanya dapat berinteraksi dengan C (biasanya penyebut umum terendah pada platform apa pun) dan kode Anda terdiri dari sedikit lebih banyak dari antarmuka, tidak membuatnya layak untuk meletakkan antarmuka C di atas kode C ++,
  • Anda meretas dalam proyek Open Source (banyak di antaranya, karena berbagai alasan , tetap berpegang pada C),
  • Anda tidak tahu C ++.

Dalam semua kasus lain, Anda harus memilih C ++.

sbi
sumber
15
Saya juga akan menambahkan bahwa C + + dengan model pengecualian kadang-kadang membawa lebih banyak masalah daripada nilainya, misalnya, kernel OS. Setidaknya itulah perasaan umum yang saya dapatkan ketika membaca tentang hal-hal.
Coder
12
@ SF: C adalah lingua franca? Itu baru. Atau lebih tepatnya, sangat tua. Mungkin jika Anda hanya berkomunikasi dengan orang-orang yang tidak belajar bahasa baru selama 20 tahun terakhir, tetapi saya akan mengatakan bahwa pengetahuan C tidak terlalu umum lagi.
DeadMG
13
@ SF: Seperti yang telah saya tulis di tempat lain, saya pernah berada di proyek yang berjumlah jutaan LoC, dan melihat sangat sedikit meta-stuff dibandingkan dengan proyek C dengan peretasan makro mereka yang tak terhindarkan dan ada di mana-mana. (OTOH, kemampuan untuk membuat EDSL ketika dibutuhkan dapat menjadi alat yang sangat kuat di komputer Anda.) Adapun C menjadi lingua franca: Saya lebih suka berpegang pada istilah saya bahwa itu adalah denominator umum terendah. Dan saya tidak ingin orang dengan keterampilan pemrograman sedang meretas kernel OS.
sbi
18
@ Max: Saya benar-benar tidak setuju. C adalah bahasa yang tidak berguna, kecuali beberapa penghalang praktis yang tidak dapat diatasi mencegah penggunaan C ++.
DeadMG
17
@ Tombol: Itu kamu yang membuat klaim ("C ++ membutuhkan lebih banyak memori"), jadi seharusnya kamu yang mendukung itu. Dan, tidak, saya tidak mengklaim bahwa C ++ membutuhkan lebih sedikit memori. Apa yang saya katakan adalah bahwa fitur biaya, tidak peduli apakah kompiler mengimplementasikannya untuk Anda (fungsi virtual) atau Anda melakukannya sendiri (array pointer fungsi).
sbi
88

Ada beberapa alasan untuk memilih C. Yang utama adalah bahwa ia cenderung lebih sulit untuk menghasilkan executable yang benar-benar kecil dengan C ++. Untuk sistem yang sangat kecil, Anda jarang menulis banyak kode, dan ruang ROM tambahan yang akan dibutuhkan untuk C ++ daripada C dapat menjadi signifikan.

Saya juga harus menambahkan, bahwa untuk sistem yang sangat kecil, C memiliki masalah dengan alasan yang persis sama, dan bahasa assembly hampir merupakan satu-satunya pilihan yang masuk akal. Rentang ukuran sistem di mana C benar-benar masuk akal cukup kecil, dan menyusut terus-menerus (meskipun saya akui, cukup lambat).

Waktu / alasan lain untuk menggunakan C adalah untuk menyediakan satu set fungsi yang dapat Anda ikat dari dasarnya bahasa lain. Anda dapat menulis fungsi-fungsi ini dalam C ++ dengan mendefinisikannya sebagai extern "C"fungsi, tetapi hal itu membatasi fungsi-fungsi tersebut untuk menghadirkan "wajah" kehidupan-C yang esensial bagi dunia - kelas, fungsi yang kelebihan beban, templat, dan fungsi anggota, dll., Tidak perlu menerapkan. Ini tidak selalu membatasi pengembangan ke C - sangat masuk akal untuk menggunakan segala macam fitur C ++ secara internal , selama antarmuka eksternal terlihat seperti C.

Pada saat yang sama, saya harus mengatakan bahwa jawaban @ Toll (untuk satu contoh yang jelas) memiliki hal-hal yang mundur dalam banyak hal. C ++ yang ditulis secara wajar umumnya akan setidaknya secepat C, dan seringkali setidaknya sedikit lebih cepat. Keterbacaan umumnya jauh lebih baik, jika hanya karena Anda tidak terkubur dalam longsoran semua kode bahkan untuk algoritma dan struktur data yang paling sepele, semua penanganan kesalahan, dll.

Template tidak "memperbaiki masalah dengan sistem jenis bahasa", mereka hanya menambahkan sejumlah kemampuan mendasar yang hampir sepenuhnya tidak ada dari C dan / atau C ++ tanpa template. Salah satu tujuan awal adalah menyediakan wadah yang aman untuk jenis, tetapi pada kenyataannya mereka jauh melampaui itu - pada dasarnya tidak ada yang disediakan C sama sekali.

Alat otomatis sebagian besar adalah herring merah juga - sementara memang benar bahwa menulis parser C kurang bekerja daripada menulis parser C ++, kenyataannya adalah bahwa itu membuat hampir tidak ada perbedaan pada akhirnya. Sangat sedikit orang yang bersedia atau mampu menulis parser yang dapat digunakan untuk salah satu dari keduanya. Dengan demikian, titik awal yang masuk akal adalah Dentang baik.

Seperti yang terjadi, C dan C ++ cukup sering digunakan bersama pada proyek yang sama, dikelola oleh orang yang sama. Hal ini memungkinkan sesuatu yang sebaliknya sangat jarang terjadi: sebuah penelitian yang secara langsung, secara obyektif membandingkan pemeliharaan kode yang ditulis dalam dua bahasa oleh orang-orang yang sama-sama kompeten secara keseluruhan (yaitu, orang yang sama persis). Setidaknya dalam penelitian terkait, satu kesimpulan jelas dan tidak ambigu: "Kami menemukan bahwa menggunakan C ++ bukannya C menghasilkan peningkatan kualitas perangkat lunak dan mengurangi upaya pemeliharaan ..."

Jerry Coffin
sumber
12
Alat pendukung bukanlah herring merah. Memang, saat ini kami memiliki dentang. Tetapi dukungan alat untuk C ++ memang tertinggal jauh dari bahasa-bahasa yang jauh, bahkan dalam IDE besar. Mengapa demikian? Sederhana, karena sampai saat ini tidak ada dentang (dan GCC tidak pernah menjadi alternatif). Hingga mungkin setengah tahun yang lalu, jika Anda membutuhkan AST kode C ++, Anda pada dasarnya kurang beruntung atau keluar dari ribuan dolar (jika Anda membeli ujung depan EDG).
Konrad Rudolph
5
+1, dan sebagai catatan, saya secara teratur menulis kode C ++ untuk prosesor 8-bit dengan ROM 4KiB.
avakar
2
+1 untuk jawaban keseluruhan yang bagus. Apa yang saya tidak mengerti (saya tidak punya pengalaman wrt. Ini) adalah mengapa (saya kira kita sedang berbicara tertanam?) Sebuah kompiler C harus menghasilkan kode dieksekusi lebih kecil daripada kompiler C ++ diberikan fitur set yang sama digunakan ? Mungkin Anda bisa memberikan beberapa referensi?
Martin Ba
2
@ Martin: hal utama adalah bahwa C ++ termasuk penanganan exception, yang (setidaknya biasanya) menambahkan beberapa ukuran minimum ke executable. Sebagian besar kompiler akan memungkinkan Anda menonaktifkan penanganan pengecualian, tetapi ketika Anda melakukan hasilnya tidak cukup C ++ lagi. Saya menduga ada juga sedikit dari fakta sederhana bahwa banyak vendor compiler C ++ tidak bekerja cukup keras untuk menghasilkan kode output sekecil mungkin.
Jerry Coffin
3
"Kami menemukan bahwa menggunakan C ++ bukannya C menghasilkan peningkatan kualitas perangkat lunak dan mengurangi upaya pemeliharaan ..." itulah kesimpulan yang perlu diingat.
Stephane Rolland
24

Perbedaan antara C dan C ++ telah disebutkan secara rinci di sini . Meskipun kadang-kadang orang mungkin memiliki alasan yang sah untuk memilih satu atau yang lain (C ++ untuk OOP atau C ketika mereka merasa seperti fitur tambahan C ++ memperkenalkan overhead yang tidak diinginkan, misalnya), dalam pengalaman saya biasanya hanya tergantung pada preferensi. Apa yang orang-orang yang bekerja di file ini tahu lebih baik dan lebih suka? Saya percaya ini adalah alasan sebagian besar waktu, karena memang benar bahwa kedua bahasa ini menangani aplikasi kritis kinerja.

(Catatan tambahan: Lihat kata-kata kasar Linus Torvads tentang mengapa ia lebih suka C ke C ++. Saya tidak perlu setuju dengan poinnya, tetapi itu memberi Anda wawasan tentang mengapa orang mungkin memilih C daripada C ++. Sebaliknya, orang yang setuju dengannya mungkin memilih C karena alasan ini.)

Casey Patton
sumber
51
-1untuk kata-kata kasar Linus. : - {
sbi
12
Jangan minus satu saya untuk itu! Ha ha. Saya tidak setuju dengan Linus, tetapi ini adalah contoh yang bagus mengapa MENGAPA orang memilih C daripada C ++ (jika mereka percaya apa yang diyakini Linus). Saya tidak mengomentari legitimasi alasan itu.
Casey Patton
10
@CaseyPatton: Pada dasarnya, saya menurunkan setiap jawaban yang menyajikan kata-kata retorika ini tanpa komentar seolah-olah itu adalah argumen nyata.
sbi
11
@ Kode: Anda tidak perlu tahu implementasi STL sama sekali. Inti dari STL adalah bahwa Anda tidak harus mengetahui implementasinya, kecuali jika Anda mengandalkan perilaku yang tidak didefinisikan oleh Standar- dalam hal ini, mengapa repot-repot menggunakan perpustakaan Standar? Selain itu, lebih dari sedikit gila untuk tidak menyukai bahasa karena perilaku pengembangnya. Pemrogram C berperilaku seperti C adalah pemberian Tuhan kepada Manusia dan terlalu buta untuk melihat kebenaran yang jelas bahwa C ++ menawarkan fitur yang secara fundamental dan secara intrinsik langsung lebih unggul daripada C, seperti RAII.
DeadMG
8
@ Kode: Jika Anda berakhir dengan begitu banyak shared_ptrs ke satu objek yang Anda limpahkan counter internal, Anda salah melakukannya. Standar akan menentukan ukuran minimum untuk penghitung - mungkin 32bit - dan itu cukup tidak realistis untuk memiliki lebih dari 2 miliar shared_ptrs ke satu objek tunggal. Bahkan jika objek itu sendiri memiliki ukuran 0, dan Anda memiliki pengalokasi memori nol-overhead, maka Anda masih mengkonsumsi 16GB memori, hanya pada shared_ptrs.
DeadMG
13

Masalah utama yang hilang dari jawaban yang ada (pada saat posting ini) adalah pilihan.

Itu mudah. Jika, karena alasan yang sangat tidak masuk akal, Anda merasa bahwa pengecualian tidak sebanding dengan biaya overhead, maka Anda tidak perlu menggunakannya . Anda masih dapat memiliki templat, dan RAII, dan pustaka standar, dan tidak pernah menulis satu pun "lemparan". Hal yang sama berlaku untuk template. Jika, karena alasan tertentu, Anda merasa mereka menyebabkan bloat yang tidak dapat dibatalkan (dan sebenarnya penting, yang hanya ada di embedded), maka Anda dapat menggunakan void * dan sizeof (T) sepanjang hari juga. Tidak ada yang memaksa Anda untuk menggunakan salah satu fitur C ++ di atas C.

Itu sebabnya C ++ adalah bahasa yang secara inheren unggul - Anda dapat memilih fitur yang Anda inginkan, dan kembali ke pemrograman gaya-C ketika Anda tidak menyukai fitur yang diberikan. Oleh karena itu, mengingat bahwa C ++ adalah segalanya C dan banyak lagi, itu adalah fakta yang jelas bahwa C ++ adalah bahasa yang unggul. Menyarankan sebaliknya sama dengan mencoba menyarankan bahwa 4 lebih besar dari 5.

DeadMG
sumber
1
Mengikuti alasan Anda, tidak ada gunanya sama sekali dalam pertanyaan awal dan karena itu harus ditutup. Saya kira pertanyaannya harus dibaca seperti: kapan kita harus membatasi diri pada subset C dari C ++ (gunakan plain C) dan kapan masuk akal untuk menggunakan C ++ penuh.
Giorgio
Ini benar, tetapi hanya untuk kasus satu orang yang mengerjakan proyek kecil mereka sendiri. Dalam kehidupan nyata hampir setiap orang menghabiskan setengah dari waktu mereka mengerjakan kode orang lain. Sayangnya kebanyakan orang "berpikir salah" mengenai alasan yang sama sekali tidak masuk akal itu.
DarenW
1
@DeadMG: Bagaimana pengalokasi dimaksudkan untuk melaporkan kesalahan tanpa melemparkan pengecualian? Juga, menambahkan lebih banyak fitur tidak selalu lebih baik ketika semua yang dilakukannya menambah kompleksitas atau redundansi.
Mankarse
@Mankarse: Jika Anda mengompilasi dengan opsi untuk menonaktifkan pengecualian, pengalokasi membatalkan program atau dengan senang hati melanjutkan menggunakan pointer nol, tergantung pada implementasi perpustakaan.
Zan Lynx
4
@Mankarse: Sejak pengalaman saya pada tahun 2007 ketika saya mencoba menjalankan sistem Linux dengan RAM 1 GB dan tanpa swap, hampir semua perangkat lunak desktop gagal dengan cara yang mengerikan ketika alokasi memori gagal.
Zan Lynx
9

Hal-hal tentang C ++ yang membuat programmer C gugup

Ada banyak keajaiban terjadi di bawah tenda; konstruktor, destruktor, metode virtual, templat, dll., dapat membuat kode C ++ jauh lebih mudah dan lebih cepat untuk ditulis daripada kode C yang setara, tetapi lebih sulit untuk dipahami dan dijelaskan (tergantung pada seberapa baik Anda mengetahui C ++ dan konvensi terkait). Sesuatu yang sesederhana Foo newFoo;mungkin memanggil banyak kode, tergantung pada bagaimana konstruktor untuk kelas Foo(dan semua kelas yang bergantung padanya) telah didefinisikan. Inilah sebabnya mengapa konvensi ini adalah menulis ++italih-alih it++ketika iterasi melalui suatu wadah, karena postfix ++sering melibatkan operasi penyalinan yang mahal.

Tergantung pada apa yang Anda lakukan, mungkin ada beberapa overhead non-sepele, terutama untuk tugas-tugas sederhana. Ambil dua program berikut, yang pertama di C, yang kedua di C ++:

/* C version */
#include <stdio.h>
int main(void)
{
  char greeting[] = "Hello, world";
  printf("%s\n", greeting);
  return 0;
}
/* end C version */

/* C++ version */
#include <iostream>
#include <string>
int main(void)
{
  std::string greeting("Hello, world");
  std::cout << greeting << std::endl;
  return 0;
}
/* end C++ version */

Perilaku identik, tidak banyak perbedaan dalam hal sumber, tetapi pada kotak 10 SLES saya bekerja dengan gcc 4.1.2, yang pertama menghasilkan executable ~ 9kb dalam ukuran, sedangkan yang kedua mengambil lebih dari 12.5kb (tidak ada optimasi ), hampir 28% lebih besar. Tipe C ++ stringjauh lebih mudah untuk bekerja dengan IMO daripada pustaka string C, dan stream C ++ jauh lebih fleksibel dan dapat dikustomisasi daripada stream C, tetapi untuk kode yang benar-benar mati otak seperti ini, mereka mungkin tidak sebanding dengan overhead.

C ++ adalah bahasa yang sangat besar dibandingkan dengan C, dengan beberapa semantik yang sangat kompleks. Dibutuhkan jauh lebih lama untuk menjadi mahir dengan C ++ daripada C, yang berarti banyak orang yang mengaku tahu C ++ tidak mengetahuinya sebaik yang mereka kira.

Hal-hal tentang C yang membuat programmer C ++ gugup

C bukan bahasa pemrograman yang aman oleh imajinasi apa pun; tidak ada batas memeriksa pada array menyebabkan banyak perilaku dieksploitasi (baik itu melalui sekarang-mati getsfungsi, atau melalui scanfdengan %sdan %[specifier konversi). C ++ setidaknya memberi Anda wadah yang melempar pengecualian jika Anda mencoba mengakses di luar kisaran yang ditentukan saat ini; semua C memberi Anda adalah (jika Anda beruntung) pelanggaran segmentasi.

Manajemen memori di C sangat padat karya dan rentan kesalahan, dibandingkan dengan alat yang disediakan C ++ untuk Anda. Jika Anda membangun wadah sendiri, Anda bertanggung jawab untuk mencocokkan semua mallocdan freepanggilan, memastikan alokasi berhasil, mencadangkan semua alokasi parsial jika terjadi kesalahan, dll. Dalam C ++, Anda hanya menambahkan item ke atau hapus item dari wadah. Jika ada masalah, pengecualian akan dilempar.

Demikian pula, penanganan kesalahan dalam C adalah rasa sakit di pantat dibandingkan dengan alat C ++ menyediakan (yaitu, pengecualian). Apa yang benar-benar menyenangkan adalah ketika Anda telah mengalokasikan banyak memori dan kemudian menabrak dinding dalam pemrosesan Anda; karena Anda harus mundur, Anda harus melepaskan memori itu dalam urutan yang benar. Dengan prinsip-prinsip C ++ dan RAII, ini (relatif) mudah dilakukan.

Jadi kapan saya menggunakan satu di atas yang lain?

Jika apa yang Anda tulis adalah rawa sederhana, bacalah / hilangkan dengan itu / singkirkan aplikasi itu, yang perilakunya dapat dijelaskan secara bersih dalam hal input dan output, dan masalah kinerja, maka lebih suka C daripada C ++. Kalau tidak, lebih suka C ++

John Bode
sumber
2
Manajemen memori rumit dan rawan kesalahan dalam beberapa kasus, tetapi terutama di dunia tertanam sering praktis untuk menulis program C menggunakan alokasi memori yang sepenuhnya statis. Jika program terhubung, tidak dapat kehabisan memori saat runtime. Bisakah jaminan seperti itu mudah dicapai dalam C ++?
supercat
9

Bjarne Stroustrup menyimpan daftar aplikasi dan perusahaan yang menggunakan C ++; Anda dapat berdebat tentang pemrograman prosedural dan OOP semua yang Anda inginkan, tetapi Anda tidak dapat berdebat dengan hasil industri selama 20 tahun terakhir.

C ++ umumnya digunakan untuk proyek berskala besar, multi-man, dan kompleks di mana orang yang terpisah perlu bekerja pada komponen modularis. Anda dapat membangun dan memelihara kode yang termodulasi dalam C, tentu saja, tetapi sifat OOP yang melekat pada C ++ mengarah pada modularisasi yang lebih baik, kemampuan testabilitas, dan penggunaan kembali kode.

C ++ standard library (STL), dengan sendirinya hanya dengan vektor dan peta, adalah alasan yang cukup untuk menggunakan C ++.

C umumnya digunakan untuk sistem embedded.

Saya pribadi akan menggunakan C hanya jika ada beberapa perpustakaan yang hanya memiliki API C.

stackoverflowuser2010
sumber
19
Kalimat terakhir Anda bukan alasan untuk menggunakan C. Anda dapat memanggil perpustakaan C dari C ++.
user207421
2
Saya menggunakan c ++ untuk proyek DSP - bukan c
BЈовић
9

Saya akan mengatakan bahwa alasan utama mengapa saya akan memilih C daripada C ++, hanya ketika saya harus menggunakan "Kalau ini TELAH MENJADI 1000% stabil" semacam NASA.

C ++ adalah ~ 99% C ketika kita melihat kinerjanya, dan itu jauh lebih produktif. Jadi walaupun di C Anda dapat menulis kode yang akan lebih cepat daripada C ++ (Anda dapat menggunakan subset dari C ++ tanpa pengecualian, virtual, streaming, abstraksi, dll. Juga, tapi itu pada dasarnya C), waktu untuk mengoptimalkan setiap hal sialan sementara STL diuji dan sudah melakukannya, akan dikenakan biaya lebih banyak daripada perolehan kinerja kecil yang mungkin Anda raih, atau berkorban karena algoritma STL telah ditulis oleh kelompok ahli, dan Anda mungkin bukan ahli dalam segala hal.

Di sisi lain C ++ memiliki banyak abstraksi. Ketika dalam keadaan mereka bocor, ini membuat Anda kesulitan. Dan ada beberapa orang yang tahu 100% C ++ Gotcha, sementara, saya kira, ada lebih banyak yang tahu semua C Gotcha, jadi menulis solusi di mana setiap langkah dipahami sepenuhnya oleh semua anggota tim jauh lebih mudah di C.

Contoh: Apakah Anda tahu kapan shared_ptr<smthn>akan melebihi jumlah referensi, akankah ia mengeluarkan pengecualian? Hal-hal seperti ini tidak keren ketika Shuttle harus masuk kembali ke atmosfer, setidaknya kurasa begitu.

Juga, penanganan pengecualian sangat, sangat sulit dibandingkan dengan kode kesalahan. Sulit untuk melihat apakah kelasnya 100% aman, dan mudah bocor. Banyak perwakilan tinggi menyatakan pendapat ini.

Coder
sumber
12
Dan dengan cara apa tepatnya mengelola memori secara manual "lebih stabil" daripada abstraksi C ++ seperti std::stringdan sejenisnya? Apakah Anda pernah mencoba menentukan platform tempat shared_ptrpenghitung akan meluap? Itu akan menjadi salah satu dari platform lucu. Dan jika Anda berpikir penanganan pengecualian sulit, Anda harus melihat sepotong kode C yang memeriksa setiap kemungkinan kesalahan pada setiap panggilan fungsi. (Saya akui kode seperti itu sulit didapat, tetapi ini hanya argumen yang lebih kuat terhadap pernyataan Anda.) Maaf, tapi ini benar-benar kotoran sapi.
sbi
12
@Lundin: '"Itu harus stabil 1000%" implementasi tidak mengizinkan alokasi memori dinamis di tempat pertama'. Dan apa yang membuat Anda tidak melakukan hal itu di C ++ ?? (Dan membuat pernyataan selimut tentang pengetahuan dan pengalaman saya daripada memberikan argumen apa pun adalah trik retorika yang agak murah.)
sbi
10
@Lundin: Bagus karena Anda sudah mulai memberikan argumen, alih-alih retorika. Tapi mereka lemah. Bahwa Anda telah "lupa" salah satu fitur utama C ++ (templat), yang membuat kode lebih aman (karena memungkinkan algoritma untuk dieksekusi - dan dengan demikian, gagal - pada waktu kompilasi , menghilangkan kesalahan run-time), tidak berbicara mendukung pengetahuan Anda tentang bahasa yang Anda nilai. Pengurangan C ++ ke bahasa OO telah dikritik sebelumnya di sini, dan untuk alasan yang baik. (Selain itu, kelas dengan kehancuran deterministik adalah alat yang hebat dan membantu untuk mengelola sumber daya lain selain hanya memori.)
sbi
9
@Lundin Tentu saja Anda tidak ingin menggunakan std::stringjika Anda tidak ingin alokasi dinamis. Anda akan menggunakan std::basic_string<char, std::char_traits<char>, some_allocator_here>.
Luc Danton
10
@ Kode: Apa yang Anda buktikan dengan ini? Yang pertama adalah kode yang benar-benar buruk (dan akan menjadi kesalahan pelaporan yang sama buruknya dengan nilai pengembalian), yang kedua membuat kasus untuk RAII atas pembersihan manual yang mana setiap C + + dev setengah layak akan bersorak, dan Joel, sama seperti saya menghormatinya, mengatakan beberapa hal yang sangat tidak saya setujui. Sumbatnya untuk single-entry-single-exit berbau buruk dari kentut tua yang tidak tahu yang tidak akan pernah setuju bahwa apa yang dia pelajari 25 tahun yang lalu telah dilampaui. (Pikiran Anda, saya telah pemrograman 25 tahun yang lalu, ketika Sese adalah keadaan seni.)
sbi
6

C adalah rakitan portabel dengan sintaksis yang lebih baik, memberikan programmer kendali penuh atas segalanya .

C ++ di sisi lain, melakukan banyak sihir yang funky (fungsi virtual, kelebihan muatan, konversi otomatis, dll.) Yang mungkin tidak diinginkan ketika Anda ingin memastikan Anda:

  • jangan menggunakan lebih banyak memori daripada yang Anda inginkan
  • jangan mengakses halaman memori mau tak mau (vtable bisa di mana saja)
  • jangan meminta banyak kode secara tidak sengaja

Dan ingin sesuatu yang sangat sederhana untuk dikerjakan, karena Anda fokus pada kinerja.

Tidak ada kejutan, dan itu sangat berharga.

Jika Anda ingin (dan saya merekomendasikannya), bacalah panduan pengkodean JSF tentang apa yang perlu Anda pikirkan saat menulis C ++ untuk kontrol avionik militer. Ada banyak jebakan di sana yang perlu Anda waspadai, dan itu bisa membuat Anda keluar. Bjarne adalah bagian dari dokumen itu, jadi dia tahu tentang apa itu.

Juga, C mengkompilasi seperti troll tersiram cahaya tersambar petir. C ++, OTOH, mungkin disponsori oleh orang yang sama yang berinvestasi di perusahaan SSD. :)

(Secara pribadi, saya lebih suka C ++, tapi saya juga tidak suka ......; ;-P)

Macke
sumber
1
Ada banyak hal yang tidak dapat dikendalikan oleh C. Cobalah menulis kode portabel yang efisien untuk melipatgandakan uint32_t dengan uint32_t untuk menghasilkan hasil uint32_t (32 bit produk terbawah). Jika suatu int64 bit, seseorang harus melemparkan setidaknya satu operan untuk uint64_tmencegah Undefined Behavior, tetapi harus dilemparkan ke 64 bit untuk tujuan menghitung hasil 32-bit adalah - dengan kata lain - "mengejutkan".
supercat
Ini bukan. Kompiler melakukan hal-hal seperti mendaftarkan alokasi untuk Anda. Saya tidak bisa menulis kode yang bisa dipelihara dalam perakitan, di CI bisa.
Nils
2

(mengingat Anda memiliki keakraban yang sama dengan kedua bahasa)

Pergilah dengan C ++ kecuali tidak ada kompiler C ++ untuk platform Anda. Anda dapat menulis kode C ++ tanpa bagian bahasa apa pun yang tidak Anda sukai (tidak ada kelas, pengecualian, warisan virtual, apa pun batasan pribadi yang ingin Anda terapkan), dan kemudian pada suatu waktu di masa depan, jika Anda memutuskan ingin beberapa setelah semua fitur itu, maka Anda dapat dengan mudah menggunakannya. Tidak ada dalam C ++ yang mencegah Anda menulis kode gaya-C.

(diberikan alat yang setara dan pengetahuan pengembang) Tidak ada alasan untuk memilih C lebih dari C ++ asalkan platform Anda memiliki kompiler C ++. Anda dapat membatasi diri Anda sendiri ke subset dari bahasa yang Anda inginkan hari ini, sambil membiarkan pintu terbuka untuk perpanjangan nanti.

segera
sumber
1

Kedua bahasa sangat bagus. Saya pikir sejumlah poster telah merinci kekuatan dan berbagai kegunaan untuk masing-masing poster. Saya hanya akan menambahkan ini:

Saya melihat bahasa C sempurna dalam 4 bidang: 1) Saya pikir itu adalah bahasa terbaik untuk digunakan ketika pertama kali belajar semua jenis pemrograman [dikombinasikan dengan beberapa Majelis dan pengetahuan tentang kode mesin], 2) sangat bagus untuk menulis driver, 3) tertanam perangkat lunak, dan 4) perangkat lunak sistem pada tingkat terendah.

C ++ adalah bahasa berorientasi objek, tetapi juga bisa bersifat prosedural (sangat menghalangi C). Jika Anda bekerja pada proyek skala besar, perangkat lunak berbasis GUI, perangkat lunak game, dan jenis perangkat lunak intensif grafis lainnya, maka saya menemukan C ++, Java, atau bahkan Objective-C sebagai pilihan terbaik Anda. Namun, ada banyak program command-line atau perangkat lunak sistem di mana Anda mungkin menemukan C ++ lebih baik atau lebih baik daripada C.

Jonathan
sumber
0

Menurut pendapat saya ada satu hal yang hilang dalam diskusi ini: Lebih sederhana dalam C untuk menyediakan antarmuka biner yang stabil dari perpustakaan. Baik untuk penggunaan dengan bahasa lain maupun C ++.

Dalam C ++ kompiler yang berbeda menggunakan susunan nama yang berbeda sehingga konsumen perpustakaan yang dikompilasi dengan kompiler yang berbeda dari perpustakaan mungkin memiliki masalah dalam menggunakannya. Dengan C antarmuka biner, biasanya, distandarisasi untuk platform.

Saya tahu bahwa kompiler saat ini sering memiliki sakelar untuk menghasilkan hal-hal yang kompatibel dengan gcc, tetapi itu tidak selalu membantu.

Saya mengamati ini pada Solaris relatif sering. Distribusi dan vendor perangkat lunak yang berbeda biasanya menggunakan Sun Studio sebagai, terutama pada sistem Sparc, seringkali memberikan hasil yang lebih baik. Proyek sumber terbuka manusia ditulis dengan kode khusus gcc. Bisa jadi cukup menyakitkan untuk membuat mereka bekerja bersama.

johannes
sumber
0

C mungkin lebih disukai daripada C ++ ketika kode C dihasilkan (misalnya dalam implementasi bahasa tingkat tinggi). Sebagai contoh, ada beberapa kompiler Lisp-like yang memancarkan kode C (misalnya Chicken , Scheme48 ...), tapi saya tidak tahu yang memancarkan kode C ++ asli ( alat MELT saya memancarkan kode C ++, tapi saya tidak akan menyebut kode itu asli Kode C ++, menggunakan sangat sedikit fitur C ++).

Kode C juga lebih mudah dibuktikan secara semi-otomatis. Analisis statis seperti Frama-C (di mana Anda membubuhi keterangan kode C Anda dengan komentar ACSL untuk membantu alasan yang tepat tentang kode Anda) tersedia untuk C, tetapi tidak sebanyak itu untuk C ++ 11 penuh.

Basile Starynkevitch
sumber