C diline kıyasla C ++ sınırlamaları ne olur? [kapalı]

C ++ 'ın faydaları aşağıdadır

• C ++, sorulan belirli özellikleri sağlar
• C derleyicileri neredeyse kesinlikle bir C ++ derleyicisidir, bu nedenle yazılım maliyeti çıkarımları yoktur.
• C ++, C kadar taşınabilir
• C ++ kodu, C kadar verimli olabilir (veya daha çok veya daha az)

C ++ yerine C'nin kullanılması gereken somut nedenler ve özel senaryolar var mı?

Bu soruya referans: C'deki jenerikler için kütüphane

Tekrar değil, çünkü bu soru dil sınırlamaları hakkında soru soruyor ve bir dili diğerine göre öğrenmemeli / öğrenmemeli hakkında değil.

Peter Kirkham'ın gönderisi benim için en bilgilendiriciydi, özellikle de dikkate almadığım C99 konuları ile ilgili olarak, bu yüzden kabul ettim. Katılan herkese teşekkürler.

Bu, C için bir jenerik kitaplığı soran güncel bir soruya verdiğim bir cevapla harekete geçirildi - soru soran özellikle C ++ kullanmak istemediklerini belirtiyor.

C tam bir programlama dilidir. C, C ++ 'ın rastgele bir alt kümesi değildir. C, C ++ 'nın bir alt kümesi değildir.

Bu geçerli C:

foo_t* foo = malloc ( sizeof(foo_t) );

C ++ olarak derlenmesi için şunu yazmanız gerekir:

foo_t* foo = static_cast<foo_t*>( malloc ( sizeof(foo_t) ) );

