Apakah ada alasan untuk menggunakan C ++ alih-alih C, Perl, Python, dll? [Tutup]


164

Sebagai pengembang Linux (sisi server), saya tidak tahu di mana dan mengapa saya harus menggunakan C ++.

Ketika saya mencari kinerja, pilihan pertama dan terakhir adalah C.

Ketika "kinerja" bukan masalah utama, bahasa pemrograman seperti Perl dan Python akan menjadi pilihan yang baik.

Hampir semua aplikasi open source yang saya tahu di bidang ini telah ditulis dalam C, Perl, Python, skrip Bash, AWK atau bahkan PHP, tetapi tidak ada yang menggunakan C ++.

Saya tidak membahas bidang lain seperti GUI atau aplikasi web, saya hanya berbicara tentang Linux, CLI dan daemon.

Apakah ada alasan memuaskan untuk menggunakan C ++?


5
Saya hanya mempertimbangkan C ++ karena STL.
dan_waterworth

46
Jadi sesuatu yang bisa dilakukan dengan menggunakan C, perl dan python bersama-sama dapat dilakukan dengan menggunakan C ++ saja. Dan Anda bertanya mengapa menggunakan C ++?
Manoj R

36
«Ketika saya pergi ke pertunjukan, pilihan pertama dan terakhir adalah C.» ya tentu: D Ini adalah pernyataan yang tidak terbukti dan salah.
deadalnix

16
@deadalnix: Saya tidak akan mengatakan itu. C ++ memiliki aturan kompleks yang mungkin menjadi bumerang pada pengoptimal, karena tidak diperbolehkan melakukan beberapa hal. Dan sangat mudah untuk melangkah menjadi pembunuh kinerja yang tidak terlihat. Ini cukup aksiomatis, dan karena itu benar: D Masih dalam kenyataannya kode C ++ kadang-kadang akan lebih cepat karena Anda akan menggunakan algoritma dan struktur data yang lebih efektif, dan toh tidak ada yang benar-benar mengoptimalkan kode C. Jadi ketika dilakukan dengan benar, C ++ lebih aman dan lebih efektif C, dan Anda harus memilih C ++ lebih dari C ketika tidak ada masalah kompatibilitas, atau persyaratan untuk perangkat lunak ketersediaan 100%.
Coder

4
Alasan terbaik, tidak dipertimbangkan dalam jawaban yang diposting, secara langsung berkaitan dengan pertanyaan OP. DEPENDANCIES !!!!, bukan berarti sistem rata-rata Anda tidak memiliki c ++ libs, tetapi sistem yang disematkan mungkin tidak memilikinya. Satu-satunya cara untuk mendapatkan program Anda di setiap sistem, adalah menulis program Anda secara teratur C. Yang lainnya hanya memperdebatkan mengapa Anda harus, atau kurang terwakili, tidak boleh menggunakan C ++. Tidak ada yang membahas mengapa C ++ tidak digunakan lebih sering, dan terlepas dari prestasi, alasannya adalah dependensi .... O dan juga kata-kata kasar Lin ++ yang terkenal.
JM Becker

Jawaban:


308

Ketika saya akan tampil, pilihan pertama dan terakhir adalah C.

Dan di situlah Anda harus membuat cadangan. Sekarang, saya tidak bisa, sama sekali , berbicara untuk pengembangan server. Mungkin memang tidak ada alasan kuat untuk memilih C ++ daripada alternatif.

Tapi secara umum, alasan untuk menggunakan C ++ daripada bahasa lain memang kinerja. Alasan untuk itu adalah bahwa C ++ menawarkan sarana abstraksi yang, tidak seperti semua bahasa lain yang saya tahu, tidak ada overhead kinerja saat runtime.

Ini memungkinkan penulisan kode yang sangat efisien yang masih memiliki tingkat abstraksi yang sangat tinggi.

Pertimbangkan abstraksi biasa: fungsi virtual, pointer fungsi, dan idiom PIMPL. Semua ini bergantung pada tipuan yang pada saat runtime diselesaikan oleh pointer aritmatika. Dengan kata lain, ini menimbulkan biaya kinerja (betapapun kecilnya).

C ++, di sisi lain, menawarkan mekanisme tipuan yang tidak menimbulkan biaya (kinerja): templat. (Keuntungan ini dibayar dengan waktu kompilasi yang meningkat (terkadang sangat besar).)

Pertimbangkan contoh fungsi sortir generik.

Dalam C, fungsi qsortmengambil pointer fungsi yang mengimplementasikan logika dengan mana elemen-elemen diurutkan relatif terhadap satu sama lain. Arrays.sortFungsi Java hadir dalam beberapa varian; salah satu dari mereka macam objek sewenang-wenang dan membutuhkan Comparatorobjek diteruskan untuk itu yang bekerja mirip dengan pointer fungsi dalam C qsort. Tetapi ada beberapa kelebihan lainnya untuk tipe Java "asli". Dan masing-masing dari mereka memiliki salinan sortmetode sendiri - duplikasi kode yang mengerikan.

Java menggambarkan dikotomi umum di sini: Anda memiliki duplikasi kode atau Anda mengalami overhead runtime.

Di C ++, sortfungsinya sangat mirip qsortdi C, dengan satu perbedaan kecil tapi mendasar: pembanding yang diteruskan ke fungsi adalah parameter templat . Itu berarti bahwa panggilannya dapat digarisbawahi . Tidak perlu tipuan untuk membandingkan dua objek. Dalam lingkaran yang ketat (seperti halnya di sini) ini sebenarnya dapat membuat perbedaan besar.

Tidak mengherankan, fungsi C ++ sortmengungguli C sortbahkan jika algoritma yang mendasarinya sama. Ini terutama terlihat ketika logika perbandingan sebenarnya murah.

Sekarang, saya tidak mengatakan bahwa C ++ adalah apriori yang lebih efisien daripada C (atau bahasa lain), atau apriori yang menawarkan abstraksi yang lebih tinggi. Apa yang ditawarkannya adalah abstraksi yang sangat tinggi dan sangat murah pada saat yang bersamaan sehingga Anda sering tidak perlu memilih antara kode yang efisien dan yang dapat digunakan kembali.


16
Sekarang saya cukup tahu tentang C ++ untuk mengetahui apakah Anda tepat atau salah. Tetapi juga ingin menambahkan Anda hanya menerima 1 downvote jadi santai. Ini adalah internet dan terjadi downvotes. Jawabannya bagus jika secara teknis terdengar!
Chris

46
tidak ada overhead kinerja saat runtime - itu tidak selalu benar. Jika Anda melihat implementasi vektor STL Anda akan melihat bahwa mereka tidak mengambil keuntungan menggunakan realloc () (mereka tidak bisa karena pointer, cerita panjang) sedangkan semua bahasa tingkat yang lebih tinggi yang saya tahu bisa dan memang menggunakan realloc ( ) dalam vektor impl's. Ini hanya satu contoh yang tidak begitu jelas dan semuanya hitam putih.
mojuba

