İnsanlar bu kadar tehlikeliyse neden C kullanıyorlar?

C öğrenmeyi düşünüyorum

Ancak insanlar 'tehlikeli' olarak kullanılıyorsa neden C (veya C ++) kullanıyorlar?

Tehlikeli olarak, işaretçilerle ve benzeri şeylerle kastediyorum.

Yığın Taşması sorusu gibi Alınan işlev neden kullanılmaması gerektiği kadar tehlikelidir? . Programcılar neden Java veya Python veya Visual Basic gibi derlenmiş başka bir dil kullanmıyorlar?

1. C, düşündüğünüz diğer dillerin çoğundan önce gelir. Programlamayı "daha güvenli" hale getirme konusunda şimdi bildiklerimizin çoğu C gibi dillerden geliyor

2. C'den beri ortaya çıkan daha güvenli dillerin çoğu, daha geniş bir çalışma süresine, daha karmaşık bir özellik kümesine ve / veya hedeflerine ulaşmak için sanal bir makineye dayanıyor. Sonuç olarak, C tüm popüler / ana diller arasında "en düşük ortak payda" olarak kalmıştır.

   • C uygulaması çok daha kolay bir dildir çünkü nispeten küçüktür ve en zayıf ortamda bile yeterince performans gösterme olasılığı yüksektir, bu nedenle kendi derleyicilerini ve diğer araçlarını geliştirmesi gereken birçok gömülü sistemin işlevsel bir derleyici sunması daha olasıdır C için

   • C çok küçük ve çok basit olduğundan, diğer programlama dilleri, C benzeri bir API kullanarak birbirleriyle iletişim kurma eğilimindedir. Bu, muhtemelen çoğumuzla sarmalayıcılar aracılığıyla etkileşime girse bile, C'nin asla gerçekten ölmemesinin ana nedenidir.

3. C ve C ++ 'da geliştirmeye çalışan "daha güvenli" dillerin birçoğu, programınızın bellek kullanımı ve çalışma zamanı davranışları üzerinde neredeyse tamamen kontrol sahibi olan "sistem dilleri" olmaya çalışmıyor. Günümüzde gittikçe artan sayıda uygulamanın bu kontrol seviyesine ihtiyaç duymadığı doğru olsa da, gerektiğinde her zaman küçük bir avuç gerekli olacaktır (özellikle, tüm bu güzel, güvenli dilleri uygulayan sanal makineler ve tarayıcılar içinde). geri kalanımız).

   Bugün, C veya C ++ 'dan daha güvenli olan birkaç sistem programlama dili (Rust, Nim, D, ...) vardır. Gezinme avantajlarına sahipler ve çoğu zaman, böyle ince kontrolün gerekli olmadığını anlıyorlar, bu yüzden gerçekten gerekli olduğunda değiştirilebilecek birkaç güvenli olmayan kanca / mod ile genel olarak güvenli bir arayüz sunun.

4. C içinde bile, pratikte ortaya çıkan sinsi böcek sayısını büyük ölçüde azaltma eğiliminde olan birçok kural ve kılavuz öğrendik. Bu kuralları geriye dönük olarak uygulamak için standardın elde edilmesi genellikle imkansızdır, çünkü bu çok fazla varolan kodu kıracaktır, ancak bu kolayca önlenebilir sorunları saptamak için derleyici uyarıları, çizelgeleri ve diğer statik analiz araçlarını kullanmak yaygındır. Bu araçları uçan renklerle geçen C programlarının alt kümesi zaten "sadece C" den çok daha güvenlidir ve bu günlerde herhangi bir yetkili C programcısı bazılarını kullanacaktır.

Ayrıca, hiçbir zaman şaşkın bir Java yarışması yapmak, şaşkın bir C yarışması kadar eğlenceli olmayacaktır .

İlk olarak, C bir sistem programlama dilidir. Örneğin, eğer bir Java sanal makinesi veya bir Python yorumlayıcısı yazarsanız, bunları yazmak için bir sistem programlama diline ihtiyacınız olacaktır.

İkincisi, C, Java ve Python gibi dillerin sunmadığı performansı sağlar. Genellikle, Java ve Python'daki yüksek performanslı bilgi işlem, ağır kaldırma işlemini yapmak için C gibi yüksek performanslı bir dilde yazılmış kütüphaneleri kullanır.

Üçüncüsü, C Java ve Python gibi dilden çok daha az yer kaplar. Bu, büyük çalışma zamanı ortamlarını ve Java ve Python gibi dillerin bellek taleplerini desteklemek için gerekli kaynaklara sahip olmayabilir gömülü sistemler için kullanılabilir.

Bir "sistem programlama dili", endüstriyel güç sistemlerini oluşturmak için uygun bir dildir; Durdukları gibi, Java ve Python sistem programlama dilleri değildir. "Tam olarak bir sistem programlama dili yapan şey" bu sorunun kapsamı dışındadır, ancak bir sistem programlama dili temel platformla çalışmak için destek sağlamalıdır.