artık geçerli olmayan C. (C-style cast'ı kullanabilirsiniz, bu durumda C'de derlenir, ancak çoğu C ++ kodlama standardı ve ayrıca birçok C programcısı tarafından dışlanır; Stack Overflow'daki "malloc dökme" yorumlarına tanık olun) .

Aynı dil değildirler ve C'de mevcut bir projeniz varsa, sadece bir kütüphane kullanmak için onu farklı bir dilde yeniden yazmak istemezsiniz. Çalışmakta olduğunuz dilde arabirim oluşturabileceğiniz kitaplıkları kullanmayı tercih edersiniz. (Bazı durumlarda bu, extern "C"şablonun / satır içi bir C ++ kitaplığının nasıl olduğuna bağlı olarak birkaç sarmalayıcı işleviyle mümkündür .)

Üzerinde çalıştığım bir projede ilk C dosyasını alarak, bu ne olur sadece takas eğer gcc std=c99için g++:

sandiego:$ g++ -g  -O1 -pedantic -mfpmath=sse -DUSE_SSE2 -DUSE_XMM3  -I src/core -L /usr/lib -DARCH=elf64 -D_BSD_SOURCE -DPOSIX -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200112L -Wall -Wextra -Wwrite-strings -Wredundant-decls -Werror -Isrc  src/core/kin_object.c -c -o obj/kin_object.o | wc -l
In file included from src/core/kin_object.c:22:
src/core/kin_object.h:791:28: error: anonymous variadic macros were introduced in C99
In file included from src/core/kin_object.c:26:
src/core/kin_log.h:42:42: error: anonymous variadic macros were introduced in C99
src/core/kin_log.h:94:29: error: anonymous variadic macros were introduced in C99
...
cc1plus: warnings being treated as errors
src/core/kin_object.c:101: error: ISO C++ does not support the ‘z’ printf length modifier
..
src/core/kin_object.c:160: error: invalid conversion from ‘void*’ to ‘kin_object_t*’
..
src/core/kin_object.c:227: error: unused parameter ‘restrict’
..
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier
src/core/kin_object.c:271: error: ISO C++ does not support the ‘z’ printf length modifier

Dördü geçersiz dönüşüm, ancak çoğunlukla C99'da var olan ancak C ++ 'da olmayan özellikler için olmak üzere toplam 69 hata satırı.

Bu özellikleri eğlenmek için kullanmıyorum. Bunu farklı bir dile taşımak önemli bir çalışma gerektirir.

Bu yüzden bunu önermek kesinlikle yanlıştır

[a] C derleyicisi neredeyse kesinlikle bir C ++ derleyicisidir, bu nedenle yazılım maliyeti çıkarımları yoktur

Mevcut C kodunu C ++ 'ın yordamsal alt kümesine taşımanın genellikle önemli maliyet etkileri vardır.

Dolayısıyla , C'deki bir kuyruğun kitaplık uygulamasını arayan bir soruya yanıt olarak 'C ++ std :: queue sınıfını kullanın' önermesi, 'hedef C'yi kullan' ve 'JNI kullanarak Java java.util.Queue sınıfını çağırın ' önermekten daha iyidir. veya 'CPython kitaplığını çağırın' - Hedef C aslında C'nin uygun bir üst kümesidir (C99 dahil) ve Java ve CPython kitaplıklarının her ikisi de ilgisiz kodu C ++ diline taşımak zorunda kalmadan doğrudan C'den çağrılabilir.

Elbette, C ++ kitaplığına bir C cephesi sağlayabilirsiniz, ancak bunu bir kez yaptıktan sonra C ++, Java veya Python'dan farklı değildir.

Bunun ne profesyonel ne de belirli bir iyi cevap olmadığını anlıyorum, ama benim için basitçe C'yi gerçekten sevdiğim için C küçük ve basittir ve beynimin tamamına tüm dili sığdırabilirim, C ++ bana her zaman büyük bir karmaşa gibi göründü her tür katmanla sersemlemekte zorlanıyorum. Bundan dolayı, C ++ 'ı ne zaman yazsam, sonunda C'yi kodladığımdan çok daha fazla hata ayıklamak ve kafamı sert yüzeylere vurmakla harcadığımı görüyorum. Yine, bunun çoğunun büyük ölçüde kendi' cehaletimin 'bir sonucu olduğunu anlıyorum.

Seçim yaparsam, arayüz ve veritabanı etkileşimi gibi tüm üst düzey şeyleri python'da (veya muhtemelen C #) ve C'de hızlı olması gereken her şeyi yazacağım. Bana tüm dünyaların en iyisini veren. Her şeyi C ++ ile yazmak, tüm dünyaların en kötüsünü almak gibi bir his.

Düzenleme: Birkaç C ++ özelliğine sahip C'nin, bir proje üzerinde çalışan birkaç kişi olacaksanız veya sürdürülebilirlik öncelikliyse, büyük ölçüde kötü bir fikir olduğunu düşünüyorum. Neyin 'birkaç'ı oluşturduğu ve hangi bitlerin C'de yapılması gerektiği ve sonunda C ++' da hangi bitlerin çok şizofrenik bir kod tabanına yol açacağı konusunda anlaşmazlık olacaktır.

C ++, düşük seviyeli gömülü sistemler gibi bazı gerçek dünya ortamlarında desteklenmez. Ve bunun iyi bir nedeni var: C kolayca bu tür şeyler için yeterince iyi, öyleyse neden daha büyük bir şey kullanalım?

C ++ ile programlamadan nefret ediyorum.

Bunun birkaç nedeni şunlar olabilir:

• Destek eksikliği - Her C derleyicisi aynı zamanda bir C ++ derleyicisi değildir. Tüm derleyiciler, C ++ 'yı desteklediklerini iddia etseler bile, özellikle standartla uyumlu değildir. Ve bazı C ++ derleyicileri umutsuzca şişirilmiş ve verimsiz kod üretir. Bazı derleyiciler, standart kitaplığın korkunç uygulamalarına sahiptir. Çekirdek modu geliştirme, genellikle C ++ standart kitaplığının yanı sıra bazı dil özelliklerinin kullanımını imkansız kılar. Dilin özüne bağlı kalırsanız yine de C ++ kodu yazabilirsiniz, ancak o zaman C'ye geçmek daha kolay olabilir.
• Aşinalık. C ++ karmaşık bir dildir. Birine C'yi öğretmek C ++ 'dan daha kolaydır ve iyi bir C programcısı bulmak, iyi bir C ++ programcısından daha kolaydır. (buradaki anahtar kelime "iyi" dir. Çok sayıda C ++ programcısı vardır, ancak çoğu dili doğru şekilde öğrenmemişlerdir)
• Öğrenme eğrisi - Yukarıdaki gibi, birine C ++ öğretmek çok büyük bir görevdir. Gelecekte başkaları tarafından bakımı yapılması gereken bir uygulama yazıyorsanız ve bu diğerleri C ++ programcıları olmayabilir, bunu C ile yazmak, kavramayı çok daha kolay hale getirir.

Bundan kurtulabildiğimde yine de C ++ ile yazmayı tercih ederim ve genel olarak faydaların dezavantajlarından daha ağır bastığını düşünüyorum. Ancak bazı durumlarda C'yi kullanma argümanını da görebiliyorum.

Gömülü programlama, performans ve benzeri şeyler hakkında pek çok tartışma var, onları satın almıyorum. C ++, bu alanlarda C ile kolayca karşılaştırılır. Ancak:

Kısa bir süre önce, 15 yıldan fazla bir süredir C ++ 'da programladıktan sonra C köklerimi yeniden keşfediyorum. C ++ 'da hayatı kolaylaştıran iyi özellikler varken, bir sürü tuzak ve işleri yapmanın bir tür "her zaman daha iyi bir yolu vardır" olduğunu söylemeliyim. Yaptığınız çözümden asla pek mutlu olmazsınız. (Beni yanlış anlamayın, bu iyi bir şey olabilir, ama çoğunlukla değil).

C ++ size sonsuz silah sesi verir. Bu tartışmasız iyi olabilir ama bir şekilde her zaman çok fazla kullanırsınız. Bu, çözümlerinizi "güzel" ve "güzel" soyutlama, genellik vb. Katmanlarla gizlediğiniz anlamına gelir.

C'ye geri dönmeyi keşfettiğim şey aslında yine eğlenceli bir programlama olduğuydu. Kalıtımı en iyi nasıl kullanacağımı modellemek ve düşünmek için çok zaman harcadıktan sonra, C'deki programlamanın aslında kaynak kodumu daha küçük ve daha okunaklı hale getirdiğini görüyorum. Bu elbette öz disiplin seviyenize bağlıdır. Ancak doğrudan kod üzerine çok fazla soyutlama koymak çok kolaydır, ki bu aslında hiçbir zaman gerekli değildir.

C'nin temel avantajı, bir kod parçasına baktığınızda gerçekte neler olup bittiğini görebilmenizdir (evet önişlemci: -E ile derleyin ve sonra onu görürsünüz). Bazı C ++ kodlarına baktığınızda çoğu zaman doğru olmayan bir şey. Orada, kapsama dayalı olarak veya atamalar nedeniyle örtük olarak çağrılan kurucular ve yıkıcılar var, kötü bir şekilde kötüye kullanılmadığında bile şaşırtıcı davranışlara sahip olabilen operatör aşırı yüklemesine sahipsiniz. Kontrol manyağı olduğumu kabul ediyorum, ancak bunun güvenilir yazılım yazmak isteyen bir yazılım geliştiricisi için o kadar da kötü bir alışkanlık olmadığı sonucuna vardım. Sadece yazılımımın tam olarak yapması gerekeni yaptığını ve aynı zamanda midemde kötü bir his olmadığını söylemek için adil bir şansa sahip olmak istiyorum çünkü bunda hala o kadar çok hata olabileceğini biliyorum ki yapmayacağım.

C ++ ayrıca şablonlara sahiptir. Onlardan nefret ediyorum ve seviyorum ama biri onları tam olarak anladığını söylerse ona yalancı derim! Bu, standardı tanımlamanın yanı sıra derleyici yazarlarını da içerir (bu, onu okumaya çalıştığınızda açık hale gelir). O kadar çok saçma sapan yanıltıcı köşe vakası var ki, gerçek kodu yazarken bunların hepsini dikkate almak mümkün değil. Tam güçleri için C ++ şablonlarını seviyorum. Onlarla yapabilecekleriniz gerçekten şaşırtıcı, ancak aynı şekilde birinin hayal edebileceği (edemeyeceği) hataları bulması en garip ve en zor hatalara yol açabilirler. Ve bu hatalar gerçekte olur ve nadiren bile olmaz. C ++ ARM'de şablonları çözmek için dahil olan kuralları okumak neredeyse kafamı patlatıyor. Ve bana, derleyicinin benden gerçekte ne istediğini anlamak için zaten 10 dakikaya veya daha fazlasına ihtiyacım olan birkaç 1000 karakter uzunluğundaki derleyici hata mesajlarını okumak zorunda kaldığım kötü bir zaman kaybı hissi veriyor. Tipik C ++ (kitaplık) kodunda, belirli şablonları mümkün kılmak için üstbilgi dosyalarında sıklıkla çok sayıda kod bulursunuz, bu da hızlı makinelerde bile derleme / yürütme döngülerini acı verici bir şekilde yavaşlatır ve bir şeyi değiştirdiğinizde kodun büyük bölümlerinin yeniden derlenmesini gerektirir. Orada.

C ++ ayrıca const tuzağına da sahiptir. Ya en önemsiz kullanım durumları dışında tümü için const'tan kaçınırsınız ya da er ya da geç onu atmanız ya da geliştiğinde, özellikle güzel ve esnek bir OO tasarımı geliştirmek üzereyken kod tabanının büyük bölümlerini yeniden düzenlemeniz gerekir.

C ++, C'den daha güçlü bir yazıma sahiptir, bu harika, ancak bazen C ++ kodunu derlemeye çalıştığımda bir Tamagotchi beslediğimi hissediyorum. Genellikle ondan aldığım uyarıların ve hataların büyük bir kısmı gerçekten işe yaramayacak bir şey yapmam değil, sadece derleyicinin bu şekilde yapmamı sevmediği şeyler veya buraya fazladan anahtar kelimeler koymadan ve Orada.

Bunlar, yalnızca bazı iddia edilen sağlam dış kitaplıkları kullanarak tek başına yazdığım yazılım için C ++ 'ı sevmememin nedenlerinden sadece birkaçı. Gerçek korku, diğer insanlarla takım halinde kod yazdığınızda başlar. Çok zeki C ++ hackerları veya acemiler olmaları neredeyse hiç önemli değil. Herkes hata yapar, ancak C ++ kasıtlı olarak onları bulmayı ve hatta gerçekleşmeden önce fark etmeyi zorlaştırır.

C ++ ile her zaman bir hata ayıklayıcı kullanmadan kaybolursunuz, ancak kodumun doğruluğunu kafamda doğrulayabilmeyi ve asla tahmin edemeyeceğim yollarda çalışan kodumu bulmak için bir hata ayıklayıcıya güvenmek zorunda kalmamayı seviyorum. Aslında tüm kodumu kafamda çalıştırmaya ve alt yordamlarda bile sahip olduğu tüm dalları almaya çalışıyorum ve sadece ara sıra sadece onun için hazırladığım tüm rahat yerlerde ne kadar güzel çalıştığını görmek için bir hata ayıklayıcı kullanmaya çalışıyorum. O kadar çok test senaryosu yazmak ve yürütmek ki, tüm kod yolları her türden tuhaf girdi verisi ile tüm kombinasyonlarda kullanılmıştır. Dolayısıyla, C ++ programlarındaki hataları bilmiyor olabilirsiniz, ancak bu onların orada olmadığı anlamına gelmez. C ++ projeleri ne kadar büyük olursa, elimizdeki tüm test verileriyle mükemmel bir şekilde çalışsa bile çok fazla tespit edilmemiş hataya sahip olmayacağına dair güvenim o kadar düşük olur. Sonunda onu çöpe atıyorum ve başka bir dil veya diğer dillerin kombinasyonuyla yeniden başlıyorum.

Devam edebilirdim ama sanırım şimdiye kadar amacımı netleştirmiştim. Tüm bunlar, C ++ 'da programladığımda kendimi verimsiz hissetmeme neden oldu ve kendi kodumun doğruluğuna olan güvenimi kaybetmeme neden oldu, bu da, 20'den fazla yazdığım C kodunu kullanmaya ve güvenmeye devam ederken artık kullanmayacağım anlamına geliyor. Yıllar önce. Belki de basitçe iyi bir C ++ programcısı olmadığım veya C ve diğer dillerde oldukça iyi olduğum için, C ++ söz konusu olduğunda gerçekte ne kadar lamer olduğumu fark etmeme izin veriyor ve bunu asla tam olarak anlayamayacağım .

Hayat kısa...

Düşük seviyeli bir gömülü ortamda, bazı "yazılım mühendisleri" bir EE geçmişine sahip olacak ve C'ye çok az hakim olacaklar. C ++ daha karmaşıktır ve bu adamlardan bazıları yeni bir dil öğrenmekten korkuyor. Bu nedenle C, en düşük ortak payda olarak kullanılır. (Bu adamlardan kurtulmayı önermeden önce, onlar en azından hardcore analog şeyleri anlamayan CS majörleri kadar önemlidir.)

Her ikisini de miras alma ve sürdürme deneyiminden bahsedersek: C'deki korkunç bir tasarımı anlamak, çözmek ve kullanılabilir bir şeye yeniden dönüştürmek zordur.

C ++ 'daki korkunç bir tasarım, rastgele soyutlama katmanları beyninizi kod tabanı etrafında hangi kodun hangi durumda çalıştırılacağını anlamaya çalışırken gönderdiği için sonsuz derecede daha kötüdür.

Harika tasarımlar üretmeyeceklerini bildiğim mühendislerle çalışmak zorunda kalırsam, ikincisinden çok birincisine sahip olmayı tercih ederim.

Gömülü sistemleri programlamak ve benzeri şeyler için bile kişisel hoşlanmama dışında bir neden görmüyorum. C ++ 'da yalnızca kullandığınız özellikler için genel gider ödersiniz. C ++ ek yükünün sizin için çok yüksek olduğu bazı özel durumlarda C ++ C alt kümesini kullanabilirsiniz. Bu, bazı C programcılarının bazı C ++ yapılarının ek yükünü abarttığını düşünüyorum. Birkaç örnek listeleyeyim:

• Sınıflar ve üye işlevler, normal işlevlere kıyasla sıfır ek yüke sahiptir (sanal işlevler kullanmadığınız sürece, bu durumda işlev işaretçileri kullanmaya kıyasla ek yük yoktur)
• Şablonların çok az ek yükü vardır (çoğu zaman hiçbir ek yükü yoktur)

Geçerli bir neden, iyi bir C ++ derleyicisine sahip olmayan (hiç C ++ derleyicisi olmayan veya bir derleyici mevcut, ancak zayıf bir şekilde uygulanmış ve bazı C ++ özellikleri için gereksiz bir yüksek ek yük uygulayan) bir platform için programlama yapıyorsanız olabilir.

İngilizce konuşmayı neden sınırlayasınız? Belki Sırpça'da daha yaratıcı bir yazar olurdunuz.

Bu, bariz yanılgılarla aynı argüman. Bir göreviniz varsa ve rahat araçlarınız görevi verimli bir şekilde çözerse, rahat araçlarınızı büyük olasılıkla iyi bir nedenle kullanacaksınız.

C ++ çok daha uzun bir öğrenme eğrisine sahiptir. C, bilmeniz gereken yalnızca birkaç yapıya sahiptir ve ardından güçlü yazılımları kodlamaya başlayabilirsiniz. C ++ 'da C tabanını, ardından OO'yu ve genel programlama, istisnayı vb. Öğrenmeniz gerekir. Ve bir süre sonra özelliklerin çoğunu öğrenebilir ve onları rahatlıkla kullanabilirsiniz, ancak yine de derleyicinin nasıl olacağını bilmiyorsunuz. bunları tercüme edin, ne kadar örtülü ek yükleri var ya da yok. Bu çok zaman ve enerji gerektirir.

Profesyonel bir proje için bu argüman geçerli olmayabilir, çünkü zaten C ++ 'yı çok iyi bilen kişileri istihdam edebilirsiniz. Ancak C'nin hala yaygın olduğu Açık Kaynak Projelerinde insanlar sevdikleri dili seçiyor ve kullanabiliyorlar. Her işletim sistemi programcısının profesyonel bir programcı olmadığını düşünün.

Dan Olson'ın cevabını takip etmek istiyorum. İnsanların C ++ 'ın potansiyel olarak tehlikeli ve üretkenliği azaltıcı özelliklerinden korktuğuna inanıyorum ve haklı olarak öyle. Ancak Dan'in söylediğinin aksine, iki nedenden dolayı bir kodlama standardına karar vermenin etkili olduğunu düşünmüyorum:

1. Kodlama standartlarının sıkı bir şekilde uygulanması zor olabilir
2. İyi bir tane bulmak çok zor olabilir.

Bence buradaki ikinci neden, birincisinden çok daha önemli, çünkü bir kodlama standardına karar vermek, kolayca siyasi bir mesele haline gelebilir ve daha sonra revizyona tabi olabilir. Aşağıdaki basitleştirilmiş durumu düşünün:

1. Stl kapsayıcıları kullanmanıza izin verilir, ancak şablonları kendi kodlarınızdan herhangi birinde kullanamazsınız.
2. İnsanlar, sadece bunu veya bu şablon sınıfını kodlamalarına izin verilirse daha üretken olacaklarından şikayet etmeye başlarlar.
3. Buna izin vermek için kodlama standardı revize edildi.
4. Eğimi, hiç kimsenin takip etmediği aşırı karmaşık bir kodlama standardına kaydırın ve standardın engellemesi gereken türden tehlikeli kodu, standardı çevreleyen aşırı bürokrasi ile birlikte kullanın.

(Standardın 3. adımda revize edilmemesi alternatifi, deneysel olarak dikkate alınamayacak kadar olası değildir ve zaten o kadar da iyi olmayacaktır.)

Birkaç yıl önce hemen hemen her şey için C ++ kullanmış olsam da, C veya C ++ ile ele alınması gereken ve diğer her şeyin başka bir şekilde yapılması gereken düşük seviyeli görevlerde C'nin tercih edilebilir olduğunu şiddetle hissetmeye başlıyorum. tamamen dil. (Yalnızca bazı özel yüksek performanslı sorunlu etki alanlarının olası istisnaları, wrt. Blitz ++ )

Kitaplık kodunu yazarken C kullanıyorum veya en azından bir C arayüzünü dışa aktarıyorum.

Kötü tanımlanmış ABI sorunları istemiyorum.

C ++ yerine C kullanmak için ikna edici olduğunu düşündüğüm hiçbir argüman görmedim. Bence çoğu insan, C ++ 'nın sunduğu belirli özelliklerden, genellikle haklı olarak korkuyor. Yine de bu beni ikna etmiyor çünkü kodlama standartları aracılığıyla belirli özellikleri kullanıp kullanmama zorunluluğu getirilebilir. C'de bile kaçınmak isteyeceğiniz çok şey var. C ++ 'ı tamamen bir kenara atmak aslında C'ye göre daha iyi bir kod yazmasına yardımcı olacak somut bir fayda sağlamadığını söylüyor, ki bu oldukça cahil olduğunu düşündüğüm bir görüş.

Ek olarak, insanlar her zaman C ++ derleyicisinin bulunmadığı platformların durumunu yükseltiyor gibi görünüyor. Kesinlikle burada C uygun olurdu, ancak bu günlerde böyle bir platform bulmakta zorlanacağınızı düşünüyorum.

Henüz dile getirilmediğim bir nokta, bence en önemlisi:

Günlük olarak kullandığım kitaplıkların çoğu Python, Ruby, Perl, Java, vb. İçin bağlamaları olan C kitaplıklarıdır. Gördüğüm kadarıyla, C kitaplıklarını 19 farklı dil bağlamasıyla sarmak olduğundan çok daha kolay. C ++ kitaplıklarını sarın.

Örneğin, Kahire'yi bir kez öğrendim ve o zamandan beri onu 3 veya 4 farklı dilde kullandım. Büyük zafer! Gelecekte tekrar kullanılabilecek bir program yazmayı tercih ederim ve diğer programlama dillerine kolayca uyarlanabilecek bir program yazmak bunun aşırı bir örneğidir.

C ++ kitaplıklarını bağlamanın mümkün olduğunu biliyorum, ancak AFAICT aynı değil. Qt (v3 ve v4) 'ü diğer dillerde kullandım ve kullanımı o kadar da güzel değil: C ++' ı başka bir dilde yazmak istiyorlar, yerel kitaplıklar gibi değil. (Dizeler olarak C ++ yöntem işaretlerini iletmelisiniz!)

Bir kez kullanılacak bir işlev yazıyorsanız veya tüm dünyanın C ++ olduğunu düşünüyorsanız, C ++ muhtemelen daha iyi bir dildir. Başlangıçtan itibaren dil taşınabilirliği için tasarlıyorsanız, C daha kolay bir dil gibi görünüyor.

Windows çekirdek geliştirme, c ++ 'ı desteklemiyor (ne yazık ki).

Linus Torvalds C iyilik neden hakkında bir eğlenceli rant okuyabilir burada

Mac'teki yerel kod, amaç-c'dir. Bir bilgisayardaki yerel kod c (window.h) veya c ++ (mfc) 'dir. Bu ortamların her ikisi de c'yi çok az değişiklik yaparak veya hiç değiştirmeden kullanmanıza izin verir. Bir kod kitaplığının çapraz platform olmasını istediğimde ansi c iyi bir seçim gibi görünüyor.

Birkaç neden düşünebilirim.

Tatmin edici bir C ++ derleyicisi olmayabilir. C ++ çok daha büyük bir dil ve ben modern C ++ ile başa çıkamayacak sistemlerde C derleyicileri çalıştırıyorum.

Soru soran veya birlikte çalıştığı kişiler C'ye aşina olabilir ancak C ++ 'ya aşina olmayabilir.

Proje C'de olabilir. C'ye bazı C ++ özellikleri eklemek mümkün olsa da, bu kolayca sürdürülemez bir karmaşaya yol açabilir. Bir dili veya diğerini seçmenizi öneririm (pratik olduğunda genellikle C ++).

Sorgulayan kişi, C ++ 'nın öğrenme eğrisinin eski bir görünümüne sahip olabilir. (Doğru yaklaşıldığında, C'lerden daha kolaydır. Gördüğüm çoğu giriş kitabı ona doğru yaklaşmıyor.)