19
@Jaroslaw, @Steve: tetapi yang sama (= kode mengasapi, cache instruksi meleset) benar untuk kode yang dioptimalkan dengan tangan yang disesuaikan untuk setiap tipe data (lihat berbagai Arrays.sortimplementasi Java ). Hanya Anda yang kehilangan keunggulan dari abstraksi tinggi. Ini bukan kerugian spesifik dari template, ini adalah kerugian dari duplikasi kode secara umum. Selain itu, ini cenderung tidak menjadi masalah karena dalam loop ketat, biasanya selalu kode yang sama yang dimuat.
Konrad Rudolph

18
@ Javarlaw: lucunya tentang cache instruksi adalah itu adalah cache . Artinya, itu tidak mencoba untuk menyimpan semuanya , hanya kode yang baru saja digunakan . Template mungkin menghasilkan banyak kode serupa untuk tipe yang berbeda ( vector.push_backuntuk vector<int>, dan yang lain untuk vector<float>, tetapi saat bekerja dengan vector<int>, ada sedikit alasan mengapa vector<float>kode tersebut berada dalam cache instruksi. Jadi saya tidak melihat bagaimana itu benar-benar penting. Setiap instantiasi template individual sangat dioptimalkan dan biasanya lebih kompak daripada implementasi catch-all generic
jalf

29
@ Steve314: Apa yang Anda sebut "mengasapi" adalah apa yang dilakukan secara manual untuk C dan Java. Dalam C ++, itu bisa otomatis, dan kompiler bisa sepintar vendor berani membuat mereka menghindari mengasapi. Jika saya harus memutuskan antara menjadi lambat (seperti dalam C) atau menggunakan kode duplikat (seperti di Jawa), meminta kompiler melakukan duplikasi (dan mungkin menjadi pintar tentang hal itu) tampaknya cukup bagus, bukan?
sbi

166

Saya melihat terlalu banyak programmer C yang membenci C ++. Butuh beberapa waktu (bertahun-tahun) untuk perlahan memahami apa yang baik dan apa yang buruk tentang itu. Saya pikir cara terbaik untuk mengungkapkannya adalah ini:

Lebih sedikit kode, tidak ada overhead run-time, lebih aman.

Semakin sedikit kode yang kita tulis, semakin baik. Ini dengan cepat menjadi jelas di semua insinyur yang berjuang untuk keunggulan. Anda memperbaiki bug di satu tempat, tidak banyak - Anda mengekspresikan algoritma sekali, dan menggunakannya kembali di banyak tempat, dll. Orang Yunani bahkan memiliki pepatah, ditelusuri kembali ke Spartan kuno: "untuk mengatakan sesuatu dengan sedikit kata, berarti bahwa Anda bijak tentang hal itu ". Dan faktanya, adalah bahwa ketika digunakan dengan benar , C ++ memungkinkan Anda untuk mengekspresikan diri Anda dalam kode yang jauh lebih sedikit daripada C, tanpa biaya kecepatan runtime, sementara lebih aman (yaitu menangkap lebih banyak kesalahan pada waktu kompilasi) daripada C.

Berikut ini contoh sederhana dari penyaji saya : Saat menginterpolasi nilai piksel melintasi garis pindai segitiga. Saya harus mulai dari koordinat X x1, dan mencapai koordinat X x2 (dari kiri ke sisi kanan segitiga). Dan di setiap langkah, di setiap piksel yang saya lewati, saya harus menginterpolasi nilai.

Saat saya menginterpolasi cahaya sekitar yang mencapai piksel:

  typedef struct tagPixelDataAmbient {
      int x;
      float ambientLight;
  } PixelDataAmbient;

  ...
  // inner loop
  currentPixel.ambientLight += dv;

Ketika saya menginterpolasi warna (disebut shading "Gouraud", di mana bidang "merah", "hijau" dan "biru" diinterpolasi oleh nilai langkah di setiap piksel):

  typedef struct tagPixelDataGouraud {
      int x;
      float red;
      float green;
      float blue;  // The RGB color interpolated per pixel
  } PixelDataGouraud;

  ...
  // inner loop
  currentPixel.red += dred;
  currentPixel.green += dgreen;
  currentPixel.blue += dblue;

Ketika saya membuat warna "Phong", saya tidak lagi menyisipkan intensitas (ambientLight) atau warna (merah / hijau / biru) - Saya menginterpolasi vektor normal (nx, ny, nz) dan pada setiap langkah, saya harus kembali -menghitung persamaan pencahayaan, berdasarkan vektor normal yang diinterpolasi:

  typedef struct tagPixelDataPhong {
      int x;
      float nX;
      float nY;
      float nZ; // The normal vector interpolated per pixel
  } PixelDataPhong;

  ...
  // inner loop
  currentPixel.nX += dx;
  currentPixel.nY += dy;
  currentPixel.nZ += dz;

Sekarang, insting pertama programmer C adalah "heck, tulis tiga fungsi yang menginterpolasi nilai-nilai, dan memanggil mereka tergantung pada mode yang ditetapkan". Pertama-tama, ini berarti saya memiliki masalah tipe - apa yang saya kerjakan? Apakah piksel saya PixelDataAmbient? PixelDataGouraud? PixelDataPhong? Oh, tunggu, programmer C yang efisien mengatakan, gunakan serikat pekerja!

  typedef union tagSuperPixel {
      PixelDataAmbient a;
      PixelDataGouraud g;
      PixelDataPhong   p;
  } SuperPixel;

..dan kemudian, Anda memiliki fungsi ...

  RasterizeTriangleScanline(
      enum mode, // { ambient, gouraud, phong }
      SuperPixel left,
      SuperPixel right)
  {
      int i,j;
      if (mode == ambient) {
          // handle pixels as ambient...
          int steps = right.a.x - left.a.x;
          float dv = (right.a.ambientLight - left.a.ambientLight)/steps;
          float currentIntensity = left.a.ambientLight;
          for (i=left.a.x; i<right.a.x; i++) {
              WorkOnPixelAmbient(i, dv);
              currentIntensity+=dv;
          }
      } else if (mode == gouraud) {
          // handle pixels as gouraud...
          int steps = right.g.x - left.g.x;
          float dred = (right.g.red - left.g.red)/steps;
          float dgreen = (right.g.green - left.a.green)/steps;
          float dblue = (right.g.blue - left.g.blue)/steps;
          float currentRed = left.g.red;
          float currentGreen = left.g.green;
          float currentBlue = left.g.blue;
          for (j=left.g.x; i<right.g.x; j++) {
              WorkOnPixelGouraud(j, currentRed, currentBlue, currentGreen);
              currentRed+=dred;
              currentGreen+=dgreen;
              currentBlue+=dblue;
          }
...

Apakah Anda merasakan kekacauan itu menyelinap masuk?

Pertama-tama, satu kesalahan ketik adalah semua yang diperlukan untuk mem-crash kode saya, karena kompiler tidak akan pernah menghentikan saya di bagian "Gouraud" dari fungsi, untuk benar-benar mengakses ".a." nilai (ambient). Bug yang tidak ditangkap oleh sistem tipe C (yaitu, selama kompilasi), berarti bug yang bermanifestasi pada saat run-time, dan akan membutuhkan debugging. Apakah Anda memperhatikan bahwa saya mengakses left.a.greendalam perhitungan "dgreen"? Kompiler pasti tidak memberi tahu Anda.

Lalu, ada pengulangan di mana-mana - forloop ada di sana sebanyak yang ada mode rendering, kami terus melakukan "kanan minus kiri dibagi dengan langkah-langkah". Jelek, dan rawan kesalahan. Apakah Anda perhatikan saya membandingkan menggunakan "i" di loop Gouraud, padahal seharusnya saya menggunakan "j"? Kompiler sekali lagi, diam.

Bagaimana dengan if / else / ladder untuk mode? Bagaimana jika saya menambahkan mode rendering baru, dalam tiga minggu? Akankah saya ingat untuk menangani mode baru di semua "jika mode ==" di semua kode saya?

Sekarang bandingkan keburukan di atas, dengan rangkaian C ++ structs dan fungsi templat ini:

  struct CommonPixelData {
      int x;
  };
  struct AmbientPixelData : CommonPixelData {
      float ambientLight;
  };
  struct GouraudPixelData : CommonPixelData {
      float red;
      float green;
      float blue;  // The RGB color interpolated per pixel
  };
  struct PhongPixelData : CommonPixelData {
      float nX;
      float nY;
      float nZ; // The normal vector interpolated per pixel
  };

  template <class PixelData>
  RasterizeTriangleScanline(
      PixelData left,
      PixelData right)
  {
      PixelData interpolated = left;
      PixelData step = right;
      step -= left;
      step /= int(right.x - left.x); // divide by pixel span
      for(int i=left.x; i<right.x; i++) {
          WorkOnPixel<PixelData>(interpolated);
          interpolated += step;
      }
  }

Sekarang lihat ini. Kami tidak lagi membuat sup jenis persatuan: kami memiliki jenis khusus per setiap mode. Mereka menggunakan kembali barang-barang umum mereka (bidang "x") dengan mewarisi dari kelas dasar ( CommonPixelData). Dan templatnya membuat kompilator MENCIPTAKAN (yaitu, menghasilkan kode) tiga fungsi berbeda yang akan kita tulis sendiri dalam C, tetapi pada saat yang sama, menjadi sangat ketat tentang jenisnya!

Perulangan kami di templat tidak dapat membuang waktu dan mengakses bidang yang tidak valid - kompiler akan menggonggong jika kami melakukannya.

Template melakukan pekerjaan umum (loop, meningkat dengan "langkah" di setiap waktu), dan dapat melakukannya dengan cara yang TIDAK BISA menyebabkan kesalahan runtime. Interpolasi per jenis ( AmbientPixelData, GouraudPixelData, PhongPixelData) dilakukan dengan operator+=()yang kita akan menambahkan dalam struct - yang pada dasarnya menentukan bagaimana masing-masing jenis interpolasi.

Dan apakah Anda melihat apa yang kami lakukan dengan WorkOnPixel <T>? Kami ingin melakukan pekerjaan yang berbeda per jenis? Kami cukup memanggil spesialisasi templat:

void WorkOnPixel<AmbientPixelData>(AmbientPixelData& p)
{
    // use the p.ambientLight field
}


void WorkOnPixel<GouraudPixelData>(GouraudPixelData& p)
{
    // use the p.red/green/blue fields
}

Artinya - fungsi untuk memanggil, diputuskan berdasarkan jenisnya. Pada waktu kompilasi!

Untuk mengulanginya lagi:

  1. kami meminimalkan kode (melalui templat), menggunakan kembali bagian-bagian umum,
  2. kami tidak menggunakan hacks jelek, kami menjaga sistem tipe ketat, sehingga kompiler dapat memeriksa kami setiap saat.
  3. dan yang terbaik: tidak ada yang kami lakukan yang memiliki dampak runtime APA PUN. Kode ini akan berjalan HANYA secepat kode C yang setara - pada kenyataannya, jika kode C menggunakan pointer fungsi untuk memanggil berbagai WorkOnPixelversi, kode C ++ akan LEBIH CEPAT daripada C, karena kompiler akan menyejajarkan WorkOnPixelspesialisasi templat jenis-spesifik panggilan!

Lebih sedikit kode, tidak ada overhead run-time, lebih aman.

Apakah ini berarti bahwa C ++ adalah bahasa be-all dan end-all? Tentu saja tidak. Anda masih harus mengukur trade-off. Orang yang bodoh akan menggunakan C ++ ketika mereka seharusnya menulis skrip Bash / Perl / Python. Pemula-senang C ++ pemula akan membuat kelas bersarang mendalam dengan beberapa warisan virtual sebelum Anda dapat menghentikan mereka dan mengirim mereka berkemas. Mereka akan menggunakan meta-pemrograman Boost yang kompleks sebelum menyadari bahwa ini tidak perlu. Mereka akan MASIH menggunakan char*, strcmpdan makro, bukan std::stringdan template.

Tapi ini tidak lebih dari ... awasi dengan siapa kamu bekerja. Tidak ada bahasa untuk melindungi Anda dari pengguna yang tidak kompeten (tidak, bahkan Java).

Terus belajar dan menggunakan C ++ - hanya saja jangan overdesign.


18
+1 untuk "tidak, bahkan bukan Java" :)
Nathan Osman

53
+1 sebagai contoh. Itu adalah posting yang panjang, tetapi perbandingan antara kode C dan C ++ mengesankan.
paercebal

Dan ini, saudara-saudara, itulah sebabnya lex / yacc ada. Alasan yang sama, saya tidak pernah menyadari bagian dari c ++ jatuh ke filosofi generasi kode yang sama. Saya harus melihatnya lagi kapan-kapan.
Spencer Rathbun

2
Saya telah menulis banyak kode rendering 2D (lebih dari satu dekade yang lalu), dan mengalami masalah ini saat porting dari C ke C ++: bagaimana Anda mendefinisikan sebuah pixel struct, jika scanline Anda terbuat dari 1-bit piksel (8 piksel dalam satu byte)? Dan ketika scanline Anda terbuat dari R, G dan B byte (3 byte per piksel)? Dan ketika Anda memiliki tiga buffer terpisah untuk R, G dan B? Anda tahu jawabannya: C ++ tidak membantu di sana, dan bersikeras menggunakan templat akan membuat Anda kehilangan banyak ruang dan waktu optimasi
Walter Tross

Mengapa Anda menggunakan templat di C ++ untuk ini? Metode Anda mendeklarasikan parameter dari kelas dasar sehingga dari sudut pandang [C # programmer] saya sepertinya Anda bisa mengirimkan turunan tipe turunan ke parameter tipe-dasar. Saya tidak tahu C ++, bisakah Anda menjelaskannya?
Vlad

79

RAII untuk bayi yang menang.

Serius, kehancuran deterministik dalam C ++ membuat kode lebih jelas dan lebih aman tanpa overhead sama sekali.


20
"C ++: Satu-satunya pilihan deterministik serius . Tanyakan kepada dokter Anda tentang hal itu hari ini."
Kyle Strand

2
Tindak lanjut: Rust sekarang menjadi pesaing di bidang ini. Lihat contoh RAII dasar dan dokumentasi tentang metode destruktor Rust .
Kyle Strand

1
C akan sama deterministiknya, tetapi membutuhkan lebih banyak kerja untuk memastikan hal itu benar-benar terjadi ketika menggunakan memori malloc-ed
Baldrickk

1
@Brickrickk di C Anda harus menulis kode pembersihan di mana pun Anda menggunakan sumber daya. Dalam C ++, Anda menulisnya sekali , dalam definisi sumber daya. Baik C dan Java menderita bug "sumber daya yang digunakan setelah dibuang" dan "sumber daya bocor", karena pembersihan tidak otomatis . Memori bukan satu-satunya sumber daya.
Caleth

70

Apakah ada alasan yang memuaskan untuk menggunakan C ++?

  1. Templat dan STL. Anda menukar sedikit waktu pembuatan (dan beberapa pesan kesalahan yang berpotensi tidak dapat dipahami) dengan banyak abstraksi yang berguna dan alat hemat tenaga kerja, tanpa hit performa run-time yang lumayan (meskipun jejak biner mungkin sedikit lebih besar).

    Butuh beberapa saat untuk membungkus kepala Anda (butuh saya beberapa tahun sebelum diklik), tetapi begitu Anda melakukannya dapat membuat hidup jauh lebih sederhana.

  2. Pemrosesan teks dalam C ++ adalah urutan besarnya kurang menyakitkan daripada di C.


35
+1 untuk pemrosesan teks, yang saya benar-benar lupa dalam jawaban saya.
Konrad Rudolph

8
Heh saya menemukan pemrosesan teks yang menyakitkan dibandingkan dengan katakanlah Python ..
Nils

7
Boost adalah satu-satunya alasan saya masih menggunakan C ++.
Ferruccio

33
@Nils: Pada skala 1 hingga menyakitkan, pemrosesan teks dalam C ++ jelas lebih buruk daripada dalam bahasa yang lebih modern seperti Python. Hanya saja pemrosesan teks di C mendefinisikan pain-in-the-ass. Jika pilihannya adalah antara C dan C ++ untuk aplikasi tertentu, maka C ++ menang dengan mudah.
John Bode

8
Saya tidak tahu mengapa orang mengalami kesulitan dengan hal-hal seperti pemrosesan teks di C / C ++. Cukup gunakan perpustakaan atau tulis sendiri. Setelah Anda menulis fungsi level rendah (nyeri satu kali), Anda mendapatkan kinerja yang luar biasa, kode yang ketat, dan fleksibilitas yang lebih besar. Ya, saya akan menggunakan Python untuk utilitas baris perintah cepat / kotor tetapi untuk kode produksi serius C / C ++.

41

Iya.

Jika Anda mencari efisiensi yang dapat dieksekusi, Anda turun ke C atau C ++, jadi saya akan fokus pada hal itu.

Bahkan sebelum template umum, saya lebih suka menggunakan C ++ daripada C untuk jenis executable yang Anda bahas pada awal 1990-an karena dua alasan yang sangat sederhana: objek polimorfisme dan RAII .

Saya telah menggunakan objek C ++ polimorfik untuk semua jenis hal menarik. Sebagai contoh, saya sedang mengerjakan sistem Linux tertanam dengan overlay frame buffer pada OMAP dan XScale ARM CPU. Kedua arsitektur perangkat keras memiliki fitur overlay yang berbeda dengan API yang sangat berbeda. Saya menggunakan kelas dasar "Overlay" virtual umum untuk mengekspos tampilan overlay yang diidealkan, dan kemudian menulis kelas "OmapOverlay" dan "XScaleOverlay" yang dipakai secara tepat saat runtime, tergantung pada arsitektur mana kode yang terdeteksi menjalankannya.

Untuk menyederhanakan terlalu banyak, RAII adalah gagasan bahwa Anda mengalokasikan sumber daya yang terhubung ke objek selama konstruktor objek, atau mungkin nanti dalam masa hidup objek, dan sumber daya mendapatkan deallocated atau dirilis dalam destruktor objek. Itu sangat bagus di C ++, karena objek yang merupakan variabel otomatis dihancurkan ketika mereka keluar dari ruang lingkup. Untuk seseorang yang sama kompeten dalam C dan C ++, jauh lebih mudah untuk menghindari kebocoran sumber daya dan memori di C ++. Anda juga tidak melihat banyak kode C ++ dengan meme C yang sangat umum dari sebuah label di akhir fungsi yang mendahului sekelompok panggilan free(), dan berbagai gotoblok fungsi melompat di sana.

Saya sepenuhnya sadar bahwa Anda dapat melakukan semua hal ini dengan C - hanya saja lebih banyak pekerjaan, lebih banyak baris kode, dan apa yang Anda dapatkan jauh lebih jelek dan seringkali lebih sulit untuk dipahami. Ada kode polimorfisme di seluruh internal server X , dan man, apakah itu jelek dan aneh dan sering sulit dilacak.

Saya juga melakukan banyak pekerjaan dengan teknologi GNOME seperti GTK + dan Clutter, yang semuanya ditulis dalam C menggunakan sistem GObject. GObject seperti sistem objek C ++ dengan penutup yang bagus dilepas dan semua internal yang jelek terbuka, dan biasanya membutuhkan setengah lusin baris kode untuk melakukan apa yang akan dilakukan pemanggilan metode C ++ satu baris. Saat ini saya sedang menulis beberapa ClutterActors, dan sementara matematika benar-benar menarik, saya terus-menerus berpikir, "Ini semua akan menjadi jauh lebih ringkas dan mudah dipahami dalam C ++".

Saya juga sering berpikir, "Anda tahu, jika saya menulis ini dalam C ++ bukannya C, saya akan keluar di ruang tamu menonton MythBusters bersama istri saya alih-alih duduk di kantor saya pada jam 9 malam."


9
Saya benar-benar dapat berhubungan dengan apa yang Anda katakan di sini, terutama 1) poin tentang RAII dan 2) pemikiran "Anda tahu, jika saya menulis ini dalam C ++, bukan C ..." Saya melakukan banyak pengembangan sistem embedded , dan bahkan jika tim adalah jenis toko "C" atau "C dengan kelas", saya benar-benar mencoba untuk mendorong RAII untuk hal-hal seperti manipulasi interupsi, operasi mutex dan pelacakan / logging (terutama hal-hal seperti toggling I / O baris). Dan deskripsi Anda tentang buffer bingkai polimorfik mengingatkan saya pada penggunaan buffer pesan polimorfik dalam sistem terdistribusi.
Radian

29

C ++ hampir secepat C (beberapa hal lebih cepat, beberapa lebih lambat), dan ia menawarkan abstraksi dan organisasi yang lebih baik. Kelas bekerja sama dengan tipe primitif, memungkinkan sejumlah besar kode untuk digunakan tanpa dipikirkan. Overloading dan template operator memungkinkan untuk menulis kode yang berfungsi lebih baik jika representasi data berubah. Pengecualian dapat memungkinkan penanganan kesalahan yang lebih mudah. Kompiler dapat digunakan untuk memeriksa lebih banyak barang pada waktu kompilasi.

Harga yang Anda bayar untuk ini adalah kurva belajar yang cukup buruk, dan lebih mudah untuk membuat kesalahan halus di dalamnya daripada kebanyakan bahasa lain yang saya kenal.

Jadi, saya tidak tahu apakah akan bermanfaat bagi Anda untuk mempelajarinya untuk apa yang Anda lakukan sekarang. Anda tentu dapat bertahan dengan kombinasi Python atau Perl dan C, tetapi C ++ menawarkan abstraksi dan kinerja dalam satu paket yang sulit digunakan.


13
Tidak ada kasus di mana C ++ lebih lambat dari C karena Anda selalu dapat menggunakan cara C jika lebih cepat (dan Anda peduli).
Jack Aidley

1
@JackAidley - Kecuali bahwa C ++ tidak mendukung parameter array membatasi dan statis. Dan kecuali bahwa menggunakan gaya C ++ di satu tempat memaksa Anda untuk menggunakannya di tempat lain.
martinkunev

@martinkunev restrictdigunakan untuk membuat pengecualian dari optimasi alias , jadi bagaimana hal itu membantu membuat segalanya lebih cepat ? dan apa yang dimaksud dengan "parameter array statis"? dan bagaimana "gaya" mempengaruhi kinerja?
underscore_d

1
@underscore_d membatasi izin pengoptimalan, berdasarkan jaminan untuk non-aliasing; parameter array statis membiarkan kompiler berasumsi bahwa argumen pointer bukan NULL dan bahwa pointer ini menunjuk setidaknya sejumlah elemen; kata "style" memiliki beberapa makna dan mengeluarkannya dari konteks mengubah artinya - saya berbicara tentang bagaimana, misalnya, pengecualian menegakkan penggunaan pointer cerdas.
martinkunev

1
@martinkunev Hmm, jadi saya bertanya-tanya apakah parameter array statis memungkinkan sesuatu yang berbeda secara fungsional dari template C ++ menggunakan T (&arr)[n]atau std::array<T, n>- harus meneliti yang ini lagi, karena tidak ada banyak info di luar sana. Itu masuk akal tentang pointer cerdas, jelas contoh yang bagus. Jika pengkodean pada bidang bermain yang sama, kami tidak akan menggunakan pengecualian, jadi tidak ada biaya potensial yang akan dikeluarkan ... namun saya menduga Anda mungkin menyinggung bagaimana, begitu perpustakaan pihak ketiga memasukkan gambar, banyak asumsi beresiko.
underscore_d

27

Saya menganggap C ++ sebagai bahasa tahun 1990-an, bahasa di masa lalu.

Saat itu besar karena menawarkan konstruksi dan mekanisme bahasa tingkat tinggi dengan biaya yang lebih rendah dalam hal kinerja. Itu adalah alat universal untuk mengembangkan segala sesuatu dari aplikasi buku alamat hingga perangkat lunak avionik, dan yang mengilhami kegilaan OO. OOP mengatasi kelaparan dan AIDS, dan ya, saya menyalahkan C ++ karena mencoba mencuci otak saya pada akhir 1990-an ketika saya pertama kali memulai pemrograman bahwa bahasa non-OO tidak layak dipelajari.

Sekarang perangkat keras telah maju begitu banyak dan lebih baru, bahasa modern telah muncul, saya gagal melihat C ++ tetap menjadi pilihan yang relevan untuk sebagian besar pemrograman aplikasi kecuali untuk perangkat lunak intensif komputasi di mana Anda masih memerlukan beberapa abstraksi (permainan, simulasi fisika, sistem CAD, dll. ). Bahkan yang terakhir dapat dihindari jika Anda menulis mesin modular yang ringkas dalam C dan memiliki logika aplikasi tingkat tinggi yang didelegasikan ke bahasa skrip yang rapi.

Jika Anda perlu beralih ke penggunaan logam C secara sehat, dan ketika Anda harus naik tingkat tinggi, lakukanlah dalam bahasa modern yang tidak mengiklankan enkapsulasi sementara Anda dapat dengan bebas mengubah setiap byte melalui pointer.


11
Jadi jangan mengubah byte acak menggunakan pointer. Itu tidak begitu sulit untuk dihindari, bukan?
David Thornley

11
@ Blagovest: Saya setuju dengan Anda tentang kompleksitas C ++ dan saya tidak akan pernah menggunakannya untuk mengganti bahasa berorientasi objek. Tetapi terlepas dari kerumitannya, ia masih menang atas C untuk saya karena banyak keuntungannya dijabarkan dalam jawaban yang berbeda (abstraksi, penyerahan sumber daya, penanganan string ...). Bahkan, Anda telah menyebutkan beberapa area yang valid di mana C ++ masih relevan, dan di mana itu jauh lebih unggul dari C.
Konrad Rudolph

6
@Blagovest: Itu sebabnya saya tetap berada di luar sudut gelap. Lebih mudah untuk dirampok di sana di C ++ daripada bahasa lain yang saya tahu. Dengan menggunakannya, saya mendapat manfaat dari RAII, penanganan string yang jauh lebih baik daripada C, kelas templat tipe STL, fitur OO, dan keunggulan lain yang dimiliki lebih dari C.
David Thornley

24
@ Blagovest: Tidak, tidak. Misalnya, apa yang Anda sebutkan tidak cukup untuk mencapai RAII, dan kelas wadah memiliki fungsionalitas yang melampaui struktur data kerajinan tangan yang sederhana. Jika Anda pikir itu mungkin, Anda tidak pernah belajar C ++ dengan baik.
David Thornley

5
@ Jamesar Saya gagal melihat mengapa mesin multi-core akan menempatkan OOP ke kubur. Jika yang Anda maksud C ++, saya bisa melihat dari mana Anda berasal. OOP adalah konsep dasar dalam banyak bahasa pemrograman modern, terutama bahasa tingkat tinggi. Bahkan C bisa menjadi OO, jika Anda memprogramnya seperti itu. Hanya saja tidak senyaman C ++ IMO.
vedosity

21

Menurut Linus , tidak ada:

Ketika saya pertama kali melihat kode sumber Git dua hal yang menurut saya aneh: 1. C murni sebagai lawan C ++. Tidak tahu kenapa. Tolong jangan bicara tentang portabilitas, ini BS.

ANDA penuh dengan omong kosong.

C ++ adalah bahasa yang mengerikan. Itu dibuat lebih mengerikan oleh fakta bahwa banyak programmer di bawah standar menggunakannya, ke titik di mana jauh lebih mudah untuk menghasilkan total dan mengucapkan omong kosong dengannya. Sejujurnya, bahkan jika pilihan C tidak melakukan apa - apa selain mengusir programmer C ++, itu sendiri akan menjadi alasan besar untuk menggunakan C.

Dengan kata lain: pilihan C adalah satu-satunya pilihan yang waras. Aku tahu Miles Bader dengan bercanda berkata "untuk membuatmu kesal", tapi itu benar. Saya sampai pada kesimpulan bahwa setiap programmer yang lebih suka proyek berada di C ++ lebih dari C kemungkinan seorang programmer yang saya benar - benar lebih suka kencing, sehingga dia tidak datang dan mengacaukan proyek apa pun yang saya terlibat dengan.

C ++ mengarah ke pilihan desain yang benar-benar buruk. Anda selalu mulai menggunakan fitur perpustakaan "bagus" dari bahasa seperti STL dan Boost dan omong kosong total dan total lainnya, yang mungkin "membantu" program Anda, tetapi menyebabkan:

  • jumlah rasa sakit yang tak terbatas ketika mereka tidak bekerja (dan siapa pun yang mengatakan kepada saya bahwa STL dan terutama Meningkatkan stabil dan portabel begitu penuh dengan BS yang bahkan tidak lucu)

  • model pemrograman abstrak yang tidak efisien di mana dua tahun kemudian Anda melihat bahwa beberapa abstraksi tidak terlalu efisien, tetapi sekarang semua kode Anda tergantung pada semua model objek yang bagus di sekitarnya, dan Anda tidak dapat memperbaikinya tanpa menulis ulang aplikasi Anda.

Dengan kata lain, satu-satunya cara untuk melakukan yang baik, efisien, dan tingkat sistem dan portabel C ++ berakhir dengan membatasi diri Anda untuk semua hal yang pada dasarnya tersedia dalam C. Dan membatasi proyek Anda ke C berarti bahwa orang tidak mengacaukannya , dan juga berarti bahwa Anda mendapatkan banyak programmer yang benar-benar memahami masalah tingkat rendah dan tidak mengacaukan segalanya dengan omong kosong "model objek" bodoh.

Jadi saya minta maaf, tetapi untuk sesuatu seperti git, di mana efisiensi adalah tujuan utama, "kelebihan" C ++ hanyalah kesalahan besar. Fakta bahwa kita juga membuat marah orang yang tidak bisa melihat itu hanyalah keuntungan tambahan yang besar.

Jika Anda ingin VCS yang ditulis dalam C ++, mainkan dengan Monoton. Benarkah. Mereka menggunakan "database nyata". Mereka menggunakan "pustaka berorientasi objek yang bagus". Mereka menggunakan "abstraksi C ++ bagus". Dan sejujurnya, sebagai hasil dari semua keputusan desain ini yang terdengar begitu menarik bagi beberapa orang CS, hasil akhirnya adalah kekacauan yang mengerikan dan tidak dapat dipertahankan.

Tapi saya yakin Anda lebih menyukainya daripada git.

      Linus

62
Saya tidak berpikir Linus harus menjadi orang untuk pergi ke argumen di sini. Kata-kata kasarnya sangat subyektif dan tidak dewasa. Dia sebenarnya memiliki beberapa poin bagus tetapi mereka sangat terkubur (di bawah "omong kosong" serta omong kosong) sehingga mereka sangat sulit ditemukan.
Konrad Rudolph

19
Haha, itu adalah tawa yang bagus. Saya tidak pernah ingin bertemu dengan pria ini.
Felix Dombek

30
Linus mengingatkan saya pada seorang roofer yang sangat berbakat yang tidak pernah menggantung sheetrock, tetapi memanggil pansies sheetrock guys karena mereka menggunakan sekrup bukan paku.
Bob Murphy

8
Linus ada benarnya tetapi mengungkapkannya terlalu keras untuk dianggap serius.
Blagovest Buyukliev

39
Saya setuju dengan @Daniel, Jika ada seseorang yang dapat berbicara tentang mendorong batas perangkat keras adalah John Carmack pencipta malapetaka, gempa dan permainan lainnya dan pendiri perangkat lunak Id. Dia menulis ini tentang c dan c ++ pada twitt beberapa bulan yang lalu: "IMO, kode C ++ yang baik lebih baik daripada kode C yang baik, tetapi C ++ yang buruk bisa jauh, jauh lebih buruk daripada kode C yang buruk." twitter.com/#!/ID_AA_Carmack/status/26560399301
Onema

18

Saya tidak berpikir ada alasan kuat untuk menggunakan C ++. Jika Anda ingin melakukan pemrograman OO, Anda dapat menggunakan Python dan menulis bagian-bagian yang membutuhkan kinerja cepat dalam C.

EDIT: Ada bahasa lain yang berinteraksi dengan baik dengan C, jadi jika Anda tidak suka Python, ada alternatif.


3
Bagaimana dengan pengembangan yang disematkan? Python tidak selalu tersedia, dan perbedaan kecepatan antara C dan C ++ yang ditulis dengan baik dapat diabaikan pada perangkat yang melewati tingkat kekuatan pemrosesan tertentu. Tentu saja, saya kira kompiler C ++ tidak akan selalu tersedia juga ...
James

6
@ James "ditulis dengan baik C ++" - ada tangkapannya :(
dss539

5
Saya setuju dengan jawaban ini, lakukan level tinggi dengan python, karena Anda akan menuliskannya sekitar 3 kali lebih cepat, profil, dan kemudian lepaskan kemacetan dengan menggantinya dengan C / C ++. Itu berlebihan untuk mengatakan "ganti bottleneck dengan kode C ++" karena Anda tidak akan melakukan level tinggi dengan kode yang Anda butuhkan untuk menjadi cepat, karena itu akan menjadi kode level rendah. Ada satu hal: saya tidak tahu cara antarmuka c ++ dengan python: /. tetapi dalam hal waktu yang dihabiskan di depan layar dan efisiensi, saya pikir itu solusi terbaik, karena sebagian besar kode C ++ akan cepat untuk apa-apa!
jokoon

8
Pergi bekerja untuk perusahaan keuangan besar dan membangun sistem keuangan yang rumit dalam tim besar yang didistribusikan dengan Python dan lihat bagaimana Anda menyukainya. Pengalaman akan mengajarkan Anda: a) keuntungan dari keamanan tipe, b) keuntungan dari kompiler menghemat pantat Anda, c) kode LUDICROUS yang Python memungkinkan noobs untuk menulis. Orang-orang mengatakan bahwa menembak kaki Anda dengan C ++ -> beberapa hal python bisa dilakukan dengan mudah tetapi menjadi gila batas. Saat ini saya lebih suka bekerja di C ++ ...
MrFox

