C ++ 'dan C ve C ++' dan C ++ ne zaman kullanılır?

164

Bilgisayar Bilimi ile bir yıldan biraz fazla bir süredir tanıştım ve deneyimlerime göre, C ve C ++ 'nın her ikisinin de "ultra hızlı" dilleri olduğu düşünülürken, Python ve bu tür betik dilleri genellikle biraz daha yavaş sayılıyor. .

Ancak, bir yazılım projesinin veya küçük bir projenin bile bu dosyaların belirli bir sayısının C'ye yazılacağı dosyaların bir araya geldiği ve bu dosyaların belirli bir sayısının C ++ dilinde yazılacağı birçok durum gördüm.

(Ayrıca, C ++ dosyalarının hemen hemen her zaman karşılık gelen başlıklara sahip olduğunu, C dosyalarının ise çok fazla olmadığını farkettim). Fakat benim asıl sorgulama noktam, C ++ 'dan C ++ kullanmanın uygun olduğu ve C ++' dan C + 'yı kullanmanın daha iyi olduğu durumlarda genel bir sezgi duygusu elde etmektir. (1) C ++' ın nesne yönelimli olduğu gerçeğinden başka C değildir ve (2) sözdizimleri çok benzerdir ve C ++ kasıtlı olarak C'ye pek çok şekilde benzemek için yaratılmıştır, farklılıklarının ne olduğundan emin değilim. Bana öyle geliyor ki, pek çok alanda (neredeyse) kusursuz bir şekilde değiştirilebilirler.

Bu yüzden eğer birileri durumu düzeltebilirse memnun oluruz! Teşekkürler

c++ c

— Dark Templar
kaynak

4

C ++ kodunda C satır içi kullanımı genellikle en iyi duruma getirilmesi gereken, donanıma çok yakın düzeylerde çalışma yapan veya verilerin bütünlüğü ve hatta insan güvenliği için kritik öneme sahip bazı modüller için geçerlidir ve denetlenebilir ve doğru olmaları gerekir. Her şeyi C'de yapmak yerine, projenin büyük kısmı esnek tasarımlar için C ++ özelliklerinden yararlanırken, ihtiyaç duyulan yerlerde C'nin sızdırmazlığının avantajlarından yararlanır.

— kylben

30

@kylben: Pek çok C ++ çalışanı size söyleyecektir: (1) Performans C'ye düşme nedeni değildir (belki de kaçınmak virtualve optimizasyonları engelleyen birkaç özellik daha vardır, ancak örneğin virtualsınıf dışı doğası gereği yetersizdir ve şablonlar bir Aslında daha verimli - örneğin qsortvs std::sort) yol açabilecek güçlü bir soyutlama aracı . (2) Doğruluğun yüksek önemi, C ++ 'ı ( kaynak yönetimi yönetilebilir hale getirmek için CFA) (çeşitliliği, constniyeti private, RAII, vb.) C'nin üzerinde kullanmak için bir nedendir .

11

@ Pubby8 Buna katılmıyorum. Bir .c dosyası üzerinde çalışıyorsam ve insanların bunu yaptığını görüyorsam, zihinsel olarak ne yaptıklarını bilmediklerini işaret etme eğilimindeyim. Örneğin, void*C kodunda başka bir işaretçi türüne

— çevirmeye

4

@kylben: (Yorumunuzdaki diğer kişilere doğru bir şekilde hitap etmeyi öğrenmek isteyebilirsiniz, bu yüzden onları gerçekten görme şansı vardır.) "Derleyicinin C'yi nasıl asm çevirdiğini çok iyi bilen bir programcı" gibi iyi. Ama bu sadece alakasız: Eğer asm ile uğraşmak istiyorsanız, derleyiciyi başka bir dilden yaratmanız yerine, sadece asm yazın. Bunu yapma şekli, sonuçta her derleyici güncellemesinde değişebilir.

— sbi

9

Alçakgönüllü görüşüme göre, istediğiniz zaman C'yi kullanıyorsunuz, benim için: C, C ++ 'dan çok daha basit ve kullanımı daha kolay ... C ++, "C With class" gibi görünebilir, ama artık değil. Sanal Yapıcılar ve Şablonlar gibi şeyler ile çok karmaşık bir dil.

— dysoco

184

C'yi ne zaman seçersin?