C ve C ++ 'nın iki farklı dil olduğunu ve zamanla daha da farklılaştığını unutmayın. Her ikisinde de aynı anda kodlama yapmak kötü bir fikirdir ve C ++ 'ın C benzeri bir alt kümesini kullanmak, C ++' nın avantajlarının çoğunu kaçırır.

İki dilde bir ortamda çalışıyorsanız, performans açısından kritik bazı düşük düzeyli işlevler için C'yi ve iş mantığı için C # / Java gibi daha işlevsel / yüksek düzeyli bir dili kullanabilirsiniz. Bu işlevler için C ++ kodu kullanılıyorsa, JNI / yönetilmeyen kod için C-Wrappers gerekir ve bu, işleri yalnızca C kullanmaktan daha karmaşık hale getirir.

C programlama ile C ++ kullanıyorum iki nedenden dolayı:

• vectorve stringdizi bellek yönetimini benden uzaklaştırmak için
• Aksi takdirde özleyeceğim tüm sıkıntıları uyarmak ve / veya yakalamak için sıkı tip kontrolü ve yayınlar.

Yani C gerçekten birkaç c ++ ödünç alıyor ama elimden geldiğince c ++ derleyicisini kullanıyor. Bir başkasının cevaplarda söylediği gibi, şimdi aslında bu şekilde daha fazla C ++ aldığımı ve C'nin fazla dahil olduğu yerlerde C ++ kullanıyorum. RAII kullanarak İzleme / Kilitleme, son zamanlarda çok iş parçacıklı programlarla uğraşırken kullandığım bunlardan biri ve dosyaları açmak / kapatmak için başka bir benzer yapı.