1
@suslik: Wow, saya terkejut bahwa ada orang yang benar-benar akan menggunakan python untuk sistem semacam itu. Saya setuju dengan Anda tentang kode python noob yang buruk; Saya sudah melihat sendiri.
Larry Coleman

13

Apakah ada alasan untuk menggunakan C ++? Pasti.

Beberapa orang mungkin lebih suka menggunakan C ++ daripada opsi lain. Bertanya apakah ada alasan untuk menggunakan C ++ sama seperti bertanya mengapa kita perlu memiliki ratusan rasa es krim. Tidak semua orang suka bertahan dengan Vanilla.

Jika pengembang sudah sangat kompeten dengan C ++, pertanyaan bagi mereka mungkin bukan 'mengapa menggunakannya?', Melainkan 'mengapa tidak?'. Tampaknya ada hal anti-C ++ yang trendi ini terjadi di SO sekarang, tetapi percaya atau tidak, tidak semua orang berlangganan itu. Beberapa orang mungkin hanya menyukai C ++ lebih baik daripada bahasa lain.

Apakah C ++ perlu digunakan untuk aplikasi? Tentu saja tidak. Tetapi pertanyaan yang persis sama ini juga bisa ditanyakan untuk bahasa lain. Ada sangat, sangat sedikit kasus di mana bahasa tertentu perlu digunakan untuk aplikasi.