Öte yandan (yorumlara yanıt olarak) günü, bir sistem programlama dili yok değil kendi kendine barındırmayı olması gerekir. Sorulan orijinal soru "neden insanlar C kullanırım" çünkü bu sorun, PYPY olduğunda ilk açıklama "neden C gibi bir dil gerekir" sordu, ben PyPy kaydetti, geldi geliyor aslında Yani C kullanın onu Başlangıçta soru ile ilgiliydi, fakat ne yazık ki (ve kafa karıştırıcı olarak) “kendini barındırma” aslında bu cevaba bağlı değil. Üzgünüm, ben büyüttüm.

Yani, özetlemek gerekirse: Java ve Python, birincil uygulamaları yorumlandığından ya da yerel olarak derlenen uygulamalar kendiliğinden barındırılmadığından, temel platformla çalışmak için gerekli desteği sağlamadıkları için programlamaya uygun değildir.

Başka bir cevap eklediğim için üzgünüm, fakat mevcut cevapların hiçbirinin doğrudan ilk cümlenizi belirttiğini sanmıyorum:

'C öğrenmeyi düşünüyorum'

Neden? C'nin günümüzde genellikle kullandığı şeyleri yapmak ister misiniz (örn. Aygıt sürücüleri, sanal makineler, oyun motorları, medya kütüphaneleri, gömülü sistemler, işletim sistemi çekirdekleri)?

Eğer evet ise, o zaman evet, hangisinin ilgilendiğinize bağlı olarak C veya C ++ öğrendiğinden emin olun. Bunu öğrenmek ister misiniz, böylece üst düzey dilinizin ne yaptığını daha iyi anlarsınız?

Daha sonra güvenlik kaygılarını dile getirmeye devam edin. Mutlaka bir gerekmez derin bir üst düzey dilde bir kod örneği üretim hazır olmadan size özünü verebilir, aynı şekilde, ikincisi yapılacak güvenli C anlaşılmasını.

Özü bulmak için bir miktar C kodu yaz. Sonra tekrar rafa koyun. Üretim C kodunu yazmak istemediğiniz sürece güvenlik konusunda çok fazla endişelenmeyin .

Bu, tonlarca cevabı olan BÜYÜK bir sorudur, ancak kısa versiyon, her programlama dilinin farklı durumlar için uzmanlaşmış olmasıdır. Örneğin, web için JavaScript, düşük seviyeli şeyler için C, Windows için C #, vb. Hangi programlama dilini seçeceğinize karar vermeyi öğrendikten sonra ne yapmak istediğinizi bilmenize yardımcı olur.

Son noktanıza hitap etmek için, neden C / C ++ ile Java / Python kullanıyorsunuz? Oyunlar yapıyorum ve Java / C # son zamanlarda oyunların çalışması için yeterince iyi olan hızlara ulaşıyor. Sonuçta, oyununuzun saniyede 60 kare hızında çalışmasını istiyorsanız ve oyununuzun çok çalışmasını istiyorsanız (renderleme özellikle pahalıdır), kodun mümkün olduğu kadar çabuk çalıştırılması gerekir. Python / Java / C # / Pek çok kişi, "tercümanlar" üzerinde çalışıyor, C / C ++ 'nın kullanmadığı tüm sıkıcı işleri yapan, bellek ve çöp toplama gibi ek bir yazılım katmanı. Bu ek yükü işleri yavaşlatır, bu yüzden hemen hemen her büyük oyun (son 10 yılda, yine de) C veya C ++ ile yapıldı. İstisnalar var: Unity oyun motoru C # * kullanıyor ve Minecraft Java kullanıyor, ancak kural dışı durum onlar. Genel olarak,

* Birlik bile tüm C # değil, bunun büyük parçaları C ++ ve oyun kodunuz için sadece C # kullanıyorsunuz.

EDIT Bunu yayınladıktan sonra ortaya çıkan yorumların bir kısmına cevap vermek için: Belki de fazlasıyla basitleştiriyordum, sadece genel resmi veriyordum. Programlama ile cevap asla basit değildir. C tercümanları var, Javascript tarayıcının dışında çalışabilir ve C # Mono sayesinde hemen hemen her şeyi çalıştırabilir. Farklı programlama dilleri, farklı alanlar için uzmanlaşmıştır, ancak bazı yerlerdeki bir programcı, herhangi bir dilin herhangi bir bağlamda nasıl çalışacağını çözmüştür. OP fazla programlama bilmiyor gibi göründüğü için (benim açımdan varsayım, yanılıyorsam özür dilerim), cevabımı basit tutmaya çalışıyordum.

C # hakkındaki yorumlara gelince, neredeyse C ++ kadar hızlı olduğu için anahtar kelime neredeyse var. Üniversitedeyken birçok oyun şirketini gezdik ve öğretmenim (bizi yıl boyunca C # ve C ++ 'dan uzaklaşmaya teşvik eden) öğretmenim her şirkette programcılara neden C ++' dan C # 'ya gittiğini sordu. dedi C # çok yavaş. Genelde hızlı çalışır, ancak çöp toplayıcı performansa zarar verebilir, çünkü ne zaman çalıştığını kontrol edemezsiniz ve ne zaman çalıştırmanızı istemediğinizi belirtmek istemiyorsa sizi görmezden gelme hakkına sahiptir. Yüksek performansa sahip bir şeye ihtiyacınız olursa, tahmin edilemez bir şey istemezsiniz.

