C'yi OOP döneminde bu kadar popüler yapan şey nedir? [kapalı]


91

Hem C hem de C ++ dilinde çok kod yazdım, ancak C'nin Java'nın biraz arkasında, ikinci en popüler dil olmasını beklemiyordum.

TIOBE Programlama Topluluk Dizini

Bu OOP döneminde C'nin neden bu kadar popüler olduğunu merak ediyorum. Popüler 5 programlama dilinden 4'ünün "modern", nesne yönelimli yetenekli diller olduğunu unutmayın.

Şimdi, OOP'yi bir dereceye kadar C de kullanabileceğinizi kabul ediyorum, ancak bu biraz acı verici ve inelegant (en azından sanırım C ++ ile karşılaştırıldığında). Peki, C'yi bu kadar popüler yapan şey nedir? Verimlilik; düşük seviye olmak; zaten var olan kütüphanelerin büyük çoğunluğu ya da başka bir şey?


18
video oyunları, gömülü sistemler, donanım programlama (bellenim), işletim sistemleri, vb

25
Yalnızca ölçtüğünüzü aldığınızı unutmayın - TIOBE durumunda +"<language> programming", popüler arama motorlarındaki isabet sayısı . Bir blog yazısı "Neden artık C programlama yapmıyor?" Bu indekste C saymaktadır. Heck, bu soru bile Google onu alır almaz başarabilir.

40
OOP yaşı? Bu oldukça cesur bir ifade.
Mahmoud Hossam

57
OOP'un gümüş bir mermi olduğu yanılsamasına sahipsin, o kadar çabuk kaybedersin, OOP ile ilgili özel ya da "iyi" bir şey yok, birçok kod organizasyon stratejisinden sadece biri.
Raynos

23
@DeadMG: Pot, su ısıtıcısıyla tanış. TIOBE'nin verileri güvenilir olmayabilir, ancak “popüler olmadığını” dile getiren hiçbir kel ya da kaynak belirtilmemiş. Sorunun ardındaki varsayıma meydan okuyacaksanız, en azından bunu destekleyecek bazı kanıtlar sağlayın.
Daniel Pryden

Yanıtlar:


142

Katkıda bulunan birkaç faktör:

  • C her yerde bulunur. Platform ne olursa olsun, C muhtemelen mevcuttur.
  • C taşınabilir. Bir parça temiz C yazın ve diğer platformlarda minimum değişikliklerle derlenir - hatta bazen kullanıma hazırdır.
  • C bir süredir buralardaydı. Geri UNIX dünyayı fethetti günlerde, C (seçim UNIX programlama dili) kendi dünya egemenliği içinde paylaşılan ve oldu ortak dil programlama dünyasının. Ciddi bir programcı en azından yapmak için beklenebilir bazı C bir yığın duygusunu; aynı diğer dillerin çoğu için söylenemez.
  • C hala UNIX ve UNIX aromalı sistemler için varsayılan dildir. Eğer açık kaynak topraklarda başarılı olmak için bir kütüphane istiyorsanız, oldukça iyi nedenler gerek yok C güvenle varsayabiliriz tek dil herhangi UNIX benzeri üzerinde desteklenecek olduğundan bu kısmen geleneğe bağlı olmakla birlikte, daha C. kullanmak sistemi. Kütüphanenizi C ile yazmak, bağımlılıkları en aza indirebileceğiniz anlamına gelir.
  • C basittir. Sofistike OOP veya işlevsel dillerin ifadesinden yoksundur, ancak sadeliği, çabuk toplanabileceği anlamına gelir.
  • C çok yönlüdür. Gömülü sistemler, aygıt sürücüleri, işletim sistemi çekirdekleri, küçük komut satırı yardımcı programları, büyük masaüstü uygulamaları, DBMS'ler, diğer programlama dillerini uygulama ve aklınıza gelebilecek başka bir şey için uygundur.
  • C hızlı. Çoğu C uygulaması doğrudan makine koduna derlenir ve programlayıcı, makine seviyesinde olanlar üzerinde tam güce sahiptir. Tercüman yok, JIT derleyici yok, VM ya da çalışma zamanı yok - sadece kod, bir derleyici, bir bağlayıcı ve çıplak metal var.
  • C 'serbesttir' (hem bira hem de konuşma anlamında). Standardı taşıyan ve kontrol eden tek bir şirket yoktur, aralarından seçim yapabileceğiniz birkaç uygulama vardır, C kullanımı için telif hakkı, patent veya ticari marka sorunu yoktur ve en iyi uygulamaların bazıları açık kaynaklıdır.
  • C çok fazla ivme kazanıyor. Dil onlarca yıldır popüler olmuştur, bu nedenle dili desteklemek için çok fazla sayıda uygulama, kitaplık, araç ve hepsinden öte topluluklar vardır.
  • C olgunlaşmış. Büyük değişiklikler getiren son standart C99'dur ve çoğunlukla önceki standartlarla geriye dönük olarak uyumludur. Yeni dillerden farklı olarak (Python, diyelim), yakın zamanda herhangi bir zamanda değişiklikleri bozma konusunda endişelenmenize gerek yok.
  • C uyumlu. Çoğu dilde C ile konuşmak için bağlar vardır, bu, standart çağrı kurallarını kullanarak C'de bir kütüphane geliştirebileceği ve hemen hemen başka bir dilin o kütüphane ile bağlantı kurabileceğinden emin olabileceği anlamına gelir. Yaygın kullanımdaki birkaç popüler dili isimlendirmek için: C #, Java, Perl, Python, PHP, C kütüphanelerine karşı pek sorun yaşamadan bağlantı kurabilir.
  • C güçlüdür: eğer dil bir şey yapamıyorsa, tüm popüler derleyiciler donanımın yapabileceği her şeyi yapabilen gömme birleştirme koduna izin verir. Uyumluluk konusundaki yukarıdaki nokta ile geçici olarak birleştirildiğinde, bu, C, daha yüksek seviyeli diller ile montajın "çıplak metali" arasında bir irtibat görevi görebilecek anlamına gelir.