12

Saya hanya beralih dari C ke C ++, dan saya pikir keuntungannya cukup besar, bahkan jika Anda tidak membutuhkan template dan OOP.

  • Manajemen memori yang lebih baik
  • Sistem tipe yang lebih kuat
  • Perpustakaan standar yang lebih baik
  • Ruang nama
  • dll.

8

Saya terkejut belum ada yang menyebutkan hal ini, tetapi C ++ memperkenalkan kami pada referensi , yang hampir menyelesaikan semua masalah dan perangkap dari pointer:

void ModifyVar(int& var)
{
    var = 5;
}

int test = 4;
ModifyVar(test);

Dari pada:

void ModifyVar(int * var)
{
    *var = 5;
}

int test = 4;
ModifyVar(&test);

Jauh lebih aman dan lebih mudah juga ... dan tanpa biaya tambahan.


3
Juga jauh kurang fleksibel. Referensi (gaya C ++) bagus dalam menyederhanakan konstruksi umum tertentu dalam bahasa yang juga memiliki pointer, tetapi mereka jauh dari menjadi pengganti pointer, bahkan tidak lucu. Dan contoh Anda sama sekali bukan kasus yang bagus untuk referensi.
Ben Voigt

3
@ Ben: Lalu bisakah Anda menjelaskan mengapa ini contoh yang buruk?
Nathan Osman