"Sadece hızlara ulaşma" yorumuma cevap vermek için evet, C # hız artışlarının çoğu daha iyi bir donanımdan geliyor, ancak .NET framework ve C # compiler ilerledikçe, orada bazı hızlandırmalar oldu.

"Oyunlar motorla aynı dilde yazılmış" hakkında, yorumuna bağlı. Bazıları, ancak birçoğu dillerin melezinde yazılmıştır. Unreal, UnrealScript ve C ++ yapabilir, Unity C # Javascript ve Boo yapar, C veya C ++ ile yazılmış birçok motor Python veya Lua'yı betik dili olarak kullanır. Orada basit bir cevap yok.

Ve "oyununuz 200fps veya 120fps'de çalışıyorsa kimin umurunda olduğunu umursam" demem için beni rahatsız ettiğinden dolayı, eğer oyun 60fps'den daha hızlı çalışıyorsa, ortalama monitör bile yenileyemediğinden muhtemelen cpu zamanını boşa harcıyorsunuzdur. hızlı. Bazı yüksek sonlar ve yeni olanlar bunu yapar, ancak standart değildir (henüz ...).

Ve "onlarca yıllık teknolojiyi görmezden gelme" sözleriyle ilgili olarak, hala 20'li yaşlarımın başındayım, bu nedenle geriye doğru ekstrapolasyon yaparken, çoğunlukla daha yaşlı ve daha deneyimli programcıların söylediklerini tekrarlıyordum. Açıkçası, böyle bir sitede itiraz edilecek, ancak dikkate değer.

C’nin güvenilmez olduğunu iddia etmeniz komik, çünkü "göstericileri var". Bunun tersi doğrudur: Java ve C # pratik olarak sadece işaretçilere sahiptir (yerel olmayan türler için). Java’daki en yaygın hata muhtemelen Null Pointer İstisnasıdır (bkz. Https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare ). İkinci en yaygın hata, muhtemelen kullanılmayan nesnelere (örneğin, kapalı Diyaloglar atılmamıştır) bu nedenle bırakılamayan, sürekli büyüyen bir bellek ayak izi ile uzun süre çalışan programlara yol açan gizli referanslar tutmaktır.

C # ve Java'yı daha güvenli ve iki farklı şekilde daha güvenli hale getiren iki temel mekanizma vardır:

• Çöp toplama, programın atılan nesnelere erişme girişiminde bulunma olasılığını azaltır. Bu, programın beklenmedik şekilde sonlandırılması olasılığını azaltır. C'nin aksine, Java ve C # varsayılan olarak yerel olmayan verileri dinamik olarak tahsis eder. Bu, program mantığını aslında daha karmaşık hale getirir, ancak yerleşik çöp toplama - bir ücret karşılığında - zor kısmı üstlenir.

Son C ++ 'akıllı işaretçiler, programcılar için bu işi kolaylaştırıyor.

• Java ve C #, ayrıntılı bir çalışma süresi tarafından yorumlanan / yürütülen bir ara kod oluşturur. Bu, bir güvenlik düzeyi ekler çünkü çalışma zamanı bir programın yasadışı faaliyetlerini tespit edebilir. Program güvenli bir şekilde kodlanmış olsa bile (her iki dilde de mümkündür), teoride ilgili çalışma süresi sisteme “dağılmasını” önler.
  Çalışma süresi, örneğin denenmiş tampon taşmalarına karşı koruma sağlamaz, ancak teoride bu tür programların istismarına izin vermez. C ve C ++ ile ise, programcının istismarları önlemek için güvenli bir şekilde kodlaması gerekir. Bu genellikle hemen elde edilemez, ancak gözden geçirmeler ve yinelemeler gerekir.

Ayrıntılı çalışma zamanının aynı zamanda bir güvenlik riski olduğunu da belirtmekte fayda var. Bana göre, yeni keşfedilen güvenlik sorunları nedeniyle Oracle JVM'yi birkaç haftada bir güncelliyor. Elbette, JVM'yi doğrulamak tek bir programdan daha zordur .

Bu nedenle, ayrıntılı bir çalışma süresinin güvenliği belirsizdir ve bir dereceye kadar aldatıcıdır: Ortalama C programınız, incelemeler ve yinelemeler ile makul derecede güvenli hale getirilebilir. Ortalama Java programınız sadece JVM kadar güvenlidir; bu, gerçekten değil. Asla.

Hakkında gets()yazdığınız makale , temel dilden değil, bugün farklı şekilde uygulanacak olan tarihi kütüphane kararlarını yansıtmaktadır.

"Güvenlik" hızlandığından, "daha güvenli" diller daha yavaş performans gösterir.

Neden C veya C ++ gibi "tehlikeli" bir dil kullandığınızı, birisinin size Python veya Java gibi bir video sürücüsü veya benzeri bir şey yazmasını ve "güvenlik" hakkında ne düşündüğünüzü görmesini isteyin.

Cidden, pikselleri, kayıtları vb. İşleyebilmek için makinenin çekirdek belleğine yakın olmanız gerekir ... Java ya da Python bunu herhangi bir performansa uygun hızda yapamaz ... C ve C ++ işaretçiler ve benzerleriyle bunu yapmanıza izin verin ...

Yukarıdakilerin yanı sıra, C'yi diğer diller için ortak bir kütüphane olarak kullanan oldukça yaygın bir kullanım durumu vardır.