Bence C daha taşınabilir. Yaklaşık 5 yıl önce kodu birçok unix çeşidine (AIX, Irix, HPUX, Linux) taşımak için bazı işler yaptım. C kodunu taşımak kolaydı, ancak bazı C ++ kodlarını taşımakta çeşitli sorunlar yaşadık. Belki sadece olgunlaşmamış geliştirme ortamlarıydı ama bu nedenle C ++ yerine C'yi kullanmayı tercih ederim ...

1. C basit bir dildir, C ++ değildir. Pek çok insan için, C ++ tamamen ustalaşmak için çok karmaşıktır, bkz. Http://en.wikipedia.org/wiki/C%2B%2B#Criticism .

2. Karmaşıklık nedeniyle, farklı programcılar genellikle yalnızca dilin farklı alt kümelerinde uzmanlaşırlar. Başkalarının kodunu okumayı acı verici hale getirir.

3. Dilin karmaşıklığı, tuzakları çok fazla dikkat dağınıklığı yaratır ve bazen üretkenliğe zarar verir. İşin kendisine odaklanmak yerine, kendimi çoğu zaman dilin kendisiyle savaşırken buldum. Java / python daha üretken alternatiflerdir.

4. Bozuk bir C kodunda hata ayıklamak, genellikle bozuk bir C ++ kodunda hata ayıklamaktan çok daha basittir.