6
@ George: Karena tidak ada yang berubah, kecuali itu dua (hitung) karakter lebih pendek? Itu tidak menyelesaikan masalah, tidak menyoroti jebakan, bahkan tidak melakukan hal-hal keren seperti memperpanjang masa pakai variabel sementara (yang referensi bagus).
Ben Voigt

@ Ben: Anda lupa sesuatu - referensi selalu valid. Pointer dapat menunjuk ke apa saja (termasuk NULL) yang dapat menyebabkan semua jenis kesalahan memori jika semuanya tidak dilakukan dengan benar. Referensi tidak pernah bisa NULL dan alamat yang mereka tuju tidak pernah bisa diubah.
Nathan Osman

5
@ George: "referensi selalu valid" benar-benar salah. Saya akan memberikan contoh jika Anda membutuhkannya, tetapi saya berharap Anda cukup ahli untuk mengetahui hal ini. Dan saya juga tidak berbicara tentang membentuk referensi yang tidak valid menggunakan pointer yang tidak valid. Fungsi yang menggunakan pointer memerlukan dokumentasi yang menyatakan prasyarat pada argumen. Namun secara praktis, semua fungsi memerlukan tingkat dokumentasi tersebut, jadi tidak masuk akal untuk menyebut bahwa sebuah serangan terhadap pointer.
Ben Voigt