Temel olarak, hemen hemen tüm dillerin C için bir API arayüzü var.

Basit bir örnek, Linux / IOS / Android / Windows için ortak bir uygulama oluşturmaya çalışın. Dışarıdaki tüm araçların yanı sıra, sonuçta C'de bir çekirdek kütüphanesi yapmak ve her ortam için GUI'yi değiştirmek oldu.

• IOS: ObjectiveC, C kütüphanelerini yerel olarak kullanabilir
• Android: Java + JNI
• Linux / Windows / MacOS: GTK / .Net ile yerel kütüphaneleri kullanabilirsiniz. Python, Perl, Ruby kullanıyorsanız, her birinin yerel API arayüzleri vardır. (JNI ile tekrar Java).

Benim iki Sentim,

C ile ilgili temel bir zorluk, adın aynı sözdizimine sahip fakat çok farklı bir anlambilimine sahip bir dizi lehçeyi tanımlamak için kullanılmasıdır. Bazı lehçeler diğerlerinden daha güvenlidir.

Aslen Dennis Ritchie tarafından tasarlandığı gibi C ifadesinde, C ifadeleri genellikle makine talimatlarıyla öngörülebilir şekilde eşleştirilirdi. C imzalı aritmetik taşma gibi şeyler gerçekleştiğinde farklı davranış gösteren işlemciler üzerinde çalışabildiğinden, aritmetik taşma durumunda bir makinenin nasıl davranacağını bilemeyen bir programcı, o makinede çalışan C kodunun da nasıl davranacağını bilemezdi. Bir makinenin belirli bir şekilde davrandığı biliniyorsa (örneğin, sessiz ikinin tamamlayıcı sarımı), o zaman bu makine üzerindeki uygulamalar da aynı şekilde olacaktır. C'nin hızlı olmasının ünü kazanmasının sebeplerinden biri, programcıların bir platformun son vaka senaryolarındaki doğal davranışının kendi gereksinimlerine uygun olacağını bilmesi durumunda, programcının veya derleyicinin bu tür senaryolar oluşturmak için kod yazmasına gerek olmamasıydı. .

Ne yazık ki, derleyici yazarları, Standardın bu gibi durumlarda ne yapılması gerektiği konusunda bir zorunluluk getirmediği için (öngörülebilir şekilde davranamayan donanım uygulamalarına izin vermek amaçlanan gevşeklik), derleyicilerin yasaları ihlal eden kodlar üretmekte özgür hissetmeleri gerektiği görüşündedir. zaman ve nedensellik.

Gibi bir şey düşünün:

int hey(int x)
{
   printf("%d", x);
   return x*10000;
}
void wow(int x)
{
  if (x < 1000000)
    printf("QUACK!");
  hey(x);    
}

Hyper-modern (ancak modaya uygun) derleyici teorisi derleyicinin "QUACK!" koşulsuz bir şekilde, koşulun yanlış olduğu herhangi bir durumda, program, sonuçta yine de göz ardı edilecek olan bir çarpma gerçekleştiren tanımsız davranışa neden olacaktı. Standart, böyle bir durumda bir derleyicinin sevdiği bir şeyi yapmasına izin vereceğinden, derleyicinin "QUACK!" Çıktısına izin verir.

C, montaj diline göre daha güvenliyken, hiper-modern derleyiciler kullanıldığında bunun tersi geçerlidir. Assembly dilinde, tamsayı taşması bir hesaplamanın anlamsız bir sonuç vermesine neden olabilir, ancak çoğu platformda etkilerinin kapsamı olacaktır. Sonuçlar yine de göz ardı edilirse, taşma önemli olmaz. Bununla birlikte, hiper-modern C'de, normalde Tanımlanmamış Davranışın “iyi huylu” formları bile olsa (örneğin, yok sayılan biten bir hesaplamada bir tamsayı taşması gibi) keyfi programın yürütülmesine neden olabilir.

Tarihsel sebepler. Sık sık yeni kod yazmak istemiyorum, çoğunlukla on yıllardır devam eden eski şeyleri sürdürüp genişletiyorum. Sadece C ve Fortran olmadığı için mutluyum.

Bir öğrenci "dediği zaman neden bu kadar korkunç X yapıyorsun?" Diyorsa sinirlenebilirim. X, sahip olduğum iş ve faturaları çok iyi ödüyor. Ara sıra Y yaptım ve eğlenceliydi, ama X çoğumuzun yaptığı şey.

"Tehlikeli" nedir?

C'nin "tehlikeli" olduğu iddiası, dil ateşi savaşlarında (çoğunlukla Java ile karşılaştırıldığında) sıkça bir konuşma noktasıdır. Bununla birlikte, bu iddia için kanıt belirsizdir.