5. Java / C #'dan farklı olarak, C ++ standart kitaplığı, C standart kitaplığının kapsamının çok az ötesine ulaşır.

6. Linus Torvalds (Linux) ve Richard Stallman (Emacs) gibi bazı ünlü programcılar C ++ 'dan hoşlanmazlar.

Çoğu programcı, herkesin kaliteyi yüksek bir öncelik olarak görmesini doğal kabul eder. Bu her zaman böyle değildir. C'ye alışkınsanız, C ++ perde arkasında sizin için çok şey yapıyor gibi görünebilir. C ++ 'da tür denetiminin katılığı da sınırlayıcı görünebilir. Pek çok kişi, C ++ 'nın bu "sıkıntılardan" kaçınmaya yardımcı olabileceği türden hataları ortaya çıkarma riskini almaya isteklidir.

Aklıma gelen üç neden var. Birincisi, C'nin ikili dosyalarının küçük boyutu ve herhangi bir sistemde C derleyicilerin daha geniş kullanılabilirliği nedeniyle gömülü sistemler için daha uygun olmasıdır. İkincisi taşınabilirliktir: C daha küçük bir dildir ve ANSI C kodu her yerde derlenecektir. C ++ 'da taşınabilirliği kırmak daha kolaydır. Sonuncusu dilin kendisidir. C ++ daha zordur ve kesinlikle çok zayıf tasarlanmış bir dildir. Torvalds kavramaları yukarıda bildirilmiştir. Ayrıca C ++ Sıkça Sorulan Cevaplara ( http://yosefk.com/c++fqa/ ) da bakmak isteyebilirsiniz .

Taşınabilirlik bir sorun olabilir. Gordon Carpenter-Thomp'un cevabından farklı olarak, bunun daha ziyade farklı linux / unix sürümlerinde farklı libstdc ++ sürümlerinin çalışma zamanı desteği olduğunu öneriyorum. Bununla ilgili iyi bir tartışma için bu bağlantıya bakın . Küçük bir alıntı:

Bir C ++ uygulamasının farklı bölümleri tarafından kullanılan çalışma zamanı destek kodunun uyumlu olması gerekir. Programın bir bölümünün dinamik yayın yapması veya bir başkası tarafından sağlanan nesneleri yakalamaya ihtiyacı varsa, her iki bölümün de belirli uygulama ayrıntıları üzerinde anlaşması gerekir: vtables nasıl bulunur, yığını nasıl çözülür vb.

C ++ ve benzer özelliklere sahip diğer birkaç GCC destekli dil için, bu tür ayrıntılar bir C ++ ABI tarafından belirtilir. GCC tarafından kullanılan ABI her değiştiğinde, farklı GCC sürümleri tarafından üretilen uyumsuz kitaplıklarla karşılaşırsınız. Aynısı düz C için de geçerlidir, ancak C ABI çok daha basittir ve çok daha uzun süredir ortalıkta olduğu için oldukça kararlıdır.

Burada her iki yönde de birçok öneriyi takip edebilirim. Ama sonuçta a) karşılaştırılabilir basit b) karşılaştırılabilir kompleks.

