it-swarm.dev

C, Perl, Python vb. Yerine C ++ kullanmak için herhangi bir neden var mı?

Linux (sunucu tarafı) geliştiricisi olarak nerede ve neden C++ kullanmalıyım bilmiyorum.

Performansa gittiğimde ilk ve son seçenek C.

"Performans" ana sorun olmadığında, Perl ve Python gibi programlama dilleri iyi seçimler olacaktır).

Bu alanda bildiğim hemen hemen tüm açık kaynak uygulamaları C, Perl, Python, Bash betiği, AWK veya hatta PHP'de yazılmış, ancak kimse C++ kullanmıyor .

GUI veya web uygulamaları gibi diğer alanları tartışmıyorum, sadece Linux, CLI ve artalanlardan bahsediyorum.

C++ kullanmak için tatmin edici bir neden var mı?

166
Ehsan

Performansa gittiğimde ilk ve son seçenek C.

Ve yedeklemeniz gereken yer burası. Şimdi, , sunucu gelişimi için konuşamam. Belki de C++ 'ı alternatiflere tercih etmek için gerçekten zorlayıcı bir neden yoktur.

Ancak genel olarak konuşursak, diğer dillerden ziyade C++ kullanmanın nedeni gerçekten performanstır. Bunun nedeni, C++ 'ın tüm bildiğim bildiğim diğer dillerin aksine bir soyutlama yöntemi sunmasıdır. çalışma zamanında ek yük yok.

Bu, hala çok yüksek bir soyutlama seviyesine sahip olan çok verimli bir kod yazmanıza izin verir.

Her zamanki soyutlamaları göz önünde bulundurun: sanal işlevler, işlev işaretçileri ve PIMPL deyimi. Bunların tümü, işaretçi aritmetiği tarafından çözülen çalışma zamanında indirime dayanır. Başka bir deyişle, bir performans maliyeti gerektirir (ancak bu küçük olabilir).

Öte yandan C++, no (performans) maliyeti: şablonlara neden olan bir dolaylı mekanizma sunar. (Bu avantaj, (bazen çok fazla) artan derleme süresiyle ödenir.)

Genel bir sıralama işlevi örneğini düşünün.

C'de, qsort işlevi, öğelerin birbirine göre sıralandığı mantığı uygulayan bir işlev işaretçisi alır. Java’nın Arrays.sort işlevi çeşitli varyantlarda gelir; bunlardan biri rastgele nesneleri sıralar ve C'nin Comparator fonksiyon işaretçisi gibi çalışan bir qsort nesnesi geçirilmesini gerektirir. Ancak, "native" Java türleri için birkaç aşırı yükleme var. Ve her birinin sort yönteminin kendine ait bir kopyası var - korkunç bir kod çoğaltma.

Java burada genel bir ikilemi göstermektedir: ya kod çoğaltmanız var ya da bir çalışma zamanı yükü alıyorsunuz.

C++ 'da, sort işlevi, C'deki qsort gibi, küçük ama temel bir farkla çalışır: işleve iletilen karşılaştırıcı bir şablonudur parametresi. Bu, çağrısının satır içi olabileceği anlamına gelir. İki nesneyi karşılaştırmak için hiçbir dolaylama gerekmez. Sıkı bir döngüde (burada olduğu gibi) bu aslında önemli bir fark yaratabilir.

Şaşırtıcı olmayan bir şekilde, temel algoritma aynı olsa bile C++ sort işlevi, C'nin sort performansından daha iyi performans gösterir. Bu, gerçek karşılaştırma mantığı ucuz olduğunda özellikle fark edilir.

Şimdi, değilim C++ 'ın C (veya diğer diller)' den daha etkili bir a priori olduğunu ya da a priori daha yüksek bir soyutlama sunduğunu söylemiyorum. Sunulan şey, aynı zamanda çok yüksek ve inanılmaz derecede ucuz olan bir soyutlamadır, böylece genellikle verimli ve yeniden kullanılabilir kod arasında seçim yapmanız gerekmez.

