it-swarm-id.com

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

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 area ini telah ditulis dalam C, Perl, Python, Bash script, 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++?

166
Ehsan

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 yang biasa: fungsi virtual, pointer fungsi, dan idiom PIMPL. Semua ini bergantung pada tipuan yang pada saat runtime diselesaikan oleh pointer aritmatika. Dengan kata lain, itu menimbulkan biaya kinerja (betapapun kecilnya itu).

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

Pertimbangkan contoh fungsi sortir generik.

Di C, fungsi qsort mengambil pointer fungsi yang mengimplementasikan logika dengan mana elemen-elemen diurutkan relatif terhadap satu sama lain. Java's Arrays.sort fungsi hadir dalam beberapa varian; salah satunya mengurutkan objek sewenang-wenang dan membutuhkan objek Comparator diteruskan ke sana yang berfungsi seperti fungsi pointer di C _ qsort. Tetapi ada beberapa kelebihan untuk "pribumi" Java. Dan masing-masing dari mereka memiliki salinan sendiri dari metode sort - duplikasi kode yang mengerikan.

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

Dalam C++, fungsi sort bekerja sangat mirip qsort dalam C, dengan satu perbedaan kecil tapi mendasar: komparator yang diteruskan ke fungsi adalah templat parameter. Itu berarti bahwa panggilannya dapat sebaris . Tidak ada tipuan yang diperlukan untuk membandingkan dua objek. Dalam lingkaran yang ketat (seperti halnya di sini) ini sebenarnya dapat membuat perbedaan besar.

Tidak mengherankan, fungsi C++ sort mengungguli C _ sort bahkan 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 bersamaan sehingga Anda sering tidak perlu memilih antara kode yang efisien dan yang dapat digunakan kembali.

310
Konrad Rudolph

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 mengatakannya 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 dalam kode yang jauh lebih sedikit daripada C, tanpa biaya kecepatan runtime, sementara lebih aman (mis. menangkap lebih banyak kesalahan pada waktu kompilasi) daripada C.

Berikut ini contoh sederhana dari renderer 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 bayangan "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 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.green Dalam perhitungan "dgreen"? Kompiler pasti tidak memberi tahu Anda.

Lalu, ada pengulangan di mana-mana - loop for ada 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 set ini dari C + + struct dan fungsi template:

  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 templat 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 melakukan kesalahan 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 akan kita tambahkan dalam struct - yang pada dasarnya menentukan bagaimana setiap jenis diinterpolasi.

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 versi WorkOnPixel, kode C++ akan LEBIH CEPAT daripada C, karena kompiler akan inline panggilan spesialisasi templat spesifik-jenis WorkOnPixel!

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

Apakah ini berarti bahwa C++ adalah be-all dan end-all language? 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 kompleks Boost meta-pemrograman sebelum menyadari bahwa ini tidak perlu. Mereka akan MASIH menggunakan char*, strcmp dan makro, alih-alih std::string Dan templat.

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

Teruslah belajar dan menggunakan C++ - tapi jangan overdesign.

167
ttsiodras

RAII untuk bayi yang menang.

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

79
Motti

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 lot 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 sekali Anda melakukannya dapat membuat hidup menjadi banyak lebih sederhana.

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

70
John Bode

Ya.

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 diskusikan sejak pertengahan 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 yang tertanam dengan frame buffer overlay pada OMAP dan XScale ARM CPU. Kedua arsitektur perangkat keras memiliki fitur overlay yang berbeda dengan API yang sangat berbeda. Saya menggunakan virtual umum " Overlay "kelas dasar untuk mengekspos tampilan overlay yang ideal, dan kemudian menulis" OmapOverlay "dan" XScaleOverlay "kelas 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 benar-benar baik di C++, karena objek yang 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 sebelum sekelompok panggilan ke free(), dan berbagai goto ada di blok fungsi melompat ke 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 X server internal, 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 Nice 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 dengan istri saya alih-alih duduk di kantor saya pada jam 9 malam . "