9
Bence bütün iddiaların doğru değil. 1) C her yerde bulunur. C ++, C ++ ubiquitos gibidir, çünkü C ++ ila C derleyicileri vardır. 2) C taşınabilir. C ++ ile aynı. 3). C bir süredir buralardaydı. C ++ ile aynı. 4). C çok yönlüdür. C ++ ile aynı. 5) C hızlı. C ++ ile aynı. 6). C 'özgür'. C ++ ile aynı. 7). C çok fazla ivme kazanıyor. Yine C ++ ile aynı. 8) C olgunlaşmıştır. C ++ ile aynı. Yani aslında soruyu cevaplamıyorsun.
Konstantin Solomatov

19
C11 en son standarttır, C99 değil. Gerçekten herkesin kullandığı gibi önemli değil '89.
Pubby

53
@KonstantinSolomatov: Başkaları tarafından tüketilecek bir kütüphane yazıyorsanız, lütfen dünyaya bir iyilik yapın ve C ++ yerine C'ye yazın. Bunu yapamıyorsanız, en azından bir C API yazın. Evrendeki her şey , genellikle en az çabayla, bir şekilde veya başka bir şekilde C koduna bağlanabilir. Buna karşın, diğer dillerden bağımsız olarak, C ++ kodunu diğer C ++ kodlarından çağırmaya çalışırken sık sık önemli ABI sorunlarıyla karşılaşırsınız .
Daniel Pryden

37
@KonstantinSolomatov - C ++ 'dan C' ye derleyiciye ihtiyaç duyulduğu gerçeği, C'nin her yerde bulunabileceğini kanıtlar.
12'de

11
@KonstantinSolomatov: Lütfen C'nin C ++ olduğunu düşünmeyi bırakın. C'nin kapakları yoktur. Bazı C uzantıları (örneğin, gcc derleyici ailesi tarafından uygulananlar) gerçekleştirir, ancak C'nin kendisi (yani orijinal K&R spesifikasyonlarında veya nihai C standartlarında yer almaz).
Donal Fellows,

88

Her zaman C'nin popülerliğini evrensel bir meclis diline duyulan ihtiyaçtan dolayı suçlama eğilimindeydim. Makine düzeyinde özgüllük, standardizasyon ve olağanüstü taşınabilirlik kombinasyonunun C'nin fiili evrensel bir montaj dili olarak işlev görmesine izin verdiğini ve bu nedenle rolünün süresiz olarak devam edeceğinden şüpheliyim.

OOP programlama kurslarında iyi bir programlama için mümkün olan tek son nokta olan bir tür "final model" olarak sunulduğunda her zaman biraz şaşırdığımı belirtmeliyim. Programlamanın diğer birçok yönü gibi, OOP'un değeri, insan beyninin bilgiyi nasıl organize ettiği, toplumsal grupların uzun vadede nasıl yazılımı desteklediğini ve nesne yönelimli programlama durumunda, bazı oldukça derin yönleri içeren bir çok rekabet faktörü arasında bir uzlaşmadır. Evrenin kendisinin nasıl çalıştığını.

Ve bu son nokta biraz kırmaya değer. Belirli programlama stillerinin neden var olduğu, birlikte nasıl çalıştıkları ve gelecekte bu tür kavramlar üzerinde genişledikçe dünyanın neresinde olabileceği konusunda fizik düzeyinde bir keşifle ilgileniyorsanız daha fazla bilgi edinin ...