310
Konrad Rudolph

C++ 'dan nefret eden çok fazla C programcısı görüyorum. Neyin iyi ve neyin kötü olduğunu yavaşça anlamak biraz zaman (yıl) aldı. Bence bunu ifade etmenin en iyi yolu şudur:

Daha az kod, çalışma zamanı yükü yok, daha fazla güvenlik.

Ne kadar az kod yazarsak o kadar iyidir. Bu, mükemmellik için çaba harcayan tüm mühendislerde hızla netleşir. Tek bir yerde bir hatayı düzeltirsiniz, çok değil - bir kez bir algoritmayı ifade edersiniz ve birçok yerde yeniden kullanırsınız, vb. Yunanlıların bile eski Spartalılara kadar uzanan bir sözleri vardır: "daha az kelimeyle bir şey söylemek, bu konuda akıllıca davranırsınız ". Ve işin gerçeği, doğru kullanıldığında , C++, çalışma zamanı hızına mal olmadan kendinizi C'den çok daha az kodla ifade etmenize izin verirken, C'den daha güvenli olmak (yani derleme zamanında daha fazla hata yakalamak).

İşte benim renderer : Bir üçgen tarama çizgisinde piksel değerlerini enterpolasyon yaparken basitleştirilmiş bir örnek. Bir X koordinatı x1'den başlamak ve bir X koordinatı x2'ye (bir üçgenin solundan sağına) ulaşmak zorundayım. Ve her adımda, geçtiğim her piksel boyunca, değerleri enterpolat etmek zorundayım.

Piksellere ulaşan ortam ışığını enterpolasyona soktuğumda:

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

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

Rengi enterpole ettiğimde ("Kırmızı", "yeşil" ve "mavi" alanların her pikselde bir adım değeri ile enterpole edildiği "Gouraud" gölgesi olarak adlandırılır):

  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;

"Phong" gölgesinde oluşturduğumda, artık bir yoğunluk (ambientLight) veya bir renk (kırmızı/yeşil/mavi) enterpolasyon yapmıyorum - Normal bir vektörü (nx, ny, nz) enterpole ediyorum ve her adımda - enterpolasyonlu normal vektöre göre aydınlatma denklemini hesaplayın:

  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;

Şimdi, C programcılarının ilk içgüdüsü "heck, değerleri enterpolasyon yapan üç fonksiyon yazın ve ayarlanan moda bağlı olarak onları çağırın" olacaktır. Her şeyden önce, bu bir tür sorunum olduğu anlamına geliyor - ne ile çalışıyorum? Piksellerim PixelDataAmbient mi? PixelDataGouraud? PixelDataPhong? Oh, bekle, verimli C programcısı sendika kullan diyor!

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

..ve sonra bir fonksiyonunuz var ...

  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;
          }
...

Kaosun kaydığını hissediyor musun?

Her şeyden önce, bir yazım hatası kodumu çökertmek için gerekli olan tek şey, çünkü derleyici beni gerçekten ".ura" erişmek için fonksiyonun "Gouraud" bölümünde durduramaz. (ortam) değerleri. C tipi sistem tarafından yakalanmayan bir hata (derleme sırasında), çalışma zamanında ortaya çıkan ve hata ayıklama gerektiren bir hata anlamına gelir. "Dgreen" hesaplamasında left.a.green Kaynağına eriştiğimi fark ettiniz mi? Derleyici kesinlikle size söylemedi.

Daha sonra, her yerde tekrar var - for döngüsü, oluşturma modları olduğu kadar çok kez var, "sağ eksi sol adımlarla bölünüyor". Çirkin ve hata eğilimli. "J" yi kullanmam gerektiğinde Gouraud döngüsünde "i" kullanarak karşılaştırdığımı fark ettiniz mi? Derleyici yine sessiz.