41
Bob Murphy

C++ kira-kira 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.

29
David Thornley

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 mulai dari aplikasi buku alamat hingga perangkat lunak avionik, dan itu mengilhami kegemaran 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 sangat 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, CAD sistem, 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.

28

Menurut Linus , tidak:

Ketika saya pertama kali melihat kode sumber Git, dua hal mengejutkan saya: 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 adalah untuk melakukan tidak ada tetapi tetap keluar programmer C++, yang dengan sendirinya 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++ daripada C kemungkinan seorang programmer yang saya benar-benar akan lebih suka kencing off, sehingga dia tidak datang dan mengacaukan proyek yang saya terlibat.

C++ mengarah ke pilihan desain yang benar-benar buruk. Anda selalu mulai menggunakan fitur perpustakaan "Nice" 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 bergantung pada semua model objek Nice 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, "keuntungan" dari 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. Betulkah. Mereka menggunakan "database nyata". Mereka menggunakan "pustaka berorientasi objek yang bagus". Mereka menggunakan "abstraksi Nice C++". Dan sejujurnya, sebagai hasil dari semua keputusan desain ini yang terdengar sangat menarik bagi beberapa orang CS, hasil akhirnya adalah kekacauan yang mengerikan dan tidak dapat dipertahankan.

Tapi saya yakin Anda lebih menyukainya daripada git.

      Linus
21
Jeremy Heiler

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

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

18
Larry Coleman

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 menanyakan mengapa kita perlu memiliki ratusan rasa es krim. Tidak semua orang suka bertahan dengan Vanilla.

Jika pengembang sudah sangat kompeten dengan C++, pertanyaan untuk mereka mungkin bukan 'mengapa menggunakannya?', Melainkan 'mengapa tidak?'. Tampaknya ada trendi anti-C++ yang sedang trendi terjadi di SO sekarang, tapi percayalah atau tidak, tidak semua orang setuju dengan hal itu. Beberapa orang mungkin menyukai C++ lebih baik daripada bahasa lain.

Apakah C++ perlu untuk 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.

13
GrandmasterB

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.
12
Oliver Weiler

Saya terkejut belum ada yang menyebutkan ini, tetapi C++ memperkenalkan kami ke 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.

8
Nathan Osman

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 diinterpretasikan. 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.

5
dietbuddha

C++ vs Python vs Perl tidak dapat 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. Seiring dengan beberapa alat yang cukup serius yang bahkan Java tidak dapat melakukannya dengan cara normal (lihat cara mengunggah file ke server web), Perl adalah "lakukan saja".

Python mudah, fleksibel, dan bahasa yang dinamis. Sangat mudah sehingga 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'ed ke suatu sistem, atau SSH'ed di tiga tingkat ke bawah dan Anda ingin menemukan masalah Anda, debugger tidak akan ada di sana untuk berdiri di sebelah 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 pikir ... "Mengapa, Tuhan?"

Selain 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 ... (OK, teman-teman, saya benci Spring Framework ....)

4
hephestos

Linux? Bagaimana dengan "berorientasi objek Pascal" atau "D"?

Saran:

3
mramirez

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 untuk mengkode skrip python atau Perl daripada yang akan dieksekusi, tetapi Anda mengerti maksud saya.

Keuntungan dari 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 sering Anda habiskan, dieksekusi lebih jarang. Anda mungkin pernah mendengarnya, tetapi itu adalah aturan 80/20 yang terkenal, dan Anda tidak akan dapat mengabaikan 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 LISP, dan mungkin seorang biksu haskell. Tetapi bahasa membuat kita berbicara dengan komputer, bahasa tidak dibuat untuk kita MENJADI komputer!

3
jokoon

C++ yang saya gunakan disebut C dengan kelas!

2
willspeak

Tidak, tidak sama sekali. Jika Anda tidak memerlukan 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 embedded 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 baik. Tapi sungguh Haskell , OCaml , D , ML dan semuanya baik-baik saja.

0
user2528

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
vegai