Fizikteki bir nesne, zaman içinde tanınabilir tutarlılığı koruyan bir şeydir. Bu da, kendimiz gibi basit yaratıkların, hayatta kalmamızı çok fazla tehlikeye düşürmeden, yalnızca az sayıda bit kullanarak nesneyi temsil etmekten kurtulmalarına izin veriyor. Ancak, büyük ölçüde fizik açısından, bu tür basitleştirmeyi kolaylaştırmak ve yaygınlaştırmak için tam olarak doğru yapmanız gereken şeylerin sayısı oldukça fazladır. İnsanlar olarak bunların hepsini düşünmüyoruz çünkü açıkçası, doğru olmasaydı burada olmazdık.

Ses çok soyut? Gerçekten değil. Örneğin, arabaların yerine hızlıca salınan plazma alanlarını ve muazzam bir hız aralığında hareket eden maddenin anlık yoğunlaşmalarını karşılaştıysanız, arkadaşınızın evine giden yolda ilerlemeye çalıştığınızı hayal edin. Böyle bir senaryo, sosyalleşme fırsatlarını derinden kesebilir, tamam mı? Biz, nesneleri ihtiyacımız olan nesneleri ve nesne varlığı etrafımızdaki çevre basitleştirilmesi muazzam ve kritik öneme düzeyde bize sağlar.

Öyleyse bunların hepsini yazılıma geri çekelim. Gerçek dünyadaki nesneler programlama açısından nesneler hakkında ne söyler?

Eh, birincisi, yazılımdaki "iyi" bir nesneyi tanımlayan şeyin, elinizde tuttuğunuz veri türünün zaman içinde tanınabilir kalıcılık fikrini destekleyip desteklememesi gerektiği anlamına gelir .

Tanımla, OOP'nin en kolay biçimlerinin tanınması kolaydır. Onlar sadece zaten "ekli" olan ya da bir kişi, ev ya da araba gibi gerçek dünyadaki gerçek fiziksel nesneler tarafından tanımlanan verileri kullanarak biraz kopyalayanlardır. Bugün bile, bu yine de insanların yazılım derslerinde aldığı nesnelerin tek tanımıdır. Bu çok kötü, çünkü önemsiz nesne yönelimli programlar bile bundan daha geniş bir tanımlamaya ihtiyaç duyuyor.

İkinci ve çok daha ilginç nesneler kategorisi ölümsüzleştirilmiş gerçek dünya olayları dediğim şeyden oluşuyor . "Ölümsüzleştirilmiş" derken , gerçek dünyada iyi tanımlanmış bir varlık ya da koleksiyon olarak en azından kısaca varolan, ancak daha sonra fiziksel olarak anlamlı koleksiyonlar olarak var olan ve dağılan şeyleri kastediyorum . Bir sempozyum harika bir örnek: Sempozyum kısa bir süre için iyi tanımlanmış bir yer ve insan topluluğu olarak var. Ne yazık ki, en iyi konferansların bile sona ermesi ve onları oluşturan parçaların diğer faaliyetlere geçmesi gerekiyor.

Ama bilgisayarları ve ağları kullanarak, biz böyle bir geçici sempozyum yapabilirsiniz görünmek yakalayan ve bir yazılım nesnesi olarak bunun bir bellek koruyarak uzun vadeli bir nesne gibi. Bilgisayarlar ve veritabanları ile yaptığımız birçok şey, gerçek evreni, fiziksel olarak var olamayacak şekillerde yakalayarak ve genişleterek daha zengin hale getirmeye çalıştığımız geçici olayların bu şekilde ölümsüzleşmesini sağlar. Örneğin, son zamanlarda gerçek bir Pandora gördünüz mü? Gerçek dünya parçalarının bu tür yakalama ve uzantıları, kendi yaşamlarımızı, ekonomilerimizi ve seçimlerimizi olağanüstü yollarla zenginleştirmeye ve genişletmeye yardımcı olur. Bu benim için nesne yönelimli programlamanın özü, en dikkat çekici etkilerinin olduğu ve olmaya devam ettiği yer.

Nihai bir OOP kategorisi, harici olaylarla yakın bağlantısı olmayan nesnelerden oluşur, ancak bunun yerine altyapıdır.Gerçek dünyadan ölümsüzleştirilmiş nesneler kullanarak devam eden gerçeklik uzantımızı desteklememiz gerekiyordu. Burası, bilgisayarın (yarı) metaline inerek, gerçek dünyanın kimyasal elementleri gibi, yeni iç dünyalar inşa etmek için hızlı ve ilginç şekillerde birleştirilebilecek kalıcı gerçeklik parçaları yaratabileceğiniz yerdir. Mobil bilgi işlem, bu tür yüksek rekombinant yaklaşımın büyümesini desteklemeye yardımcı oldu, ki bu, bir çok açıdan fiziksel dünyanın rekombinant özelliklerini taklit ediyor. Aynı zamanda zordur: İyi bir seçim, zaman içinde beklenmedik bir şekilde kötü olan bir durum olduğunu kanıtlayabilir, çünkü genellikle onu desteklemek yerine çeşitliliği ve genişlemeyi engeller.