Birinin bir tür dil karmaşıklığı ölçümünü "icat ettiği" konusunda bir fikrim yok.

0-10 arası bir ölçekte muhtemelen C'yi 2 veya 3 olarak değerlendiririm, C ++ ise 8-10 arasında olur. C ++ 'nın en karmaşık dillerden biri olduğunu iddia ediyorum ama örneğin Ada, PL1 veya benzerlerini bilmiyorum, bu yüzden belki başka bir dil ile karşılaştırıldığında o kadar karmaşık değil.

C ++, C'nin tüm karmaşıklığını miras alır, bu nedenle C'nin karmaşıklık düzeyinin altında olamaz.

Benim açımdan, bazı betik dillerini ve C'yi kullanarak çok daha rahat olurdum. Dolayısıyla, sonunda aşağıdaki soruyu yanıtlamak zorunda. "Daha fazlası her zaman daha mı iyidir?"

C'de bulduğum en yararlı şey, ad alanlarının ve aşırı yüklenmelerin olmaması: işlev ve sembol adları benzersiz tanımlayıcılardır. Bu sembollerin kullanıldığı yerleri bulmak için, sadece grepkaynak kod dosyalarını inceleyebilirsiniz ve arama sonuçları konumları gösterir.

Yeni bir özelliği veya bileşeni eski ve karışık bir sisteme bağlarken önemlidir.