5

Di mana dan mengapa biasanya akan menjadi:

  • keakraban
  • fitur bahasa yang diinginkan
  • perpustakaan tertentu yang ingin Anda gunakan
  • persyaratan kinerja

Untuk pemrograman sisi server Anda sering dapat memilih dari berbagai bahasa yang berbeda, dikompilasi atau ditafsirkan. Biasanya pilihan bahasa didorong oleh platform yang paling efektif bagi Anda atau tim Anda. Atau jika Anda belum memiliki tim, ketersediaan keterampilan di pasar.

Di samping catatan saya tidak begitu mengerti memutuskan untuk menggunakan C / C ++ berdasarkan kinerja (hanya) karena banyak bahasa skrip dapat diperluas dengan C / C ++. Anda mendapatkan manfaat dari bahasa pengembangan cepat ditambah dengan kemampuan untuk memigrasi bagian lambat ke ekstensi C / C ++. Tentu saja jika Anda melakukan pemrograman sistem di mana setiap ops menghitung itu bisa dimengerti, tetapi dalam sebagian besar pengembangan aplikasi saya tidak mengerti.


2
Keakraban adalah alasan nomor 1, dan saya terkejut Anda yang pertama menyebutkannya.
Paul Butcher

4

C ++ vs Python vs Perl tidak bisa dinilai dengan mudah. Itu tergantung pada proyek dan persyaratan.