Bu son kategori, programlama için sadece bir model kullanmanın risklerini de işaret ediyor, çünkü gerçek dünyadaki gibi, programlanmış dünyalar da gerekmeyen işlemlere ihtiyaç duyuyornispeten değişmeyen nesnelere iyi karşılık gelir. Dünya nesnelerle doludur, ancak güneş, daha düşük enerjili dünyadaki nesneleri ve etkinlikleri "tahrik etmek" için gereken son derece dinamik enerji akışlarıyla doludur. Benzer şekilde, bilgi işlem dünyaları yaratırken akışlar ve dönüşümlerle uğraşmanız gereken durumlar vardır ve hızla değişen bağlamlar, yine de kendi içinde nesneye benzemese de, daha yüksek seviyelerde kullanılan daha basit, daha insan dostu nesnelerin elde edilmesinde kesinlikle kritiktir. . Çekirdek düzeyinde yapılan programlamanın çoğunun dikkat çekici bir şekilde nesne benzeri olmaması ya da daha çok işleme odaklı olan C gibi dillere yoğun şekilde eğilim göstermesi tesadüf değildir. Bunlar bilgisayar tarafından üretilen dünyalarda daha yüksek gördüğümüz büyüleyici çeşitliliği tamamlayan daha derin alanlardır.

OOP'nin ters gidebileceği diğer alan eski nesne kavramlarına çok fazla odaklanmaktır .

Gerçek dünyadaki nesneler ve özellikle de yaşayan nesneler, çevreleriyle karmaşık ve ince şekillerde etkileşime girme konusunda kesinlikle şaşırtıcı bir yetenek düzeyine sahiptir. Birbirine bakan, bazı uyumluluk ve akıl sağlığı kontrolleri yapan ve hatta etkileşime girmenin bazı yeni yollarını bile bulabilen birleşik aletler, gerçek dünya biyolojik nesne kavramına yakın olduğumuzda basit çerçeveler ve basit kalıtım şemaları yapıyor Odak seviyesine odaklanmak (genellikle zorunlu olarak!) Bu, siber dünyadaki nesneler için büyüme alanlarından biridir, daha "ajan benzeri", çevreye reaktivitenin programlama dahilinde bile norm olduğu yaklaşımlara yaklaşır.

Ve OOP benim "eleştirisi" için çok fazla! Yine de, umarım, daha zengin bir siber dünya yaratmanın neden sadece bir tane gerekli olduğunu varsaymak yerine, programlama stillerinin çeşitliliğini kapsayan anlamına geldiğine işaret etmişimdir . Benim düşüncem, gerçekten ilginç olan şeylerin henüz gelmediği, şu anda ne yaptığımızın ne kadar fazla olduğu önemli değil!


18
Eminim "Fizik düzeyinde bir keşifle ilgileniyorsanız daha fazla okuyun" bölümüne bir kaç kişi okudu. Yapmadığım için memnunum. Bu, anlayışımızın temellerini sarsacak bir düşünce şekli ve muhtemelen kayda değer bir ilerleme kaydetmemizin tek yoludur. Güzel okuma için teşekkürler.
Matt Esch

@Raynos, $ MattEsch, ikinize de nazik sözleriniz için teşekkürler, ve ilginç bulduğunuza sevindim!
Terry Bollinger

1
Bu derin düşünce, muhteşem cevabı sadece oy kullanabilmek için siteye kaydoldum. =)
sgorozco,

2
Düşüncelerinize paralel olarak, bir süredir programlama yapıyorum ve OOP zodotu oldum, çünkü kodlama becerilerimin gerçekten benimsediğimde çarpıcı bir şekilde geliştiğini gördüm. Bununla birlikte, deneyim bana her şeyi bir nesne olmaya zorlamanın gerçekten zararlı olabileceğini göstermiştir. Şimdi sadece kablo üzerinden gerekli olan doğru miktarda ikili veriyi gönderen basit bir ikili protokol ile karşılaştırıldığında% 1000 bant genişliği tüketen nesne-ilişkisel haritalama araçları (ne dağınıklık) veya tam nesne-grafik serileştirme şemalarına kısıldım an Güzel okuma için teşekkürler.
sgorozco

2
Bu cevap aynı zamanda neden hala SQL'e ihtiyacımız olduğuna cevap veriyor!
HLGEM

25

Öncelikle, bu konuda ne tür dogmalar popülerse de, her şey için OOP'ye ihtiyacınız yok. Java'nın aksine, C, işlevsel göstergelere kapı açan ve OOP'un ele aldığı sorunlu alanın bir parçasını çözen işlev göstergelerine ve hatta kapanmalarına izin verir , çünkü bağımlılık enjeksiyon araçlarını sağlar. Ayrıca , sglib'in kanıtladığı gibi, makroların ihtiyatlı kullanılması da gerçekten çok hoş şeyler yaratabilir .