Modlar için if/else/merdiveni ne olacak? Üç hafta içinde yeni bir oluşturma modu eklersem ne olur? Tüm kodumdaki tüm "if mode ==" modlarında yeni modu kullanmayı hatırlayacak mıyım?

Şimdi yukarıdaki çirkinliği, bu C++ yapıları ve bir şablon işlevi kümesiyle karşılaştırın:

  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;
      }
  }

Şimdi şuna bak. Artık sendika tipi çorba yapmıyoruz: her mod için belirli tiplerimiz var. Bir temel sınıftan (CommonPixelData) miras alarak ortak öğelerini ("x" alanı) yeniden kullanırlar. Ve şablon, derleyiciyi C'de kendimize yazacağımız üç farklı işlevi CREATE (yani kod üretme) yapar, ancak aynı zamanda türler hakkında çok katıdır!

Şablondaki döngümüz geçersizleşir ve geçersiz alanlara erişemez - eğer yaparsak derleyici havlar.

Şablon ortak çalışmayı gerçekleştirir (döngü, her seferinde "adım" artarak) ve bunu çalışma zamanı hatalarına neden OLMAYACAK şekilde yapabilir. Tür başına enterpolasyon (AmbientPixelData, GouraudPixelData, PhongPixelData), yapılara ekleyeceğimiz operator+=() ile yapılır - temel olarak dikte eden Her türün nasıl enterpolasyonlu olduğu .

Ve WorkOnPixel <T> ile neler yaptığımızı görüyor musunuz? Her tipte farklı işler yapmak istiyor muyuz? Sadece bir şablon uzmanlığı diyoruz:

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


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

Yani - çağrılacak işleve, türe göre karar verilir. Derleme zamanında!

Tekrar ifade etmek için:

  1. ortak parçaları yeniden kullanarak kodu (şablon aracılığıyla) en aza indiririz,
  2. çirkin kesmek kullanmıyoruz, sıkı bir sistem tutuyoruz, böylece derleyici her zaman bizi kontrol edebilir.
  3. ve en iyisi: yaptığımız hiçbir şeyin çalışma zamanı üzerinde herhangi bir etkisi yoktur. Bu kod SADECE eşdeğer C kodu kadar hızlı çalışır - aslında, C kodu çeşitli WorkOnPixel sürümlerini çağırmak için işlev işaretçileri kullanıyorsa, derleyici satır içi olacağından C++ kodu C'den daha hızlı olacaktır. türe özgü WorkOnPixel şablon özelleştirme çağrısı!

Daha az kod, çalışma zamanı yükü yok, daha fazla güvenlik.

Bu, C++ 'nın dillerin hepsi ve sonu olduğu anlamına mı geliyor? Tabii ki değil. Yine de ödünleşmeleri ölçmek zorundasınız. Cahil insanlar bir Bash/Perl/Python betiği yazmaları gerektiğinde C++ kullanacaklardır. Tetikleyici mutlu C++ yeni başlayanlar, onları durdurabilmeniz ve ambalaj göndermeden önce sanal çoklu kalıtımla derin iç içe sınıflar oluşturacaktır. Bunun gerekli olmadığını fark etmeden önce karmaşık Boost meta-programlama kullanırlar. STILL, char* Ve şablonlar yerine std::string, strcmp ve makroları kullanacaklar.

Ama bu ... kiminle çalýţtýđýný izle. Sizi beceriksiz kullanıcılardan koruyacak bir dil yoktur (hayır, Java bile değil).

C++ 'ı çalışmaya ve kullanmaya devam edin - fazla tasarlamayın.

167
ttsiodras

RAII kazanan bebek için.

C++ 'da deterministik yıkım, kodu hiçbir ek yük olmadan çok daha açık ve güvenli hale getirir.

79
Motti