Bunu karmaşık bir arama grafiği oluşturma aracı olmadan C ++ 'da kolayca yapamazsınız.

Çoğu insan C ve C ++ 'nın bir şekilde ilişkili olduğunu düşünüyor gibi görünüyor, ancak ne yazık ki yanılıyorlar. C ++, C'den tamamen farklı bir dildir.

C ++ 'da nesneler ve birbirleriyle nasıl ilişkili oldukları açısından düşünürsünüz. C'de, API'ler açısından düşünürsünüz. Gün ile 17 arasındaki fark gibi.

Zayıf bir benzetme: Biri İngilizceye Çince'yi ekler ve buna İngilizce ++ diyorsa, muhtemelen son aşk mektubunuza Çince bir satır eklemekte rahat hissetmezsiniz, çünkü İngilizce ++ 'nın bu bölümünde sevgiyi ifade etmek çok daha kolay.

Aşağıdakiler, bir projeyi C ile sınırlamanın neden faydalı olabileceğinin tüm nedenleridir:

• daha hızlı derleme çünkü dil çok daha basit
• daha az çalışma zamanı desteği gerektirir, bu da onu düşük seviyeli ortamları daha uygun hale getirir
• diğer dillerle arayüz oluşturmak çok daha kolay
• yığın üzerinde değişken boyutlu dizileri destekler
• isim değiştirme olmadığından montaj kodunu okumak daha kolay
• fiilen standart uygulama ikili arabirimi olduğundan farklı derleyiciler tarafından üretilen kodun kolayca birleştirilmesine izin verir