Tuhaf bir şekilde, C, Java ve C ++ arasında iyi bir uzlaşma olarak görülebilir. Ben am unutmayınız değil C hiçbir şekilde ikisi için birlikte olduğunu söyleyerek. Ancak Java'nın aksine, oldukça güçlü bir dil iken, C ++ 'ın aksine yönetilebilir bir karmaşıklığa sahiptir.

Gerçekten daha karmaşık bir şekilde gelişmese de, güvenilir ve tutarlı bir biçimde büyüyen eski bir dildir. Ve bunların hepsi bir yana, devasa bir eko sistemi var ve sadece her yerde çalışıyor.


11
İşlevsel programlama harika, bu konuda bir itiraz yok. Fakat C, işlevsel programlama için oldukça kötü bir dildir. Kapaklar / bloklar taşınabilir olmayan kesitlerdir ve çirkin sözdizimi ile gelirler (hem de gotchas, iddiaya girerim). Bunları görmezden bile olsa, bellek yönetimi ile ilgilenmeye devam etmeniz gerekir. C faydalı bir dildir, ancak herhangi bir dilde olduğu gibi, sadece sizin için yapılmayan bir paradigma kullanmak için suistimal ediyorsanız hayatınızı olması gerekenden daha zorlaştırıyorsunuz. İşlevsel programlamayı da Java'da taklit edebilirsiniz (bkz. Guava ), ancak bu da hoş değil.

7
Çöp toplayıcı olmadan işlevsel bir şekilde programlanması çok zordur.
Konstantin Solomatov

@KonstantinSolomatov: İlk olarak, bu çok öznel. İkincisi, gerekirse C'ye çöp toplama ekleyebilirsiniz.
back2dos

Java ile C ++ arasında bir uzlaşma istiyorsanız, Obj-C :) yi deneyin. Kesinlikle her C / C ++ programcısının denemesi gereken bir şey var.
Sulthan

21

C'nin ABI (Uygulama İkili Arabirimi) var C ++ yok. Bu, C'yi belirli durumlarda C ++ 'dan daha kullanışlı kılar. Bir kütüphane yazıp başkalarının kullanımı için ikili dosyaları gönderebileceksem, C ++ iş için yanlış bir araçtır. Başka bir dil tarafından kullanılacak olan kütüphaneleri tekrar yazacaksam, C bu iş için doğru araçtır. FFI'yi (Yabancı İşlev arayüzü) C'ye desteklemeyen bir dili hiç duymadım, diğer yandan C ++, farklı derleyiciler kullanılıyorsa C ++ ile yazılmış kütüphanelerle çalışmaz.

Temel olarak, C ++ 'nın uygun olmadığı bir rolü doldurmak üzere C'ye kaynar.


2
Mmm .. bir C, domates ve peynirli rulo!
DeadMG

3
Peki, C ++ 'da ABI var. Sadece C ABI kaya gibi sağlam, C ++ ise çok sık değişiyor. Ayrıca bir sürü C ++, kullanılan uygulamaya derlenmiş şablonlardır, bu nedenle güncelleyemezsiniz. Tüm işlevler işlev çağrılarının arkasına gizlendiğinde, kitaplığı düzeltmek ve uygulamayı çalışır durumda tutmak mümkündür.
Jan Hudec

12

C ++ ya da Java gibi diller üzerinde C kullanmanın bir avantajı da kaputun altında pek fazla büyü olmaması. Öğeler tahsis edildiğinde hiçbir kurucu çalıştırılmaz ve nesneler kapsam dışına çıktığında hiçbir yıkıcı çalıştırılmaz. Mangling yok ve vible yok. Performansı tahmin etmek daha kolaydır; Bir rutini yarıda kesen ve zamanını boşa harcayan bir çöp toplayıcı için endişelenmenize gerek yoktur.

Kurucu ve yok ediciler, adı bozma, vtables, çöp toplayıcılar, vb kod yazar karmaşıklık bazı azaltabilir fakat daha sonra bu karmaşıklık dilin kendisi bir parçası haline gelir bunun üzerinde hiçbir kontrole biraz var . Daha uzun derleme süreleri (can sıkıcı, ancak tolere edilebilir), daha büyük çalışma zamanı belleği ayakizi (tolere edilebilir veya olmayabilir) veya daha yavaş performansla kurulabilir. C ile ihtiyaç duyduğunuz işlevsellikten ayrılana kadar bu karmaşıklığın bir kısmını ortadan kaldırabilirsiniz .

Örneğin, C ++ stringveri türü, C tarzı dizelerle çalışmak için hafif yıllar daha kolaydır, ancak oldukça ağır bir kod parçasıdır ve görüntü boyutunuza biraz ağırlık ekler. stringBir programda yeteneklerini tam olarak kullanan birini nadiren gördüm . C tarzı karakter dizileri, çalışmak zor olsa da, çalışma süresi ve görüntü boyutu bakımından daha az ceza alır ve belirli bir sorun için bu nedenle daha çekici olabilir.