C++ kullanmak için tatmin edici bir neden var mı?

  1. Şablonlar ve STL. Önemli bir çalışma zamanı performans isabeti olmadan (ikili ayak izi biraz olabilir), lot yararlı soyutlama ve iş gücü tasarrufu araçları için biraz inşa süresi (ve bazı anlaşılmaz hata mesajları) ticareti yaparsınız. ) daha büyük olabilir.

    Kafanı sarmak biraz zaman alır (tıklanmadan birkaç yıl önce beni aldı), ama bir kez yaptıktan sonra hayat bir lot daha basit hale getirebilir.

  2. C++ 'da metin işleme büyüklük sırası C'de olduğundan daha az acı verir.

70
John Bode

Evet.

Yürütülebilir verimlilik arıyorsanız, C veya C++ 'ya inersiniz, bu yüzden buna odaklanacağım.

Şablonlar yaygın olmadan önce, iki çok basit nedenden ötürü 1990'ların ortalarında tartıştığınız yürütülebilir dosyalar için C++ 'ı C üzerinde kullanmayı tercih ettim: nesne polimorfizmi ve RAII .

Ben her türlü ilginç şeyler için polimorfik C++ nesneleri kullandım. Örneğin, OMAP ve XScale ARM CPU'lar üzerinde çerçeve arabellek kaplamaları olan gömülü bir Linux sistemi üzerinde çalışıyordum. İki donanım mimarisinin çok farklı API'lerle farklı kaplama özellikleri var. Ortak bir sanal kullandım ” Bindirmelerin idealize edilmiş bir görünümünü ortaya çıkarmak için "temel sınıfı" üzerine yazın ve kodun üzerinde çalıştığı algılanan mimariye bağlı olarak çalışma zamanında uygun şekilde başlatılan "OmapOverlay" ve "XScaleOverlay" sınıflarını yazdı.

Aşırı basitleştirmek için RAII, nesnenin yapıcısı sırasında veya belki de daha sonra nesnenin yaşamı boyunca bir nesneye bağlı kaynakları ayırdığınız ve kaynakların nesnenin yıkıcısında serbest bırakıldığı veya serbest bırakıldığı fikridir. C++ 'da bu gerçekten güzel, çünkü otomatik değişken olan nesneler kapsam dışına çıktığında yok edilir. C ve C++ 'da eşit derecede yetkin biri için, C++' da kaynak ve bellek sızıntılarından kaçınmak çok daha kolaydır. Ayrıca, free() çağrısından önce gelen bir işlevin sonunda ve işlev bloğundaki çeşitli goto 'lerden bir etiketin çok yaygın C memesi ile çok fazla C++ kodu görmüyorsunuz. orada atlama.

Tüm bu şeyleri C ile yapabileceğinizin tamamen farkındayım - sadece çok daha fazla iş, daha fazla kod satırı ve kurguladığınız şey çok daha çirkin ve genellikle daha zor. X server internals ve man, boyunca polimorfizm kodu var, çirkin ve garip ve sık sık izlenmesi zor.

Ayrıca GTK + ve Clutter gibi hepsi de GObject sistemini kullanarak C ile yazılmış GNOME teknolojileriyle çok çalışıyorum. GObject, Nice kapağı çıkarılmış ve tüm çirkin içler açıkta olan C++ nesne sistemi gibidir ve genellikle tek satırlık bir C++ yöntemi çağrısının yapacağı işlemi yapmak için yarım düzine kod satırı gerektirir. Şu anda bazı ClutterActors yazıyorum ve matematik gerçekten ilginç olsa da, sürekli olarak, "Bu C++ çok daha özlü ve anlaşılır olurdu" diye düşünüyorum.

Ben de sık sık, "Biliyor musun, bunu C yerine C++ ile yazsaydım, oturma odasında dışarıda izlerdim MythBusters eşim ile saat 9'da ofisimde oturmak yerine ."

41
Bob Murphy