C, belirli özelliklere sahip bir dildir. Bu özelliklerden bazıları, diğer dil türlerinde izin verilmeyen bazı hata türlerine izin verebilir (C'nin bellek yönetimi riski genellikle vurgulanır). Ancak, bu C diğer dillere daha tehlikeli bir argüman olarak aynı değildir genel . Bu konuda ikna edici kanıtlar sunan hiç kimsenin farkında değilim.

Ayrıca, "tehlikeli" içeriğe bağlıdır: ne yapmaya çalışıyorsun ve ne tür risklerden endişe ediyorsun?

Birçok bağlamda C'yi üst düzey bir dilden daha "tehlikeli" olarak kabul ediyorum, çünkü temel işlevsellikten daha fazla manüel uygulama yapmanız ve hata riskini artırmanız gerekiyor. Örneğin, bazı temel metin işlemlerini yapmak veya C dilinde bir web sitesi geliştirmek genellikle aptalca olacaktır, çünkü diğer dillerde bunu çok daha kolaylaştıran özelliklere sahiptir.

Bununla birlikte, görev kritik sistemler için C ve C ++ yaygın olarak kullanılır, çünkü daha doğrudan kontrol kontrolü olan daha küçük bir dil bu bağlamda "daha güvenli" olarak kabul edilir. Gönderen çok iyi yığın taşması cevap :

Her ne kadar C ve C ++ bu tür bir uygulama için özel olarak tasarlanmamış olsa da, çeşitli nedenlerden dolayı gömülü ve güvenlik açısından kritik öneme sahip yazılımlar için yaygın olarak kullanılırlar. Notun ana özellikleri bellek yönetimi (örneğin, çöp toplamak zorunda kalmamanızdan kaçınmanızı sağlar), basit, iyi hata ayıklanmış çekirdek çalışma zamanı kitaplıkları ve olgun araç desteğidir. Günümüzde kullanımda olan gömülü geliştirme aracı zincirlerinin çoğu, ilk olarak 1980'lerde ve 1990'larda, bunun şu andaki teknoloji olduğu ve o dönemde yaygın olan Unix kültüründen geldiği için geliştirilmiştir, bu nedenle bu araçlar bu tür çalışmalar için popüler olmaya devam etmektedir.

Hataları önlemek için manuel bellek yönetimi kodunun dikkatlice kontrol edilmesi gerekirken, çöp toplamaya bağlı dillerde bulunmayan uygulama yanıt süreleri üzerinde bir dereceye kadar kontrol sağlar. C ve C ++ dillerinin temel çalışma zamanı kitaplıkları nispeten basit, olgun ve iyi anlaşılır, bu nedenle mevcut en kararlı platformlar arasında yer alıyor.

Mevcut cevaplara eklemek için, göreceli güvenliklerinden dolayı projeniz için Python veya PHP'yi seçeceğinizi söylemek gayet iyi ve güzel. Fakat birileri bu dilleri uygulamalı ve bunu yaptıklarında muhtemelen C'de yapacaklardır (Ya da onun gibi bir şey.)

- insanlar C kullanın Yani bu yüzden daha az tehlikeli araçları oluşturmak için size kullanmak istiyorum.

Sorunuzu tekrar ifade etmeme izin verin:

[Aracı] öğrenmeyi düşünüyorum.

Fakat insanlar [tehlikeli] olarak kullanabiliyorlarsa neden [araç] (veya [ilgili araç]) kullanıyorlar?

Herhangi bir ilginç araç, programlama dilleri dahil, tehlikeli bir şekilde kullanılabilir. Sen öğrenmek sen böylece daha yapmak (Aracı kullandığınızda daha az tehlike oluşturulduğunu ve bu yüzden) daha fazlası. Özellikle, aleti, o alet için iyi olan şeyi yapabilmeniz için öğrenirsiniz (ve belki de bu alet, tanıdığınız aletlerin en iyi aleti olduğunda bunu tanır).

Örneğin, 6 mm çapında, 5 cm derinliğinde, bir tahta parçası içine silindirik bir delik açmanız gerekirse, bir matkap LALR ayrıştırıcısından çok daha iyi bir araçtır. Bu iki aracın ne olduğunu biliyorsanız, hangisinin doğru araç olduğunu bilirsiniz. Zaten matkap kullanmayı biliyorsanız, boşluk !, delik.

C sadece başka bir araçtır. Bazı görevler için diğerlerinden daha iyidir. Buradaki diğer cevaplar buna değiniyor. Biraz C öğrenirseniz, ne zaman doğru alet olduğunu ve ne zaman olmadığını tanımaya başlayacaksınız.

C öğrenmeyi düşünüyorum

C'yi öğrenmemek için belirli bir neden yok ama C ++ 'ı önerebilirim. C'nin yaptığı şeylerin çoğunu sunar (çünkü C ++, C'nin süper bir kümesidir) ve büyük miktarda "ekstra" içerir. C ++ 'dan önce C öğrenmesi gerekli değildir - onlar etkili bir şekilde ayrı dillerdir.

Başka bir deyişle, C bir ağaç işleme aletleri seti olsaydı, muhtemelen şöyle olurdu:

• çekiç
• çiviler
• el testeresi
• Matkap
• blok zımpara makinesi
• keski (belki)

Bu araçlarla her şeyi inşa edebilirsiniz - ama güzel olan her şey potansiyel olarak çok zaman ve beceri gerektirir.

C ++, yerel nalburdan elektrikli el aletleri topluluğudur.

Başlamak için temel dil özelliklerine sadık kalırsanız, C ++ 'ın ek öğrenme eğrisi azdır.

Ancak insanlar 'tehlikeli' olarak kullanılıyorsa neden C (veya C ++) kullanıyorlar?

Çünkü bazı insanlar IKEA'dan mobilya istemiyor. =)