2
Çalışma süresinin cezası saçmalıktır. C dizeleri (boş bırakılmış) C ++ dizgilerinden çok daha az verimlidir. Ayrıca, bir dize sınıfı C'yi kadar küçük olabilir, bütün stdiçine sürüklemediğiniz sürece .
Pubby

1
stringCRT'yi statik olarak bağlarsanız kullanılmayan fonksiyonları kullanmayan bir alet zinciri, tuzuna değmeyen bir alet zinciridir.
Billy ONeal

10
Aptalca, yeterincestd::string sofistike olmadığı bir kütüphaneyle çalışıyorum . Hem performans hem de yetenekler açısından karakter dizileri konusunda gerçekten ciddiyseniz, char*emin olmak için düz eskileri kullanmamakla birlikte, tekrar C ve tekrar kullanmaya başlıyorsunuz . (Teller şaşırtıcı bir şekilde karmaşıktır, onların karmaşık olmasını beklemeseniz bile.)
Donal Fellows

1
@DonalFellow İlginç. İşte bu yüzden, C standardı her zaman dizeleri ve karma tabloları gibi şeyleri bırakmıştır, bunların yokluğu bazen beni rahatsız ediyor.
Mühendis

@ ArcaneEngineer: C'deki temel eksik veri tipi, bir T * ile bir size_t birleştiren, bir dizi gibi indekslenebilen, bir T * içinde parçalanabilen ve dolaylı olarak dönüştürülebilen bir "dilim T []" türüdür. Herhangi bir T [n] tipinde (derleyici tarafından otomatik olarak tedarik edilecek boyutta). Böyle bir tür, birçok durumda diğer tür kodları daha temiz ve okunaklı kılarken, bunun mümkün olmadığı birçok durumda otomatik sınır kontrolüne izin verebilir.
supercat

11

Gömülü sistemler ve sürücüler genellikle C dilinde programlanır. Bunun dışında, hala devam ettirilen ve genişletilen tonlarca eski C sistemi vardır.