C++, C kadar hızlıdır (bazı şeyler daha hızlı, bazıları daha yavaş) ve daha iyi soyutlamalar ve organizasyon sunar. Sınıflar, ilkel türlere benzer şekilde çalışır ve büyük miktarlarda kodun akılda tutulmadan kullanılmasına izin verir. Operatör aşırı yüklemesi ve şablonlar, veri gösterimleri değişirse daha iyi çalışan kod yazmayı mümkün kılar. İstisnalar daha kolay hata işlemeye izin verebilir. Derleyici, derleme zamanında daha fazla öğeyi kontrol etmek için kullanılabilir.

Bunun için ödediğiniz fiyat oldukça kötü bir öğrenme eğrisidir ve içinde aşina olduğum diğer dillerden daha ince hatalar yapmak daha kolaydır.

Bu yüzden, şimdi yaptığınız şey için öğrenmenin sizin için değerli olup olmayacağını söyleyemem. Kesinlikle Python veya Perl ve C kombinasyonları ile elde edebilirsiniz, ancak C++, kullanımı zor bir pakette hem soyutlama hem de performans sunar.

29
David Thornley

C++ 'ı 1990'lı yılların dili, eski çağın dili olarak görüyorum.

O zamanlar büyüktü, çünkü performans açısından daha düşük maliyetle daha üst düzey dil yapıları ve mekanizmaları sundu. Adres defteri uygulamalarından aviyonik yazılımlara kadar her şeyi geliştirmek için kullanılan evrensel bir araçtır ve bu da OO çılgınlığına ilham kaynağı olmuştur. OOP açlığı ve AIDS'i çözdü ve evet, 1990'ların sonunda OO olmayan herhangi bir dilin öğrenmeye değmeyeceğini programlamaya başladığımda beni beyin yıkamaya çalıştığı için C++ 'ı suçluyorum.