Cidden, C veya C ++ 'dan "daha yüksek" olan birçok dil, bazı yönlerden onları (potansiyel olarak) "kolay" yapan şeylere sahip olsa da, bu her zaman iyi bir şey değildir. Bir şeyin yapılmasından hoşlanmazsanız veya bir özellik sağlanmazsa, bu konuda yapabileceğiniz fazla bir şey yoktur. Öte yandan, C ve C ++, birçok şeye doğrudan erişebildiğiniz (özellikle donanım ya da OS-akıllıca) ya da başka bir şekilde yapamayacağınız şekilde kendi başınıza yaratabileceğiniz yeterli "düşük seviye" dil özellikleri (işaretçiler dahil) sağlar. uygulandığı gibi diller.

Daha spesifik olarak, C, birçok programcı için arzu edilen kılan aşağıdaki özelliklere sahiptir:

• Hız - Yıllar boyunca göreceli basitliği ve derleyici optimizasyonları nedeniyle, doğal olarak çok hızlıdır. Ayrıca, birçok insan dili kullanırken, hedefleri daha da hızlı kılan özel hedeflere giden birçok kısayol bulmuşlardır.
• Boyut - Hız için listelenenlere benzer nedenlerle, C programları çok küçük yapılabilir (hem uygulanabilir boyutta hem de bellek kullanımı açısından), bu da sınırlı belleğe sahip ortamlarda (yani gömülü veya mobil) istenebilir.

• Uyumluluk - C uzun zamandır etrafta ve herkesin bunun için araçları ve kütüphaneleri var. Dilin kendisi de seçici değildir - bir işlemciden bir şeyleri tutmak için talimatlar ve hafıza yürütmesini bekler ve bu onunla ilgilidir.

  Ayrıca, bir Uygulama İkili Arabirimi (ABI) olarak bilinen bir şey var . Kısacası, programların bir Uygulama Kodu Arabirimi'ne (API) göre avantajları olabilecek makine kodu düzeyinde iletişim kurmasının bir yoludur . C ++ gibi diğer diller bir ABI'ye sahip olsa da, genellikle bunlar C'lerden daha az aynıdır (üzerinde anlaşılırlar), bu nedenle C, bir sebepten dolayı başka bir programla iletişim kurmak için bir ABI kullanmak istediğinizde iyi bir temel dili oluşturur.

Programcılar neden Java veya Python veya Visual Basic gibi derlenmiş başka bir dil kullanmıyorlar?

Verimlilik (ve bazen belleğe nispeten doğrudan erişim olmadan uygulanamayan bellek yönetimi programları).

İşaretçilerle doğrudan belleğe erişme, kirli pençelerinizi küçükler ve sıfırlar üzerine doğrudan dolabınızdaki sıfırlar ve sıfırlar üzerine koyabileceğiniz ve öğretmenlerin sadece oyuncakları dağıtması için beklemek zorunda kalmayacağınız bir çok temiz (genellikle hızlı) hileci sunar çalma saatinde tekrar toplayın.

Kısacası, malzeme eklemek potansiyel olarak gecikme yaratır veya istenmeyen karmaşıklığı beraberinde getirir.

Komut dosyası dilleri ve bu ilklerle ilgili olarak, ikincil programların C (veya herhangi bir derlenmiş dilin) ​​olduğu kadar verimli çalışmasını gerektiren dilleri almak için çok çalışmak zorundasınız. Hareket halindeyken bir tercüman eklemek doğal olarak azaltılmış çalıştırma hızı ve arttırılmış bellek kullanımı olasılığını ortaya çıkarır çünkü karışıma başka bir program ekliyorsunuz. Programlarınızın verimliliği, bu programın verimliliğine, orijinal program kodunuzu ne kadar iyi yazdığınıza (zayıf =) bağlıdır. Programınızdan bahsetmiyorum bile ikinci programa bile tamamen bağımlıdır. Bu ikinci program belirli bir sistemde bir nedenden dolayı yok mu? Kod yok git.

Aslında, "ekstra" bir şey eklemek, potansiyel olarak kodunuzu yavaşlatır veya karmaşıklaştırır. "Korkutucu işaretçiler olmadan" dilde, her zaman arkanızda temizlemek veya başka şeyler yapmak "güvenli" yollarını anlamaya kod diğer bit bekliyor - Programınız çünkü hala yapılabilir olabilir aynı bellek erişimi işlemlerini yapıyor işaretçileri. Sen sadece bunu yapan kişi değilsin (bu yüzden bunu yapamazsın, dahi = P).

Tehlikeli derken, işaretçilerle ve benzeri şeylerle demek istiyorum. [...] Yığın Taşması sorusu gibi Alınan fonksiyon neden kullanılmaması gereken çok tehlikelidir?

Kabul edilen cevaba göre:

"1999 ISO C standardına kadar dilin resmi bir parçası olarak kaldı, ancak 2011 standardı tarafından resmen kaldırıldı. Çoğu C uygulaması hala onu destekliyor, ancak en azından gcc kullanan herhangi bir kod için bir uyarı veriyor."