C ++ memiliki gudang utilitas sejak lama, berjalan di banyak platform. Tapi itu menyakitkan untuk mulai berjalan melalui stream untuk hanya melewati String ke Integer dan mundur.

C ++ di sisi lain, memiliki banyak sekali ketergantungan pada perpustakaan. Setelah Anda mengompilasi sesuatu di GCC X atau VC ++ Y, maka Anda tidak dapat mengandalkan bahwa kode akan dijalankan oleh versi berikutnya dari alat-alat itu. Neraka yang sama ada di Windows, neraka yang sama juga ada di Unix.

Perl, mengambil kekuatannya dari dunia Unix tetapi terutama sebagai alat ekspresi reguler. Inilah yang paling sering digunakan. Bersamaan dengan beberapa alat yang cukup serius yang bahkan Java tidak dapat melakukannya dengan cara biasa (lihat cara mengunggah file ke server web), Perl adalah "lakukan saja".

Python mudah, fleksibel, dan bahasa yang dinamis. Sangat mudah bahwa Anda dapat mengirim integer ke suatu fungsi, skrip mengharapkan string, namun Anda dapat memperoleh hasilnya! Meskipun tidak terduga, tetapi hasilnya. Jadi programmer harus sangat berhati-hati. IDLE menawarkan beberapa debugging, tetapi ketika Anda memiliki TELNET ke suatu sistem, atau SSH di tiga tingkat ke bawah dan Anda ingin menemukan masalah Anda, debugger tidak akan ada di sana untuk berdiri di samping Anda. Tapi, itu bisa melakukan beberapa pekerjaan matematika dengan cepat.