Artık donanım çok gelişti ve daha yeni, modern diller ortaya çıktı, hala biraz soyutlamaya (oyunlar, fizik simülasyonları, CAD ihtiyaç duyduğunuz hesaplama açısından yoğun yazılımlar dışında C++ 'ın çoğu uygulama programlama için ilgili bir seçim olarak kaldığını göremiyorum. sistemleri vb.). C'de kompakt, modüler bir motor yazarsanız ve düzgün bir komut dosyası diline devredilen daha üst düzey uygulama mantığına sahipseniz, ikincisinden bile kaçınılabilir.

Metal C'ye doğru bir şekilde gitmeniz gerekiyorsa ve yüksek seviyeye gitmeniz gerektiğinde, her baytı bir işaretçi aracılığıyla serbestçe değiştirebildiğinizde kapsülleme reklamını yapmayan modern bir dilde yapın.

28

Linus'a göre , hayır:

Git kaynak koduna ilk baktığımda iki şey bana garip geldi: 1. C++ yerine Pure C. Neden olduğu hakkında bir fikrim yok. Lütfen taşınabilirlik hakkında konuşma, BS.

[~ # ~] siz [~ # ~] saçmalıklarla dolusunuz.

C++ korkunç bir dildir. Birçok standart altı programcının onu kullanması, onunla toplam ve mutlak bok üretmenin çok daha kolay olduğu noktaya kadar daha korkunç hale geldi. Açıkçası, C seçimi hiçbir şey yapmasa bile ama C++ programcılarını dışarıda tutsa bile, kendi başına C'yi kullanmak için çok büyük bir sebep olurdu.

Başka bir deyişle: C seçimi tek aklı başında seçimdir. Miles Bader'ın şaka yollu bir şekilde "seni kızdırmak" dediğini biliyorum, ama aslında doğru. Ben proje C üzerinde C++ olmasını tercih edecek herhangi bir programcı büyük olasılıkla ben gerçekten piss tercih bir programcı olduğu sonucuna vardım işin içine girdiğim herhangi bir projeyi berbat etmemesi için.

C++ gerçekten kötü tasarım seçeneklerine yol açar. Her zaman STL ve Boost gibi dilin "Nice" kütüphane özelliklerini kullanmaya başlarsınız ve programlamanıza "yardımcı olabilir", ancak aşağıdakilere neden olabilir:

  • çalışmadığında sonsuz miktarda acı (ve bana STL ve özellikle Boost'un kararlı ve taşınabilir olduğunu söyleyen herkes BS ile o kadar dolu ki komik bile değil)

  • iki yıl boyunca bazı soyutlamaların çok verimli olmadığını fark ettiğiniz verimsiz soyutlanmış programlama modelleri, ancak şimdi tüm kodunuz etrafındaki tüm Nice nesne modellerine bağlıdır ve uygulamanızı yeniden yazmadan düzeltemezsiniz.

Başka bir deyişle, iyi, verimli ve sistem düzeyinde ve taşınabilir C++ yapmanın tek yolu, kendinizi temel olarak C'de bulunan tüm şeylerle sınırlamak ve sonuçta projenizi C ile sınırlamak, insanların bunu vidalamaması anlamına gelir. ve aynı zamanda düşük seviyeli sorunları gerçekten anlayan ve herhangi bir aptalca "nesne modeli" saçmalıklarına zarar vermeyen birçok programcıya sahip olduğunuz anlamına gelir.

Üzgünüm, ama verimliliğin birincil hedef olduğu git gibi bir şey için, C++ 'nın "avantajları" sadece büyük bir hatadır. Bunu göremeyen insanları da kızdırmamız, büyük bir ek avantajdır.

C++ ile yazılmış bir VCS istiyorsanız, Monotone ile oynayın. Gerçekten mi. Bir "gerçek veritabanı" kullanırlar. "Güzel nesne yönelimli kütüphaneler" kullanıyorlar. Onlar "Güzel C++ soyutlamalar" kullanın. Ve açıkçası, bazı CS insanlarına bu kadar çekici gelen tüm bu tasarım kararlarının bir sonucu olarak, sonuç korkunç ve sürdürülemez bir karışıklıktır.

Ama eminim git'ten daha çok istersiniz.

      Linus
21
Jeremy Heiler

C++ kullanmak için zorlayıcı bir neden olduğunu düşünmüyorum. OO programlama yapmak istiyorsanız, Python kullanabilirsiniz ve C'de hızlı performans gerektiren parçaları yazabilirsiniz.

EDIT: C ile iyi arayüz diğer diller vardır, bu yüzden Python sevmiyorum, alternatifler vardır.

18
Larry Coleman

C++ kullanmak için bir neden var mı? Kesinlikle.

Bazı insanlar sadece tercih edebilir C++ diğer seçeneklere göre kullanmak. C++ kullanmanın bir nedeni olup olmadığını sormak, neden yüzlerce dondurma çeşidine ihtiyacımız olduğunu sormak gibidir. Herkes sadece Vanilya'ya yapışmayı sevmez.

Geliştiriciler zaten C++ ile çok yetkinse, onlar için soru 'neden kullanıyorsunuz' değil, 'neden olmasın?' Olabilir. SO şu anda devam ediyor, ama ister inanın ister inanmayın, herkes buna abone değil, bu trendy anti-C++ şey var gibi görünüyor.

C++ 'nın uygulamalar için kullanılması gerekiyor mu ? Tabii ki değil. Ancak bu aynı soru başka herhangi bir dil için de sorulabilir. Bir uygulama için belirli bir dilin kullanılması gereken çok ancak çok az durum vardır.

13
GrandmasterB

Sadece C'den C++ 'ya geçiyorum ve şablonlara ve OOP'a ihtiyacınız olmasa bile kazancın önemli olduğunu düşünüyorum.

  • Daha iyi bellek yönetimi
  • Daha güçlü tip sistemi
  • Daha iyi bir standart kütüphane
  • Ad alanları
  • vb.
12
Oliver Weiler

Kimsenin bundan bahsetmediğine şaşırdım, ancak C++ bizi işaretçilerin tüm sorunlarını ve tuzaklarını neredeyse çözen referanslar ile tanıştırdı:

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

int test = 4;
ModifyVar(test);

Onun yerine:

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

int test = 4;
ModifyVar(&test);

Çok daha güvenli ve daha kolay ... ve değere göre geçiş yükü olmadan.

8
Nathan Osman

Nerede ve neden genellikle:

  • aşinalık
  • istenen dil özellikleri
  • kullanmak istediğiniz belirli kütüphaneler
  • performans gereklilikleri

Sunucu tarafı programlama için, genellikle derlenmiş veya yorumlanmış sayısız farklı dil arasından seçim yapabilirsiniz. Genellikle dil seçimi sizin veya ekibinizin hangi platformda en etkili olacağı ile belirlenir. Veya henüz bir ekibiniz yoksa, pazardaki becerilerin kullanılabilirliği.

Bir yan notta, birçok komut dosyası dili C/C++ ile genişletilebildiğinden, performansa dayalı C/C++ kullanmaya karar vermeyi gerçekten anlamıyorum. Yavaş bölümleri C/C++ uzantılarına geçirme yeteneği ile birlikte hızlı bir geliştirme dilinden faydalanırsınız. Kesinlikle her op sayılır yerlerde programlama sistemleri anlaşılır, ancak çoğu uygulama geliştirme bunu elde edemiyorum.

5
dietbuddha

C++ vs Python vs Perl kolayca değerlendirilemez, projeye ve gereksinimlere bağlıdır.

C++, uzun zaman önce birçok platformda çalışan bir yardımcı program cephanesine sahiptir. Ancak String'i tamsayıya ve tersine geçirmek için akışlarda yürümeye başlamak acı vericidir.

Öte yandan C++, kütüphanelere bağımlılıklarla korkunç bir anlaşma yapıyor. GCC X veya VC++ Y'de bir şey derledikten sonra, kodun bu araçların bir sonraki sürümü tarafından çalışacağına güvenemezsiniz. Aynı cehennem Windows'ta, aynı cehennem de Unix'te.

Perl, gücünü Unix dünyasından ama özellikle düzenli bir ifade aracı olarak alıyor. Çoğu zaman bu kullanılır. Java normal bir şekilde yapamayacağı bazı ciddi araçlarla birlikte (bir dosyayı bir web sunucusuna nasıl yükleyeceğinizi kontrol edin), Perl “sadece yap” dır.

Python kolay, esnek ve dinamik bir dildir. O kadar kolay bir fonksiyona bir tamsayı gönderebilirsiniz, script dize bekliyor, ama bir sonuç olabilir! Beklenmedik ama sonuç. Bu yüzden programcının çok dikkatli olması gerekiyor. BOŞTA bazı hata ayıklama sunar, ancak TELNET'i bir sisteme veya SSH'yi üç seviyeye indirdiğinizde ve sorununuzu bulmak istediğinizde, hata ayıklayıcı yanında duramaz. Ancak, bazı harika matematik çalışmalarını hızlı bir şekilde yapabilir.

Java, buzzwords, uzaylı teknolojileri ve büyük kelimelerin ekosistemidir ve yalnızca web sunucusuna bir dosya yüklemek istediğinizde, bunu yalnızca sunucuda JSP . Sistem kitaplıklarını veya izleme gibi sistem işlevlerini çağırmak istiyorsanız, çok fazla Kazmanız gerektiğini görürsünüz. Ve belki de ulaşmak için JNI ve Tamam ... Sence o zaman ... "Neden Rab?"

Bunun dışında, Java iş süitleri için harika bir araçtır ve multithreading, çok beğendim.

Hızlı bir program yapmak ve özgeçmişinize göstermek için "Oh, ben de teknolojiyi biliyorum" ve olmak istiyorum patron, şaşıracaksınız! Teknoloji gerekli olmasa da ... (Tamam, millet, Spring Framework .... 'dan nefret ediyorum.)

4
hephestos

Linux? "Nesneye yönelik Pascal" veya "D" ne olacak?

Öneriler:

3
mramirez

Bir dil seçerken akılda tutulması gereken şey, onu kullanmaktan ne fayda sağlayacağınız ve onu almanın ne kadar süreceği.

python ve Perl gibi diller arasındaki ana fikir, daha az insan zamanı, ancak daha fazla işlemci zamanı ile daha fazlasını yapmaktır. Aslında bir python veya Perl betiğini kodlamaktan daha fazla zaman harcayacaksınız, ama benim fikrimi anlıyorsunuz.

C/C++ 'ın avantajı hızlı olmalarıdır, ancak sözdizimi ve güçlü yazma maliyetiyle: bilgisayarın derleme zamanında seçmemesi için kendiniz çok şey yapmanız gerekir.

Bir kod yaptığınızda, bazı satırlar diğerlerinden çok daha fazla çalıştırılır ve bu satırlar sorun teşkil eden satırlardır. Öte yandan, kodun geri kalanı, çok fazla zaman harcadığınız kod, çok daha az sıklıkla yürütülür. Bunu duymuş olabilirsiniz, ancak bu 80/20 meşhur kuraldır ve bu kuralı atlayamazsınız.

Bu sorunun çözümü, tüm kodunuzu yapmak için daha kolay bir dil kullanmaktır (daha kolay geliştirici dostu: daha az yazarak, tembel yorumlama, önceden var olan bir çok rutin ve malzeme vb.).

Bunu, C veya C++ ile yapsaydınız, çok daha fazla beyin ağrısı alacak kadar hızlı bir şekilde yapacaksınız.

Programınız yavaş olacak, ancak bir profil oluşturucu ile, zamanın% 80'inde çalıştırılan kısmı izole edersiniz ve bunları C veya C++ ile yaparsınız.

Bu şekilde programlayarak, çok zaman kazandınız ve programınız da çok hızlı, bellek sızıntısı yapma şansınız daha az ve zamandan tasarruf ettiniz.

Komut dosyası dilleri geliştiricinin yanında olacak şekilde tasarlanmıştır, ancak yine de optimizasyon mümkündür. Tabii ki bir tasarım deseni sihirbazı veya bir STL vudu veya hatta bir LISP savaşçısı ve belki de bir haskell keşişi olabilirsiniz. Ama diller bilgisayarlarla konuşmamızı sağlıyor, bilgisayar olmamız için diller yapılmıyor!

3
jokoon

Ben kullandığım C++ sınıfları ile C denir!

2
willspeak

Hayır, hiç de değil. Performansa ihtiyacınız yoksa ve başka bir dil kullanabileceğiniz bir kütüphane varsa C/C++ ile uğraşmayın. Bugünlerde sadece dilleri (kolayca?) Çalıştıramayan gömülü sistemleri hedeflediğimde yapıyorum. Bazen C kullanıyorum çünkü bir eklenti yazıyorum ama gerçekten hayır.

Ancak, C kullanmaktan kaçınmak için Python, Perl, vb kullanmak olmaz. Tercihim aslında C #, çünkü iyi bir kütüphane (.NET'in gücüdür) ve statik olarak yazılmış dilleri seviyorum. Boo iyi bir alternatiftir. Ama gerçekten Haskell , OCaml , D , ML ve hepsi iyi.

0
user2528

Aslında böyle oluşturulan tüm sorulara tek bir cevap var. Y teknolojisi yerine X teknolojisini kullanmanın en iyi nedeni (X ve Y kabaca aynı seviyededir (tıpkı tüm çağdaş programlama dilleri gibi)) X'i zaten biliyor olmanız ve Y'yi bilmemenizdir.

(ancak Haskell geldikten sonra, başka bir şey kullanmanın bir nedeni yoktu)

0
vegai