Bir dilde bir şey yapılabileceği için yapılması gereken aptalcadır. Dillerin düzeltilen kusurları vardır. Eski kod ile uyumluluk nedenleriyle, bu yapı hala kullanılabilir. Ancak bir programcının kullanmaya zorlayan hiçbir şey yoktur () ve () aslında bu komut daha güvenli alternatiflerle değiştirilir.

Daha da önemlisi, gets () ile olan sorun başlı başına bir işaretçi sorunu değildir. Belleği nasıl güvenli bir şekilde kullanacağınızı bilmeyen bir komutla ilgili bir sorun. Soyut anlamda, tüm bunlar işaretçi meseleleridir - sizin yapmanız gerekmeyen şeyleri okumak ve yazmak. İşaretçilerle ilgili bir sorun değil; işaretçi uygulamasında bir sorun var.

Netleştirmek için, işaretçiler yanlışlıkla istemediğiniz bir hafıza konumuna erişene kadar tehlikeli değildir. Ve o zaman bile bu, bilgisayarınızın erimesini veya patlamasını garanti etmez. Çoğu durumda, programınız işlevini kesecektir (doğru).

Bunun nedeni, işaretçilerin bellek konumlarına erişim sağlaması ve veri ile yürütülebilir kodun birlikte bellekte bulunması nedeniyle, belleği doğru şekilde yönetmek istediğinizde yanlışlıkla bozulma tehlikesi vardır.

Bu noktada, gerçekten doğrudan belleğe erişim işlemleri genellikle yıllar önce sahip olduklarından genel olarak daha az fayda sağladığından, C ++ gibi çöp toplanmamış diller bile, bellek verimliliği ile güvenlik arasındaki boşluğu doldurmaya yardımcı olmak için akıllı işaretçiler gibi şeyler ortaya koymuştur .

Özet olarak, güvenle kullanıldığı sürece işaretçiden korkmak için çok az neden vardır. Sadece South Park'ın Steve "The Crocodile Hunter" (Irwin) sürümünden bir ipucu alın - baş parmağınızı croc'ların çukurlarına sokmayın .

Her zaman olduğu gibi, programlama dili sadece problem çözmenin bir sonucudur. Aslında sadece C'yi değil, bir çok farklı dili (ve bir bilgisayarı programlamanın diğer yollarını (GUI araçları veya komut yorumlayıcıları da olabilir)) problem çözerken kullanmak için iyi bir araç kutusuna sahip olmayı öğrenmelisiniz.

Bazen bir sorunun Java varsayılan kitaplıklarında bulunan bir şeye iyi bir şekilde katlandığını göreceksiniz, bu durumda, kaldıraç için Java'yı seçebilirsiniz. Diğer durumlarda, Windows'ta .NET çalışma zamanlarında çok daha basit olan bir şey yapmanız gerekebilir, bu nedenle C # veya VB kullanabilirsiniz. Sorununuzu çözen grafiksel bir araç veya komut dosyası olabilir, sonra bunları kullanabilirsiniz. Belki birden fazla platformda bir GUI uygulaması yazmanız gerekir, Java JDK'da bulunan kütüphaneler göz önüne alındığında bir seçenek olabilir, ancak daha sonra yine bir hedef platformda bir JRE olmayabilir, bu nedenle belki C ve SDL (veya benzerlerini) seçin.

C genel olarak, küçük ve hızlı olduğu ve aynı zamanda makine kodunu derlediği için bu araç setinde önemli bir konuma sahiptir. Aynı zamanda güneş altındaki her platformda desteklenir (ancak yeniden derlenmeden).

Alt satırda, mümkün olduğunca çok sayıda araç, dil ve paradigma öğrenmelisiniz.

Lütfen zihniyetten uzak durun: "Ben bir X programcısıyım" (X = C, C ++, Java, vb.)

Sadece "Ben programcıyım" kullanın.

Bir programcı sorunları çözer ve iş yükünü gerçekleştirmeleri için makinelere talimat vererek algoritmalar tasarlar. Hikayenin sonu. Bu dille alakası yok. En önemli yeteneğiniz, problem çözme ve yapılandırılmış problemlerin mantıksal dağılmasıdır, dil becerisi / seçimi her zaman ikincil ve / veya problemin niteliğinin bir sonucudur.

C ile ilgileniyorsanız ilginç bir yol, beceri setinizi Go ile genişletmektir. Go, çöp toplama ve ara yüzleri ile gerçekten geliştirilmiş bir C'dir, ayrıca C'nin birçok faydasını da (işaretçi aritmetik ve makine kodunu derleme gibi) ortaya çıkaran güzel bir iş parçacığı modeli / kanalına sahiptir.

Ne yapmak istediğine bağlı. C, montaj dili için bir yedek olarak tasarlanmıştır ve makine diline en yakın olan en üst düzey dildir. Bu nedenle, boyut ve performans açısından düşük genel giderlere sahiptir ve sistem programlaması ve küçük bir alan kaplayan ve altta yatan donanıma yaklaşan diğer görevler için uygundur.

En verimli ayırıcıları ve veri yapılarını etkin bir şekilde uygulamak için sıklıkla gerekli olacak şekilde, homojen veri toplama belleği olarak bellek, bit ve bayt düzeyinde çalışırken, sahip olunacak hiçbir güvenlik yoktur. Güvenlik, ağırlıklı olarak güçlü bir veri türü ile ilgili kavramdır ve bir bellek ayırıcısı veri türleriyle çalışmaz. Potansiyel olarak bir veri türünü temsil eden aynı bit ve baytlarla bir dakika ve sonra bir araya gelmek için bit ve baytlarla çalışır.