Java adalah ekosistem kata kunci, teknologi asing, dan kata-kata besar dan ketika Anda hanya ingin mengunggah file ke server web, Anda dapat melakukannya hanya jika server memiliki JSP . Jika Anda ingin memanggil pustaka sistem atau fungsi-fungsi sistem seperti pemantauan, Anda harus banyak menggali. Dan mungkin untuk mencapai JNI dan OK ... Anda berpikir kemudian ... "Kenapa, Tuhan?"

Terlepas dari itu, Java adalah alat yang hebat untuk suite bisnis, dan multithreading, saya sangat menyukainya.

Cepat membuat program dan menunjukkan ke CV Anda "Oh, saya tahu teknologi itu juga" dan bos Anda yang ingin menjadi, kagum! Meskipun demikian, teknologinya mungkin tidak terlalu dibutuhkan ... (Oke, teman-teman, saya benci Spring Framework ....)


1
Sayangnya, Anda harus mempertimbangkan bahwa Python memiliki dependensi versi - terutama setelah Anda bermigrasi ke Python 3, sama dengan perl .. atau adakah yang mau repot-repot pindah ke Perl 6? Semuanya memiliki dependensi buruk :(
gbjbaanb

3

Hal yang perlu diingat saat memilih bahasa, adalah manfaat apa yang akan Anda dapatkan dari menggunakannya, dan berapa lama untuk mendapatkannya.

Ide utama antara bahasa seperti python dan perl adalah melakukan lebih banyak dengan lebih sedikit waktu kerja, tetapi dengan lebih banyak waktu cpu. Sebenarnya Anda akan menghabiskan lebih banyak waktu coding skrip python atau perl daripada yang akan dieksekusi, tetapi Anda mengerti maksud saya.

Keuntungan C / C ++ adalah mereka cepat, tetapi dengan biaya sintaks dan pengetikan yang kuat: Anda harus melakukan banyak hal sendiri sehingga komputer tidak harus memilihnya pada waktu kompilasi.

Ketika Anda membuat kode, beberapa baris akan dijalankan lebih banyak daripada yang lain, dan baris-baris itu yang menimbulkan masalah. Di sisi lain, semua sisa kode, kode yang banyak Anda habiskan, dieksekusi lebih jarang. Anda mungkin pernah mendengarnya, tetapi itu adalah aturan 80/20 yang terkenal, dan Anda tidak akan dapat mem-bypass aturan tersebut.

Solusi untuk masalah ini, adalah dengan menggunakan bahasa yang lebih mudah (maksud saya lebih mudah lebih ramah pengembang: kurang mengetik, interpretasi malas, banyak rutin dan hal-hal yang sudah ada sebelumnya, dll) untuk melakukan semua kode Anda.

Anda akan melakukannya dengan sangat cepat dibandingkan dengan jika Anda melakukannya dengan C atau C ++, itu akan membutuhkan lebih banyak sakit otak.

Program Anda akan lambat, tetapi dengan profiler, Anda mengisolasi bagian yang berjalan 80% dari waktu, dan Anda melakukannya dengan C atau C ++.

Dengan prorgamming cara ini, Anda menghemat banyak waktu, dan program Anda seefisien, secepat, memiliki lebih sedikit peluang untuk membocorkan memori, dan Anda menghemat waktu.

Bahasa skrip dirancang untuk berada di sisi pengembang, tetapi pengoptimalan masih dimungkinkan. Tentu saja Anda bisa menjadi penyihir pola desain atau voodoo STL atau bahkan seorang prajurit kacangan, dan mungkin seorang biksu haskell. Tetapi bahasa membuat kita berbicara dengan komputer, bahasa tidak dibuat untuk kita MENJADI komputer!



2

C ++ yang saya gunakan disebut C dengan kelas!


8
Hore, Anda menggunakan kata kunci 'kelas'. Sekarang Anda mengerti desain OO!
dss539

C ++ saya disebut C dengan namespaces.
jsz

6
C ++ saya disebut, umm .. Manoj's C ++.
Manoj R

+1 Kelas itu satu-satunya alasan mengapa saya menggunakan C ++.
mbq

... ok, juga pengecualian.
mbq

0

Sebenarnya ada satu jawaban untuk semua pertanyaan yang terbentuk seperti ini. Alasan terbaik untuk menggunakan tech X daripada tech Y (di mana X dan Y kira-kira berada pada level yang sama [seperti hampir semua bahasa pemrograman kontemporer]) adalah karena Anda sudah tahu X dan tidak tahu Y.

(tapi setelah Haskell tiba, tidak ada alasan untuk menggunakan hal lain)


0

Tidak, tidak sama sekali. Jika Anda tidak membutuhkan kinerja dan ada perpustakaan Anda dapat menggunakan bahasa lain maka jangan repot-repot dengan C / C ++. Saya hanya melakukannya saat ini ketika saya menargetkan sistem tertanam yang tidak dapat (dengan mudah?) Menjalankan bahasa. Terkadang saya menggunakan C karena saya menulis sebuah plugin tetapi sebenarnya tidak.

Namun, saya tidak akan menggunakan Python, Perl, dll untuk menghindari penggunaan C. Preferensi saya sebenarnya adalah C #, karena saya suka perpustakaan yang bagus (yang merupakan kekuatan .NET), dan saya suka bahasa yang diketik secara statis. Boo adalah alternatif yang bagus. Tapi benar-benar Haskell , OCaml , D , ML dan semacamnya baik-baik saja.


7
Anda melewatkan intinya.
Matt Joiner

@Matt Joiner: Saya yakin saya belum. Apa yang saya lewatkan?

Pertanyaannya adalah tentang tidak menggunakan C ++.
Matt Joiner

@Matt Joiner: hmm, pada tampilan lain saya bisa melihat yang diminta. Tapi sepertinya saya jawab juga (saya bilang jangan repot-repot dan alternatif yang saya gunakan)

Saya hampir ingin
mengundurkan diri
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.