her ne sebeple olursa olsun taşınabilir C montajcısına (gerçekten C'nin ne olduğu)
platformunuz C ++ sağlamaz (bir C derleyicisinin uygulanması daha kolaydır),
C ile etkileşime girebilecek diğer dillerle etkileşime girmeniz gerekir (genellikle herhangi bir platformda en düşük ortak payda olan) ve kodunuz, C ++ kodu üzerinden C arabirimi koymaya değmez, arabirimden biraz daha fazlasını içerir.
Açık Kaynaklı bir projeyi hacklediniz (birçoğu, çeşitli nedenlerle C'ye sadık),
C ++ 'ı tanımıyorsun.

Diğer tüm durumlarda C ++ 'ı seçmelisiniz.

— sbi
kaynak

15

Ayrıca istisna modeline sahip C ++ 'nın işletim sistemi çekirdeği gibi değerinden daha fazla sorun çıkardığını da ekleyeceğim. En azından bir şeyler okurken edindiğim genel duygu bu.

— Kodlayıcı

12

@SF: C lingua franca mı? Bu yeni. Ya da daha doğrusu, çok yaşlı. Belki de sadece son 20 yıldır yeni dil öğrenmemiş insanlarla konuşursanız, ama C bilgisinin artık çok yaygın olmadığını söyleyebilirim.

— DeadMG

13

@SF .: Başka bir yerde yazdığım gibi, milyonlarca LoC'ye ulaşan projelerde bulundum ve kaçınılmaz ve her yerde bulunmayan makro korsanlıklarıyla C projelerine kıyasla çok az meta madde gördüm. (OTOH, gerektiğinde EDSL oluşturma yeteneği, kutunuzda inanılmaz derecede güçlü bir araç olabilir.) C'nin lingua franca olduğu gibi: En düşük ortak payda olduğumu söylemek istiyorum. Üstelik ılımlı programlama becerisine sahip insanların bir işletim sistemi çekirdeğini hacklemelerini istemem.

— sbi

18

@ Max: Tamamen aynı fikirde değilim. C, işe yaramaz bir pratik engel, C ++ 'ı engellemediği sürece yararsız bir dildir.

— DeadMG

17

@Buttons: Hak talebinde bulundun ("C ++ daha fazla belleğe ihtiyaç duyuyor"), bu yüzden bunu destekleyen siz olmalısınız. Ve hayır, C ++ 'ın daha az belleğe ihtiyacı olduğunu iddia etmiyorum . Demek istediğim, derleyicinin bunları sizin için uygulamasına (sanal işlevler) ya da kendinize (işlev işaretçiler dizisine) uygularsanız da , bu özelliklerin maliyetidir.

— sbi

88

C'yi tercih etmenin birkaç nedeni vardır: Asıl olan, C ++ ile gerçekten küçük uygulamalar üretme zorluğudur. Gerçekten küçük sistemler için, nadiren çok fazla kod yazıyorsunuz ve C ++ için gerekli olacak ekstra ROM alanı, C yerine önemli olabilir.

Ancak şunu da eklemeliyim ki, gerçekten küçük sistemler için, C'nin tamamen aynı nedenden dolayı problemleri var ve montaj dili neredeyse tek makul seçenek. C'nin gerçekten mantıklı olduğu sistem boyutları aralığı oldukça küçük ve sürekli küçülüyor (yine de oldukça yavaş itiraf edeyim).

C'yi kullanmanın başka bir zamanı / nedeni, diğer herhangi bir dilden bağlayabileceğiniz bir dizi işlev sağlamaktır. Sen edebilirsiniz olarak tanımlayarak C ++ bu işlevleri yazma extern "C"fonksiyonları, ama bunu yaparken dünyaya esasen C-life "yüz" sunmaya bu işlevleri kısıtlar - vb sınıfları, aşırı fonksiyonlar, şablonlar ve üye fonksiyonlarını, gerek uygulamak. Bu, gelişimi kesinlikle C ile sınırlamaz - harici arabirim C gibi gözüktüğü sürece, her türden C ++ özelliğini dahili olarak kullanmak tamamen mantıklıdır .

Aynı zamanda, @ Toll'un cevaplarının (bariz bir örnek için) çoğu bakımdan geriye doğru bir şeyleri olduğunu söylemeliyim. Makul bir şekilde yazılmış olan C ++ genellikle en az C kadar hızlı ve genellikle en az biraz daha hızlı olacaktır. Okunabilirlik genellikle çok daha iyidir, çünkü yalnızca en önemsiz algoritmalar ve veri yapıları, tüm hata işlemeleri vb. İçin tüm kodların bir çığına gömülmezseniz.

Şablonlar "dilin tip sistemiyle ilgili bir sorunu çözmez", şablonlar olmadan C ve / veya C ++ 'da neredeyse tamamen bulunmayan bir dizi temel özellik eklerler. Orijinal amaçlardan biri, güvenli tip konteynerler sağlamaktı, ancak gerçekte bunların ötesine geçtiler - aslında hiçbiri C'nin sağladığı hiçbir şey.

Otomatik araçlar çoğunlukla kırmızı bir ringa balığıdır - bir C ayrıştırıcısı yazmanın bir C ++ ayrıştırıcı yazmaktan daha az iş olduğu doğrudur; Çok az kişi, ikisinden biri için kullanılabilir bir çözümleyici yazmaya istekli veya yazabiliyor. Bu nedenle, makul başlangıç noktası her iki şekilde de Clang.

Olduğu gibi, C ve C ++ aynı insanlar tarafından sürdürülen aynı projelerde sık sık birlikte kullanılıyor. Bu, aksi takdirde oldukça nadir olan bir şeye izin verir: iki dilde yazılmış kodun genel olarak eşit derecede yetkin kişiler (yani aynı insanlar) tarafından korunmasını doğrudan, nesnel olarak karşılaştıran bir çalışma . En azından bağlantılı çalışmada, bir sonuç açık ve netti: "C yerine C ++ kullanmanın, geliştirilmiş yazılım kalitesi ve düşük bakım çabasıyla sonuçlandığını gördük ..."

— Jerry Tabut
kaynak

12

Alet desteği kırmızı bir ringa balığı değildir . Verilmiş, bugünlerde klanımız var. Ama C ++ için aracı desteği yok bile büyük çekim IDE, önemli ölçüde oder dillere arkasında lag. Neden? Basit, çünkü çok yakın bir zamana kadar hiç klan yoktu (ve GCC asla alternatif değildi). Belki bir buçuk yıl öncesine kadar, eğer bir AST C ++ koduna ihtiyacınız varsa, temelde şansınız ya da binlerce dolar dışındaydınız (EDG önyüzünü satın aldıysanız).

— Konrad Rudolph

5

+1 ve kayıt için düzenli olarak 8 bit işlemciler için 4KiB ROM'lu C ++ kodu yazıyorum.

— avakar

2

Genel bir cevap için +1. Ne yok anlamaya (biz gömülü bahsediyoruz sanırım?) C ++ derleyicisi daha küçük yürütülebilir kod üretmelidir C derleyicisi neden (. Hiç deneyimi wrt var bu) aynı özellik seti verildi kullanılan ? Belki bazı referanslar sunabilirsiniz?

— Martin Ba

2

@Martin: Asıl mesele, C ++ 'ın (en azından genellikle) çalıştırılabilir boyuta bir miktar minimum değer ekleyen istisna işleme içermesidir. Çoğu derleyici özel durum işlemeyi devre dışı bırakmanıza izin verir, ancak sonucu yaptığınızda artık oldukça C ++ olmaz. Ayrıca, birçok C ++ derleyici satıcısının mümkün olan en küçük çıktı kodunu üretmek için çok fazla çalışmadığı gerçeğinden de biraz şüpheliyim.

— Jerry Coffin

3

“C yerine C ++ kullanmanın, yazılım kalitesinin artmasına ve bakım çabalarının azalmasına yol açtığını tespit ettik…” bu da hatırlanacak bir sonuçtur.

— Stephane Rolland,

24

C ve C ++ arasındaki farklar burada daha ayrıntılı olarak sıralanmıştır . Bazen insanlar birini ya da diğerini seçmek için meşru sebeplere sahip olsalar da (örneğin, C ++ 'ın ekstra özellikleri gibi göründüğü zaman, OOP veya C için C ++), benim deneyimlerime göre genellikle tercih edilir. Bu dosyada çalışan insanlar neyi daha iyi biliyor ve neyi daha çok seviyor? Bunun çoğu zaman bunun nedeni olduğuna inanıyorum, çünkü bu dillerin her ikisinin de performans açısından kritik uygulamaları ele aldıkları doğru.

(Not: Linus Torvads'ın neden C ++ 'ı C ++' ı tercih ettiğine dikkat etmiyor . Puanlarına mutlaka katılmıyorum, ancak insanların neden C ++ 'dan C'yi seçebileceği hakkında fikir veriyor. Aksine, onunla aynı fikirde olan insanlar. bu nedenlerden dolayı C'yi seçebilir.)

— Casey Patton
kaynak

51

-1Linus'un rantı için. : - {

— sbi

12

Bunun için beni eksi yapma! Haha. Linus ile aynı fikirdeyim ama bu, Niçin insanların C ++ 'dan C +' yı seçebileceğinin güzel bir örneğidir (eğer Linus'un inandığına inanırlarsa). Bu nedenlerin meşruiyeti hakkında yorum yapmıyorum.

— Casey Patton

10

@CaseyPatton: Temelde, bu retorik rantı, sanki gerçek bir argümanmış gibi yorumlanamayan her cevabı reddediyorum.

— sbi

11

@Coder: STL uygulamasını hiç bilmek zorunda değilsiniz. STL'nin asıl amacı, Standart tarafından tanımlanmayan bir davranışa güvenmediğiniz sürece, uygulamayı bilmek zorunda olmamanızdır; bu durumda, neden Standart kütüphaneyi kullanmaktan rahatsız olmuyorsunuz? Dahası, geliştiricilerin davranış şeklinden dolayı bir dili sevmemek biraz delice. C programcıları C'nin Tanrı'nın İnsan'a armağanı olduğu gibi davranırlar ve C ++ 'nın RAII gibi temelden ve özünde doğrudan C üstünlüğüne sahip olan özellikler sundukları gerçeğini göremeyecek kadar kördürler.

— DeadMG

8

@Coder: İç sayacı taşan tek bir nesneye o kadar çok paylaşılan_ptr ile karşılaşırsanız, yanlış yapıyorsunuzdur. Standart, muhtemelen 32bit'lik bir sayaç için minimum bir boyut belirleyecektir ve tek bir nesnede 2 milyardan fazla paylaşılan ptr'ye sahip olmak zorunda olması gerçekçi değildir. Nesnenin kendisi 0 boyutta olsa ve sıfır yükü eklenmiş bir bellek ayırıcınız olsa bile, o zaman hala paylaşılan_ptr'lerde 16 GB bellek tüketiyorsunuz.

— DeadMG

13

Mevcut cevaplardan eksik olan asıl sorun (bu ilanın saati itibariyle) seçimdir.

Basit. Eğer tamamen mantıksız bir sebepten dolayı, istisnaların ek yüke değmediğini düşünüyorsanız, o zaman onları kullanmak zorunda değilsiniz . Yine de şablonlara, RAII'ye ve Standart kütüphaneye sahip olabilir ve hiçbir zaman tek bir "atma" yazamazsınız. Aynı şablonlar için de geçerli. Herhangi bir sebepten ötürü, geri dönüşümsüz olduklarını (ve aslında sadece gömülü olan) çalıştırılabilir şişkinliğe neden olduğunu düşünüyorsanız, o zaman sürpriz - tüm gün boşluğu * ve sizeof (T) kullanabilirsiniz. Hiçbir şey seni C üzerinde C ++ özelliklerinden birini kullanmaya zorlamaz.

Bu nedenle C ++ doğası gereği üstün bir dildir - istediğiniz özellikleri seçebilir ve verilen bir özelliği beğenmediğinizde tekrar C-tarzı programlamaya geri dönebilirsiniz. Bu nedenle, C ++ 'nın her şey C olduğu ve daha fazlası olduğu için, C ++' nın üstün bir dil olduğu açıktır. Aksi takdirde önermek, 4'ün 5'ten büyük olduğunu önermeye çalışmak gibidir.

— DeadMG
kaynak

1

Sebeplerinizi takiben orijinal soruda hiçbir nokta yoktur ve bu nedenle kapatılmalıdır. Sanırım soru şu gibi bir şey okumalı: kendimizi ne zaman C ++ 'ın C altkümesi ile sınırlandırmalıyız (düz C kullanın) ve ne zaman tam C ++' ı kullanmak mantıklı olur?

— Giorgio

Bu doğru, ancak yalnızca bir kişinin kendi küçük projesinde çalışan vakaları için. Gerçek hayatta, neredeyse herkes zamanının yarısını başkalarının kodu üzerinde çalışarak geçirir. Maalesef diğer birçok insan bu tamamen mantıksız sebeplerle ilgili olarak "yanlış düşünür".

— DarenW

1

@DeadMG: Tahsisâtçıların istisnalar atmadan hataları bildirmeleri nasıl yapılır? Ayrıca, daha fazla özellik eklemek, tüm yaptıkları karmaşıklık veya artıklık olduğunda mutlaka daha iyi olamaz.

— Mankarse

@Mankarse: İstisnaları devre dışı bırakma seçenekleriyle derlerseniz, tahsisatçılar programı iptal eder veya kitaplık uygulamasına bağlı olarak boş bir işaretçi kullanmaya başlar.

— Zan Lynx,

4

@Mankarse: 2007'deki deneyimimden beri 1 GB RAM ve takassız bir Linux sistemi çalıştırmayı denediğimden beri, bellek ayırma işlemi yine de başarısız olduğunda hemen hemen tüm masaüstü yazılımları korkunç derecede başarısız oluyor.

— Zan Lynx,

9

C ++ 'ı C programcılarını sinirlendiren şeyler

Kaputun altında bir sürü sihir var; Yapıcılar, yıkıcılar, sanal yöntemler, şablonlar, vb., C ++ kodunu yazmayı eşdeğer C kodundan çok daha kolay ve hızlı hale getirebilir, ancak bunu anlamak ve aklınızı zorlaştırır (C ++ 'ı ve bununla ilgili kuralları ne kadar iyi bildiğinize bağlı olarak). Sınıf için yapıcının (ve buna bağlı olan herhangi bir sınıfın) nasıl tanımlandığına bağlı olarak çok fazla kod Foo newFoo;çağırabilecek kadar basit bir şeyFoo . Bu nedenle, sözleşmenin bir konteynır ++itiçinde it++yinelenmek yerine yazmak yerine yazılmasıdır , çünkü postfix ++genellikle pahalı bir kopyalama işlemini içerir.

Ne yaptığınıza bağlı olarak , özellikle basit işler için önemsiz bazı ek yükler olabilir . Aşağıdaki iki programı alın; ilki C, ikincisi C ++:

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

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

Özdeş davranış, kaynak açısından çok fazla fark yok, ancak gcc 4.1.2 ile çalıştığım SLES 10 kutusunda, bir önceki ~ 9kb boyutunda bir yürütülebilir dosya oluşturuyor, ikincisi ise 12.5kb'yi alıyor (optimizasyon yok) ), neredeyse% 28 daha büyük. C ++ stringC tipi dize kitaplığından daha IMO ile çalışmak çok daha kolay ve C akışları daha C ++ akışları çok daha esnek ve özelleştirilebilir, ama böyle gerçekten beyin ölümü kodu için, onlar olabilir havai değmezdi.

C ++, C ile karşılaştırıldığında oldukça karmaşık bir anlam ifade eden çok büyük bir dildir. C ++ 'ta uzman olmak, C'den daha uzun sürer, yani C ++' ı bildiğini iddia eden birçok insan, bildikleri kadar iyi bilmez.

C ++ programcılarını sinirlendiren C hakkında şeyler

C, hayal gücünün uzatılmasıyla güvenli bir programlama dili değildir; dizilerin sınırlarının kontrol edilmemesi, çok fazla sömürülebilir davranışa yol açar (şimdi ölü getsişlev veya ya scanfda %sve %[dönüşüm belirtecileri aracılığıyla ). C ++ en azından şu anda tanımlanmış aralığının dışına erişmeye çalışırsanız istisnalar atan kaplar verir; tüm C size (eğer şanslıysanız) bir segmentasyon ihlali verir.

C'deki bellek yönetimi çok emek yoğun ve hataya açık, C ++ araçlarına kıyasla. Kendi konteynerinizi kuruyorsanız, tüm aramaları mallocve freeçağrıları eşleştirmek , tahsislerin başarılı olduğundan emin olmak, bir hata durumunda kısmi tahsisleri yedeklemek vb. Sizin sorumluluğunuzdadır . C ++ 'ta, sadece öğeleri kaptan çıkarın. Bir sorun varsa, bir istisna atılacak.

Benzer şekilde, C'de hata işlemesi, C ++ 'nın sağladığı araçlarla karşılaştırıldığında (yani istisnalar) kıçta bir ağrıdır. Asıl eğlenceli olan şey, bir sürü bellek ayırıp işleminiz sırasında bir duvara çarptığınızda; vazgeçmeniz gerektiğinden, bu belleği doğru sırayla silmelisiniz. C ++ ve RAII ilkeleri ile bunu yapmak (nispeten) kolaydır.

Peki birini diğerine ne zaman kullanırım?

Yazdığınız bir bataklık basitse, davranışları girdiler ve çıktılar ve performans sorunları açısından açık bir şekilde tanımlanabilen uygulamadan kurtulun / uygulamadan kurtulun , sonra C ++ 'ı C' yi tercih edin. Aksi takdirde, C ++ 'ı tercih edin

— John Bode
kaynak

2

Bellek yönetimi bazı durumlarda karmaşıktır ve hataya açıktır, ancak özellikle gömülü dünyada tamamen statik bellek ayırma kullanarak C programları yazmak genellikle pratiktir. Program bağlantıları, bu olamaz zamanında bellek tükendi. Bu tür garantiler C ++ 'ta kolayca elde edilebilir mi?

— supercat

9

Bjarne Stroustrup, C ++ kullanan uygulamaların ve şirketlerin bir listesini tutar ; İsteğe bağlı olarak, OOP programlaması için istediğin gibi tartışabilirsin, ancak son 20 yılda sektör sonuçlarıyla tartışamazsın.

C ++, ayrı insanların modüler hale getirilmiş bileşenler üzerinde çalışması gereken büyük ölçekli, çok insanlı ve karmaşık projelerde yaygın olarak kullanılır . Elbette C dilinde modülerleştirilmiş kod oluşturabilir ve bakımını yapabilirsiniz, ancak C ++ 'nın doğal OOP yapısı üstün modülerleşmeye, test edilebilirliğe ve kodların yeniden kullanılmasına yol açar.

C ++ standart kütüphanesi (STL) kendi içinde sadece vektör ve haritalarla C ++ kullanmak için yeterli bir nedendir.

C genellikle gömülü sistemler için kullanılır.

Kişisel olarak C'yi yalnızca C API'si olan bir kütüphane varsa kullanırdım.

— stackoverflowuser2010
kaynak

19

Son cümleniz C kullanmak için bir neden değildir. C kütüphanelerini C ++ 'dan arayabilirsiniz.

— user207421

2

DSP projesi için c ++ kullandım - c değil

— BЈовић

9

C ++ 'dan C ++' ı seçmemin asıl nedeninin, "Bu% 1000 istikrarlı olmalı" NASA türüne başvurmam gerektiği zamandı.

C ++, performansa baktığımızda ~% 99 C'dir ve çok daha üretkendir. Böylece C'de bile C ++ 'dan daha hızlı olacak kod yazabilirsiniz (istisnalar, sanal, akış, soyutlamalar vb. Olmadan C ++ alt kümesini de kullanabilirsiniz, ancak temel olarak C), her lanet şeyi en iyi duruma getirme zamanı STL test edilmiş ve zaten yapmış olsa da, elde edeceğiniz ufak performans kazancından daha pahalıya mal olacak, ya da feda edeceğiniz için, çünkü STL algoritmaları uzman grupları tarafından yazıldı ve muhtemelen her konuda uzman değilsiniz.

Öte yandan, C ++ 'ın bir ton soyutlaması vardır. Koşullar altında sızdıklarında, bu başınızı belaya sokar. Ve C ++ 'nın% 100' ünü tanıyan çok az insan var, sanırım, tüm C gotcha'larını bilen daha var, bu yüzden her adımın bir ekibin tüm üyeleri tarafından tamamen anlaşıldığı bir çözüm yazmak C’de daha kolay

Örnek: shared_ptr<smthn>Referans sayısının ne zaman aşacağını biliyor musunuz , istisna atacak mı? Shuttle'ın atmosfere yeniden girmesi gerektiğinde bunun gibi şeyler pek havalı değil, en azından sanırım.

Ayrıca, istisna işleme hata kodlarıyla karşılaştırıldığında çok zordur. Sınıfın% 100 istisnasız güvenli olup olmadığını ve sızıntılara girmesinin kolay olup olmadığını görmek zor. Birçok yüksek temsilci bu görüşü dile getirdi.

— Kodlayıcı
kaynak

12

Ve hangi yolla manüel olarak tam olarak elle yönetme, C ++ 'gibi soyutlamalardan daha "kararlı" olur std::string? shared_ptrTezgahın taşacağı bir platform belirlemeyi hiç denedin mi? Bu eğlenceli bir platformdan biri olabilirdi. İstisna işlemenin zor olduğunu düşünüyorsanız, her işlev çağrısında olası her hatayı kontrol eden bir C koduna bir göz atmanız gerekir. (Böyle bir kodun gelmesi zor, itiraf ediyorum, ama bu sadece ifadenize karşı daha güçlü bir argüman.) Üzgünüm, ama bu gerçekten de büyük dışkılar.

— sbi

12

@ Lundin: ''% 1000 kararlı olmalı '' uygulamaları ilk etapta dinamik bellek tahsisine izin vermiyor '. Ve tam olarak bunu C ++ 'da yapmaktan alıkoyan şey nedir? (Ve herhangi bir argüman sunmak yerine bilgim ve deneyimim hakkında battaniye açıklamaları yapmak oldukça ucuz bir söylem hilesidir.)

— sbi

10

@ Lundin: Retorikten çok argümanlar sunmaya başladığın için iyi. Fakat onlar zayıf. C ++ 'ın (şablonlarının) ana özelliklerinden birini, kodu daha güvenli kılan (algoritmaların çalıştırılmasına izin verdiği için - ve dolayısıyla, derleme zamanında , çalışma zamanı hatalarını ortadan kaldıran ), "unutmuşsunuz" , yargıladığınız dili bildiğinizden yana konuşun. C ++ 'nın bir OO diline indirgenmesi burada daha önce ve iyi nedenlerden dolayı eleştirilmiştir. (Ayrıca, deterministik yıkımı olan sınıflar, hafızadan başka kaynakları yönetmek için harika bir araçtır ve yardımcıdır.)

— sbi

9

@Lundin Elbette std::stringdinamik ayırma istemiyorsanız kullanmak istemezsiniz. Kullanırdın std::basic_string<char, std::char_traits<char>, some_allocator_here>.

— Luc Danton

10

@Coder: Bunlarla ne kanıtladığını düşünüyorsun? Bunlardan birincisi sadece kötü kod (ve geri dönüş değerleri kadar kötü raporlama hataları olur), ikincisi de her yarı-terbiyeli C ++ devinin neşelendireceği manuel temizlik için RAII ve bir dava açar. Ona saygı duymak, kesinlikle katılmıyorum birkaç şey söyledi. Tek giriş-tek çıkış için taktığı fiş, 25 yıl önce öğrendiklerinin aşıldığına hiçbir zaman hemfikir olmayan, bilgisiz, yaşlı bir osuruktan kaynaklanıyor. (Ben, Bak edildi SESE son teknoloji iken 25 yıl önce, programlama.)

— sbı

6

C, programlayıcıya her şeyin tam kontrolünü sağlayarak daha iyi bir sözdizimine sahip taşınabilir bir yapıdır .

C ++ ise, emin olmak istediğinizde istenmeyebilecek birçok korkak sihir (sanal fonksiyonlar, aşırı yükleme, otomatik dönüşüm vb.) Yapar:

istediğinden daha fazla hafıza kullanma
bellek sayfalarına nilly willy erişmeyin (vtable her yerde olabilir)
kazara fazla kod çağırmayın

Ve performansa odaklandığınızdan, çalışması gerçekten kolay bir şey istiyorum.

Sadece sürprizleri yok ve bu çok değerli.

İsterseniz (ve bunu öneririm), askeri aviyonik kontrol için C ++ yazarken düşünmeniz gerekenler hakkında JSF kodlama kurallarını okuyun . Farkında olmanız gereken çok fazla tuzak var ve sizi yakalayabilir. Bjarne bu belgenin bir parçasıydı, bu yüzden ne hakkında olduğunu biliyor.

Ayrıca, C yıldırım çarpması için haşlanmış bir trol gibi derler. C ++ OTOH, muhtemelen SSD şirketlerine yatırım yapan aynı kişiler tarafından desteklendi. :)

(Şahsen, ben C ++ olsa tercih ederim, ama ben de sevmiyorum ...... ya da. ;-P)

— Macke
kaynak

1

C'nin kontrolünü sağlamadığı birçok şey var. Bir uint32_t sonucu elde etmek için bir uint32_t'yi bir uint32_t ile çarpmak için verimli taşınabilir kod yazmayı deneyin (32 bit ürün). Bir int64 bit ise, uint64_tTanımlanmamış Davranışı önlemek için en az bir işlenen atılmalıdır, ancak 32 bitlik bir sonucu hesaplamak için 64 bit atmak zorunda - bunu ılımlı bir şekilde koymak - "şaşırtıcı" dır.

— supercat

Değil. Derleyici sizin için kayıt tahsisatı gibi şeyler yapar. Bakım sırasında kod içinde, CI'de yazamıyorum.

— Nils

2

(her iki dilde de aşinalıkınız varsa)

Platformunuz için C ++ derleyicisi yoksa C ++ ile gidin. C ++ kodunu, sevdiğiniz dilin herhangi bir bölümü olmadan (sınıflar, istisnalar, sanal miras, uygulamak istediğiniz kişisel kısıtlamalar olmadan) ve sonradan bir süre sonra istediğiniz zaman karar verirseniz yazabilirsiniz. sonuçta bu özellikleri, sonra kolayca kullanabilirsiniz. C ++ 'da hiçbir şey C tarzı kod yazmanızı engellemez.

(eşdeğer araç setleri ve geliştirici bilgisi verildi) Platformunuzun bir C ++ derleyicisi olması koşuluyla, C ++ 'dan C' yi seçmek için hiçbir sebep yoktur. Kapıyı daha sonra genişletmek için açık bırakırken, bugün kendinize istediğiniz dilin alt kümesini sınırlayabilirsiniz.

— çok geçmeden
kaynak

1

Her iki dilde mükemmel. Bence bir çok poster güçlü ve her biri için çeşitli kullanımlarını detaylandırdı. Bunu basitçe ekleyeceğim:

C dilini 4 alanda mükemmel görüyorum: 1) Herhangi bir programlama türünü ilk kez öğrenirken kullanmanın en iyi dili olduğunu düşünüyorum: 1) yazılım ve 4) sistem yazılımı en düşük seviyededir.

C ++ nesne yönelimli bir dildir, ancak aynı zamanda usule dayalı olabilir (C biçiminde). Büyük ölçekli projeler, GUI tabanlı yazılımlar, oyun yazılımları ve diğer grafiksel yoğun yazılım türleri üzerinde çalışıyorsanız, en iyi seçenek olarak C ++, Java veya hatta Objective-C bulabilirim. Bununla birlikte, C ++ 'ı C'den daha iyi veya daha iyi bulabileceğiniz birçok komut satırı programı veya sistem yazılımı vardır.

— Jonathan
kaynak

0

Bence bu tartışmada eksik olan bir nokta var: C kütüphanesinde sabit bir ikili arayüz sağlamak daha kolay. Hem diğer dillerde hem de C ++ ile kullanım için.

C ++ 'da farklı derleyiciler farklı isim yönetimini kullanır, böylece kütüphaneden farklı bir derleyici ile derlenen bir kütüphanenin tüketicileri onu kullanırken sorun yaşayabilir. C ile ikili arayüz genellikle platform için standardize edilmiştir.

Günümüzde derleyicilerin genellikle gcc uyumlu şeyler üretmek için anahtarları olduğunu biliyorum, ancak bu her zaman yardımcı olmuyor.

Bunu Solaris'te nispeten sık gözlemlerim. Dağıtım ve farklı yazılım satıcıları, özellikle Sparc sistemlerinde genellikle daha iyi sonuçlar verdiği için Sun Studio'yu kullanırlar. Adam açık kaynaklı projeler olsa gcc özgü kod ile yazılmıştır. Birlikte çalışabilmek için biraz acı olabilir.

— johannes
kaynak

0

C kodu, C kodu oluşturulduğunda C ++ 'a tercih edilir (örneğin, üst seviye dillerin uygulamasında). Örneğin, C kodu yayan (örneğin Tavuk , Şema48 ...) Lisp benzeri derleyiciler var , ama orijinal C ++ kodu yayan hiçbirini bilmiyorum ( MELT aracım C ++ kodunu yayar, ancak bu kodu orijinal olarak adlandırmayacağım. C ++ kodu, çok az C ++ özelliği kullanır).

C kodu yarı otomatik olarak ispatlanması da daha kolaydır. Frama-C gibi statik analizörler (burada kodunuzla ilgili nedenlerin kanıtlanmasına yardımcı olmak için ACSL yorumlarıyla C kodunuzu eklersiniz) C için kullanılabilir, ancak C ++ 11 için çok fazla değildir.

— revile Basile Starynkevitch
kaynak