Bu durumda C ++ kullanmanızın bir önemi yoktur. İşaretçilerden static_castsyayın yapmak void*ve hala bit ve baytlarla çalışmak için hala tüm kodun üzerine serpiyor ve bu bağlamda tip sistemine saygı duymayla ilgili daha fazla güçlükle uğraşıyorsunuz. için memcpybit ve tip sistemini üzerinde buldozerle endişesi duymadan etrafında bayt.

Aslında, genel olarak daha güvenli bir dil olan C ++ 'ta çalışmak, bu tür düşük seviyeli bit ve bayt bağlamlarında, C +' dan türden bir sistem üzerinde buldozerlik yapabileceğinizden ve daha fazlasını yapabileceğinizden daha tehlikeli bir kod yazmadan çalışmak zordur. vptr'lerin üzerine yazmak ve uygun zamanlarda kopya kurucularını ve yıkıcıları çağırmamak. Bu türlere saygı duymak için doğru zaman ayırırsanız ve yeni ve manuel olarak yeni bir yerleşim yerleştirirseniz, RAII için pratik olması ve istisnaya ulaşması için çok düşük bir bağlamda istisna işleme dünyasına maruz kalırsınız. Böyle düşük seviyeli bir bağlamda güvenlik çok zordur (herhangi bir fonksiyonun tüm olasılıkları fırlatabilmesi ve yakalayabilmesi ve herhangi bir şey olmamış gibi bölünemez bir işlem olarak herhangi bir yan etkiyi geri alabilmesi gibi). C kodu genellikle "

Ve bu tür ayırıcıları burada "tehlikeli" olmanıza izin vermeyen dillerde uygulamak imkansız olurdu; Sağladıkları her tahsisatçıya (C veya C ++ 'da uygulanacak olan) ne kadar dayanmanız ve amaçlarınız için yeterince iyi olacağını ummanız gerekir. Neredeyse her zaman daha verimli ancak daha az genel tahsisatçı ve özel amaçlarınıza uygun veri yapıları var, ancak sizin amaçlarınız için özel olarak tasarlandıkları için çok daha dar uygulanabilirler.

Çoğu insan, C veya C ++ 'dan hoşlanmaya ihtiyaç duymaz, çünkü sadece C veya C ++' ta uygulanmış olan kodu, hatta onlar için daha önce uygulanmış olan montajı bile çağırabilir. Birçoğu, C'de uygulanmış olan görüntü işleme fonksiyonlarının kütüphanelerini kullanan, tek tek pikseller arasında en düşük döngü seviyesinde çok fazla inovasyon yapmadıkları, ancak belki de en düşük seviyede döngü oluşturma kullanan bir görüntü programını bir araya getirmek gibi, üst düzeyde yenilikçilikten faydalanabilir. daha önce hiç görülmemiş çok kullanıcı dostu bir arayüz ve iş akışı sunuyor. Bu durumda, yazılımın amacı sadece düşük seviyeli kütüphanelere yüksek seviyeli çağrılar yapmaksa ( "bu görüntüyü benim için işlem, her piksel için değil, bir şeyler yap" ), o zaman muhtemelen erken bir optimizasyon olabilir. Hatta C'ye böyle bir uygulama yazmaya başlamak için

Ancak, daha önce hiç görülmemiş yepyeni bir görüntü filtresi gibi gerçek zamanlı olarak HD video üzerinde çalışmak için yeterince hızlı olan verilere erişmeye yardımcı olduğu düşük seviyede yeni bir şey yapıyorsanız, genellikle elde etmeniz gerekir. biraz tehlikeli.

Bu şeyleri kabullenmek için almak kolaydır. Düşük seviyeli dillerin modası geçmiş hale geldiğini ima eden Python ile bir 3D video oyunu yaratmanın ne kadar mümkün olduğunu belirten biriyle bir facebook gönderisini hatırlıyorum. Ancak Python, tüm ağır kaldırma işlerini yapmak için C'de uygulanan kütüphanelere üst düzey çağrılar yapıyordu. Unreal Engine 4'ü mevcut kütüphanelere sadece yüksek seviyeli çağrılar yaparak gerçekleştiremezsiniz. Unreal Engine 4 olduğunukütüphane. Diğer kütüphanelerde ve motorlarda asla aydınlatmayan, hatta kendi nodal plan sistemine kadar varolmayan her türlü şeyi yaptı ve anında nasıl derleyebildiğini ve çalıştırabildiğini söyledi. Düşük motor / çekirdek / çekirdek seviyesi türünde yenilik yapmak istiyorsanız, düşük seviyeye sahip olmalısınız. Tüm oyun geliştiricileri yüksek seviyeli güvenli dillere geçerse, Unreal Engine 5 veya 6 veya 7 olmayacaktı. Büyük olasılıkla hala on yıllar sonra Unreal Engine 4 kullanan insanlar olabilirdi çünkü gelmek için gereken seviyede yenilik yapamazsınız. Sadece yeni nesil bir motorla eskiden yüksek seviyeli aramalar yaparak.