2
Evet, C her şey üzerinde çalışır. Dil öğrenmek oldukça kolay (c ++ 'a kıyasla).
BenjaminB

10

El çekiçini, havalı çekiçler (havalı çekiçler) çağında popüler kılan aynı şey: C, hala bazı işler için doğru araçtır.


6

Sadelik, tutarlılık ve hassasiyet.

Çok basit - karmaşık bir geliştirme ortamına, kapsamlı kütüphanelere veya sanal bir makineye ihtiyacınız yok.

Tutarlı - 10 yıl önce yazılmış çoğu C bugün derleyebildi.

Hassasiyet - gerektiğinde bellek konumlarını bilerek makinenin seviyesine inmenizi sağlar. Bu performans ve gömülü donanım için mükemmeldir.

Her şey için değil, hala yararlı bir araç.


5
Daha da iyisi, bu kod adil bir şans var derlenmiş 10 yıl önce olabilir yürütmek bugün.
Donal Fellows,

@DonalFellows: Eklentileri kullanan uygulamalar için, bugün (çalıştırılabilir biçimde) yazılmış, derlenmiş ve yayımlanmış bir uygulamanın (bile çalıştırılmayan) derlenmiş eklenti araçlarını kullanarak derlenmiş eklentileri kullanabilme olasılığı oldukça yüksektir. henüz tasarlandı.
supercat

6

Başka bir cevabın iki puanından bahsettim, çünkü tam olarak hala C'yi kullanmamın nedenlerini tam olarak anlıyorlar (yine de ana seçim dili değil):

  • C basittir. Sofistike OOP veya işlevsel dillerin ifadesinden yoksundur, ancak sadeliği, çabuk toplanabileceği anlamına gelir.
  • C olgunlaşmış. Büyük değişiklikler getiren son standart C99'dur ve çoğunlukla önceki standartlarla geriye dönük olarak uyumludur. Yeni dillerden farklı olarak (Python, diyelim), yakın zamanda herhangi bir zamanda değişiklikleri kırma konusunda endişelenmenize gerek yok.

Bence bu çok doğru. C'lerin ilk gecelerinde C öğrendim: basitti, birkaç anahtar kelime ve yapı, çoğu kütüphaneler tarafından yapıldı. O zaman C'yi birkaç yıl kullanmadım. 2002 civarında hızlı bir algoritma uygulamasına ihtiyacım vardı, bir C derleyicisi kurdum ve uyguladım. Dili biliyorum, neyin iyi olduğunu, neyin iyi olmadığını ( C de bir web uygulamasını asla uygulayamam!) Biliyorum ve tam ihtiyacım olduğunda orada. Sürpriz yok.

C ++ ile farklı bir deneyim yaşadım. 1995 yılında öğrendim ve bu zorunluluktan OOP'ye büyük bir paradigma geçişi anlamına geliyordu. Harika! 1999'a kadar birkaç projede kullandım. Birkaç yıl boyunca C ++ kullanmamıştım ve tekrar aldığımda (2008) zaten dilde ve hatta daha planlı olan birçok yeni özellik buldum (bu arada C ++ 'da tanıtıldı). 11). Dili tekrar öğrenmem gerektiğini hissediyorum.

Bir geliştirici olarak, olgun ve kararlı dilleri tercih ederim. Bir kez bir dil öğrenmek, tasarım ilkelerini anlamak, neyin iyi olduğunu ve iş için doğru araç olduğunu düşündüğümde kullanmayı seviyorum. Ayrıca farklı diller öğrenmeyi ve ihtiyacımı karşılayan dili seçmeyi de seviyorum (C, C ++, Java, Scala, Haskell, vb.). Sevmediğim şey, aynı dili tekrar tekrar öğrenmek zorunda çünkü daha ileri ve daha da gelişiyor ve asla olgunluğa ulaşmıyor.

IMHO, bir programlama dili açık, tutarlı ve sağlam bir tasarıma sahip olmalıdır. Niklaus Wirth gibi tasarımcıların yaklaşımını seviyorum: Her ne zaman farklı bir dile duyduğunu hissettiğinde, yeni bir tane tasarladı (Pascal, Modula-2, Modula-3, Oberon). Her 5-10 yılda bir önemli değişikliklere uğrayan dilleri sevmiyorum: onlar hareketli hedefler gibiler ve onları derinlemesine öğrenmek için zamanımı harcamanın asla değersiz olduğunu düşünmüyorum, çünkü şimdi öğrendiğim sürüm muhtemelen birkaç yıl içinde eski olacak Yine de yıllar.

Bu anlamda C, IMO'nun kazananıdır: belirli uygulamalar için iyidir ve diğerleri için daha az uygundur, ancak basit ve göreceli olarak istikrarlı olması avantajına sahiptir.


4

Henüz kimsenin Worse Is Better'den bahsetmediğine şaşırdım . Bu noktada 20 yaşın üzerindedir, ancak okumaya kesinlikle değer. Bazen hafifçe yanak dili olsa da, yol göstericinin sık sık idealin üzerinde nasıl ve neden kazandığını, C'yi (LISP'ye karşı çukurlu) merkezi örneklerinden biri olarak seçerek iyi bir iş çıkardı.


İngilizce, PHP, Windows: 'Kötü ama daha iyi' kategorisine koyduğum şeyler. .. McDonald's belki. Yine de İspanyolca, Python, Linux ve Artisan Fransız Yemeklerini kıskanıyorum / tercih ediyorum; Genel olarak mümkün değilse, mümkün olduğunca.
ThorSummoner

1

Bir C derleyiciniz varken genellikle C ++ derleyiciniz olmasına rağmen, neden insanların C ++ yerine C kullandığını sormak istemişsinizdir.

  • C dili, C ++ 'dan daha basittir. Kodlama kurallarında C ++ standardının tamamını kullanan hiçbir şirket tanımıyorum. Örnek olarak Google’ın C ++ kod stiline bir göz atın: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
  • C derlemek için çok daha hızlı. Derlemesi zor yapıların olmayışı sayesinde.

Bu bağlantı koptu.
ar2015

0

Hiçbir şey değil. TIOBE değersiz bir endekstir. Aslında onların ölçümüne bakarsanız, en iyi ihtimalle kesin bir tahmin.


10
TIOBE'nin değersiz olduğu gerçeği C'nin popüler olmadığı anlamına gelmez
Raynos

Bununla birlikte, OP’de sunulan argümanı, C’nin popüler olduğu ve bu nedenle bir miktar kullanımı olması gerektiği gibi, kesinlikle ortadan kaldırmaktadır.
DeadMG

2
C'nin popülaritesinin daha iyi bir ölçüsü, hemen hemen her platformun bir C derleyicisine sahip olmasıdır
Raynos

@Raynos: Bu hiç bir ölçüm değil. Bu demek olan tek şey, uygulamasının kolay olmasıdır. Kaç kişinin kullandığı ya da neden olduğu hakkında hiçbir şey söylemez.
DeadMG

2
Tamamen değil, muhalif bakış açılarını memnuniyetle kabul ediyorum. Bir satırlık cevabınız çok az düşünülmüş gibi görünüyor ve siz cevaplarınızla tartışmacı ve yapıcı değilsiniz.
mattnz

0

Çok Eski Yazılım

Birçok şirket, kodlarını anında C ++ veya benzeri bir şekilde değiştiremez.

Birçok şirket kodunu değiştiremez.

Birçok şirket kodunu değiştirmeyi göze alabilir, ancak umursamıyor veya "ucuz".

Birçok şirket göç sürecinde ancak henüz bitmedi.

Gizli Nesne Yönü

(Nesneye Yönelik Olmayan) Nesne Yönelimli C kaynak kodu olarak tasarlanan C kaynak kodu, Nesne Yönlendirme ile modellenen ve "saf C" ile kodlanan uygulamalar veya "C ++" veya diğer OO programlarından çeviri yapan araçlar. c. içine

Bazı video oyunlarının bu şekilde yapıldığını duydum. Bazı çapraz platform araçları ve GNome Linux işletim sistemi dağıtımları için GTK (GObject, GLibrary) görsel arayüz kütüphanesi.


3
Bu cevabın ikinci yarısının deobfuscated edilmesi gerekiyor.
aramis

@aramis. İkinci bölüm şu anlama gelir: Pek çok kod doğrudan "C" 'de donde görünüyor, ancak aslında başka bir dilde ve "C" ye
çevrilmiş

0

Cevaplayıcıların bazılarının neden C'nin en popüler olduğunu, uzun zamandır ortalıkta olduğunu, çoğu platformda, ücretsiz vb.

Ancak aynı şey diğer diller için de söylenebilir, örneğin ücretsiz Pascal - ücretsiz ve hemen hemen tüm platformlar için desteklenir.

Pascal 1970'lerde icat edildi, C 1972'lerde icat edildi, bu yüzden Pascal'ın C kadar uzun süredir bulunduğunu düşünüyorum.

Şahsen, C'nin en popüler dil olduğunu düşünüyorum çünkü orada herkes tarafından tekrar kullanılmak üzere daha açık kaynak kodları mevcut. Ve evet, Pascal'dan daha düşük seviyedeydi, bu yüzden montaja yaklaşıyor ama montaja göre daha okunaklı.

Dışarıda çok fazla programlama dili olduğunu düşünüyorum. Programcılar olarak, önemli olanların çoğunu bilmek zorundayız, ama sonunda buna gerek kalmamalı. Web sitelerini oluşturmaktan iOS bilgisayar oyunlarına kadar hepsini yapmak için bir programlama dili uygulanabilir.

C bu küresel dil gibi gözüküyor, ancak keşke Object Pascal gibi bir şey olsaydı. Neden Nesne Pascal, bu daha okunaklı bir programlama dilidir, OOP kodu C'ye göre daha fazla yeniden kullanılabilir ve daha az hataya eğilimlidir (bence).

Object Pascal ile yönetilmesi çok büyük uygulamaların C / C ++ 'dan daha kolaydır.

'70'ten beri bazıları olan bir programlama dili olması ve her 5 veya 10 yılda bir değişen dillerden hoşlanmaması. Zaman geçtikçe teknoloji ilerler ve programlama yöntemleri geliştirilir. Bir dil her birkaç yılda bir ciddi şekilde değişirse, o zaman muhtemelen tasarımcı tarafından iyi düşünülmedi. Ancak 1970 - 2012 yılları neredeyse yarım yüzyıldır, o dönemde bir dilde Yazılım geliştirmede kullanılan gelişmeleri içerecek şekilde değişiklik yapmak mümkündür.

C'nin kendisi birkaç kez revize edildi. Dolayısıyla bu bakış açısını diğer dillerden daha iyi değil.


3
Pascal ile ilgili bir problem, dilin "resmi" versiyonunun çok gerekli bazı özellikleri dışarıda bırakmasıydı. Bir süredir, hem PC hem de Macintosh, o sırada varolan herhangi bir C derleyicisinden çok daha kullanışlı olan Pascal derleyicilerine sahipti, ancak bu derleyiciler herhangi bir "resmi" standart tarafından desteklenmeyen dil uzantıları eklediler. Bence, bu tür uzantıları kodlayan resmi bir standart oluşturma çabası olsaydı, Pascal, "C" olarak bilinen bir dil kesmesini değiştirmiş olabilirdi.
supercat

0

Çünkü C'nin çok büyük bir kullanıcı tabanı var. Evet, bir catch-22 biraz, ancak StackOverflow üzerinde C hakkında bir soru sorduğumda, neredeyse anında cevap alıyorum. Python ile ilgili aynı soruya cevap verilmesi saatler alabilir.

C ++ 'ya gelince, IMO öğrenmek daha karmaşıktır. Ayrıca, 10 yıl boyunca OOP'yi denedikten sonra, bunun her zaman faydalı olmadığını ve çoğu zaman prosedürel programlamanın kullanılmasının daha kolay olduğunu düşünüyorum.


C # veya Java için sorulan SO sorularını karşılaştırdınız mı?
tatarcık

@gnat, C v Python'un (bu arada sorulan daha fazla sorusu olan!) izole edilmiş bir örneğiydi. Ben C # ile hiçbir deneyime sahip (sen benim fark ettiniz değil C # veya jav için SO soru soruyorsun?)
puk

Heh, StackOverflow'ta #python topluluğunu hemen hemen her zaman süper hızlı buluyorum. Yine de, C topluluğu javascript topluluğunu yanıtlama hızı için geride bıraksa şaşırırdım. (Çoğunlukla cilt yüzünden)
ThorSummoner
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.