C / C ++ terimini kullanmayı bırakmalı mıyım?

C ve C ++ 'nın farklı diller olduğunu anlıyorum ama C ++' ı öğrenirken her zaman C 'nin C ++' nın bir alt kümesi olduğu ve C ++ 'nın C sınıfı olduğu söylendi . Ve bu, C ++ x0, C ++ 11 (ya da genel olarak modern C ++ 11/14/17) ortaya çıkana kadar oldukça doğruydu. Aslında (özellikle gömülü sistemler üzerinde çalışırken), C ++ dilinde yazılmış, ancak tamamen saf C dilinde yazılmış birçok parçayla kod bulmak çok muhtemeldir. İşte birkaç sorum var:

1. C / C ++ terimini kullanmayı bırakmalı mıyım?
2. # 1 cevabı evet ise, C ve C ++ karışımı kullanan bir programı nasıl çağırırım?
3. Her ikisinin de 'farklı' dilleri olduğu göz önüne alındığında, bir noktada C ++ derleyicilerinin C dilinde yazılmış kodu desteklemeyi bırakması muhtemeldir (modern c ++, işaretçiler, dinamik bellek kullanımı vb. Gibi temel şeyler için C zihniyetinden ayrılmaktadır).
4. Şu anda uyumluluğu korumak için C / C ++ standartlarını yapan kişiler arasında herhangi bir işbirliği var mı?
5. Eğer # 4 ise, bu tür bir işbirliği yakın gelecekte modern c ++ ' nın görünümü ile sona erebilir (11/14/17)

Ben zaten benzer soruların olduğunu biliyorum, ancak birçok insanın bu soruları paylaştığından eminim, bu yüzden özellikle yakın gelecekte C ++ eğilimi ile ilgili olan noktalar için iyi cevaplar almakla çok ilgileniyorum.

C hiçbir zaman bir C ++ alt kümesi olmadı. Bunun en açık örneği int new;. Bu, C89 ve C ++ 98’den beri geçerliydi ve diller birbirinden daha da yeni standartlar çıktıkça daha da büyüdü.

C / C ++ terimini kullanmayı bırakmalı mıyım?

Evet

# 1 cevabı evet ise, C ve C ++ karışımı kullanan bir programı nasıl çağırırım?

Kaynak dosya, bir dilde veya diğerinde yazılmıştır. Bir program, birlikte çalışan birden çok dilden gelen koddan veya farklı derlenmiş nesneleri birbirine bağlayarak üretilen bir yürütülebilir dosyadan oluşabilir. Programın C ve C ++ ile yazılmış olduğunu söylersiniz, "C / C ++" bir dil değildir.

Her ikisinin de 'farklı' dil olduğu göz önüne alındığında, bir noktada C ++ derleyicilerinin C dilinde yazılmış kodu desteklemeyi bırakması olasıdır.

3) Hiç yapmadılar. char *a = malloc(10);. C ve C ++ , en azından ISO standartlarına sahip oldukları sürece hiçbir zaman tam olarak uyumlu hale gelmedi (önceden standartlaştırılmış günlerle ilgili tüm ayrıntıları bilmiyorum). linkleri tıklayın veya C89 ve üstü ile uyumlu ancak herhangi bir C ++ standardında geçerli olmayan bir dosya için aşağıya bakın.

4) hayır, çalışma grupları birbirlerinin farkındalar ancak standartlar kendileri için en uygun kararları veriyor.

/* A bunch of code that compiles and runs under C89 but fails under any C++ */

/* type aliases and struct names occupy separate namespaces in C, not in C++ */
struct S { int i; };
typedef int S;


struct Outer { struct Inner { int i; } in; };
/* struct Inner will be Outer::Inner in C++ due to name scope */
struct Inner inner;


/* default return type of int in C, C++ functions need explicit return types */
g() {
    return 0;
}


/* C sees this as two declarations of the same integer,
 * C++ sees it as redefinition */
int n;
int n;


/* K&R style argument type declarations */
void h(i) int i; { }


/* struct type declaration in return type */
struct S2{int a;} j(void) { struct S2 s = {1}; return s; }


/* struct type declaration in argument, stupid and useless, but valid */
/*void dumb(struct S3{int a;} s) { } */


/* enum/int assignment */
enum E{A, B};
enum E e = 1;


void k() {
    goto label; /* C allows jumping past an initialization */
    {
        int x = 0;
label:
        x = 1;
    }
}


/* () in declaration means unspecified number of arguments in C, the definition
 * can take any number of arguments,
 * but means the same as (void) in C++  (definition below main) */
void f();

int main(void) {
    f(1); /* doesn't match declaration in C++ */
    {
        /* new is a keyword in C++ */
        int new = 0;
    }

    /* no stdio.h include results in implicit definiton in C.  However,
     * as long as a matching function is found at link-time, it's fine.
     * C++ requires a declaration for all called functions */
    puts("C is not C++");
    {
        int *ip;
        void *vp = 0;
        ip = vp; /* cast required in C++, not in C */
    }
    return 0;
}

/* matches declaration in C, not in C++ */
void f(int i) { }

Hep C belirtmekte yarar var hissetmek olduğunu Objective-C bir alt kümesi.

Orada var bu terimler sık sık bir araya gelip bir nedeni olmaya. C öğretmenine dilinin C ++ 'nın alt kümesi olduğunu söylememelisin, burada bazı gerçekler var. Diğerleri zaten öğretmeninizin bakış açısını gözler önüne sermiştir. Bu çok hoş (ve örnekler ile gösterildi, vb.). Fakat fildişi bir kulede ya da bir kitapta yaşamıyoruz.

Büyük patronun, kullandığın dili daha az önemsemedi. Programlama hakkında biraz şey biliyorsa, ona sadece C / C ++ kullandığını ve "Makine koduna, DLL'lere ve tüm karmaşık şeylere sahip bir kod kullandım" gibi geleceğini söyle. Bu "dış iletişim" kısmıdır.

Hem C hem de C ++ ile arabirim oluşturabilecek bir kütüphane oluşturursanız, kesinlikle C / C ++ kütüphanesi olarak adlandırmak istersiniz. Tabii ki, birileri yardım edecek ve neden C ++ sargısı olan bir C kütüphanesi olarak adlandırılmadığını soracaktır ve yine de C ++ C kitaplıklarına bağlanabilir, böylece bundan hiç bahsetmenize gerek kalmaz. Sadece cevap verin: "Evet, haklısınız, bu bir C / C ++ kütüphanesidir". Bu "iç iletişim" kısmıdır.

C ++ için sözlüksel bir çözümleyici oluşturursanız, C ile ne kadar iyi çalıştığını görünce şaşıracaksınız. "Ördeğe benziyorsa vs." Bölüm.

Vb.

Gördüğüm C programlarının çoğu C ++ kodu olarak değiştirilmeden derlendi (ve çalışıyor). Birkaç istisna veya dogmatik (ancak etkili) programcıların sezginizi kandırmasına izin vermeyin. C ve C ++ çok yakın ve çok sık uyumludur ve sık sık birlikte karıştırılır ve eşleştirilir, C / C ++ terimi kullanılır. Java ya da PHP olmadığı sürece, C ya da C ++ 'ı göz önünde bulundurmanızın gerçekten önemli olmadığı bu tür durumları tanımlamakta faydalı olduğu için kullanılır . Bunun "yanlış" olduğunu biliyoruz, ama umursamıyoruz, yanlış olmaktan daha faydalı.

Suistimal edilebilir, aptal olabilir, ama yine de, gereğinden fazla bilgiçlik yaparak ne gibi bir kazanç elde edeceğinizden emin değilim ve başkalarının anlayacağı şekilde iletişim kurmayı reddediyorum. Belirli bir durumda huzursuz hissediyorsanız, sadece C / C ++ genel terimini kullanmayın, ancak durumla alakalı olanı kullanın (C veya C ++).

Gelecekten korkma. İşletim sistemlerimiz C dilinde yazılmıştır. C / C ++ yazılım programlarının çoğu C ++ 'ta gerçekleşmektedir. Bu çift bir süre kalmak için burada. Kimse birinden diğerine daha fazla uyumsuzluğa ilgi duymuyor (aslında tam tersi).

Puanlarınız hakkında net olmak için:

1) bağlıdır. Evet, bir karışıklığa yol açabileceği zaman, huzursuz hissettiğinizde ya da sadece yanlış ya da bağlam dışı olduğunda. Yeterli olduğunu düşündüğünde hayır.

2) Yok

3) Hayır sanırım ama kristal topum yok.

4) fikrim yok

5) Hiçbir şey bu yöne iter diye düşünmüyorum

Akıntıya karşı çıkmak , içeriğe bağlı olduğunu söyleyebilirim .

"C / C ++" terimi genellikle "bu bir C / C ++ programıdır" gibi bir şey söylerken uygun değildir, ancak bu diğer cevaplarda derinlemesine incelenmiştir.

Bununla birlikte, C / C ++ 'ın uygun olabileceği bağlamlar olabilir.

• Genellikle hem C hem de C ++ API içeren çeşitli kütüphaneler vardır. Sanırım böyle bir şeye C / C ++ kütüphanesi diyorsan, gerçeğinden uzak değil. Biz, bilgileri sıkıştırmayı severiz, "opencv bir C / C ++ kütüphanesidir" demek, kısa, açık ve anlaşılabilirdir, "opencv, hem C hem de C ++ için başlıklarla birlikte gönderilen bir kütüphanedir" ifadesiyle karşılaştırın.
• Dil tasarımı ve sözdizimi hakkında konuşabilirsiniz. Dil sözdizimi açısından, bir dilin C / C ++ benzeri bir sözdizimine sahip olduğunu söyleyebilirsiniz.
• Bir kodlama yarışması düzenliyorsunuz ve hem C hem de C ++ ile yazılmış çözümleri kabul ediyorsunuz.
• Yeni bir programcı tutuyorsunuz ve görevlerin çoğu C veya C ++ olacak, bu nedenle programcının her iki dili de bilmesi bekleniyor. C'nin bazı (genellikle çok küçük) mikrodenetleyiciler için daha uygun olduğu ve diğerleri için ise C ++ 'nın gömülü gelişiminde yaygındır. Bu durumda bir C / C ++ programcısı aradığınızı söyleyebilirsiniz.

Genel olarak, SO kullanıcıları soruyu soran kişiden bir dil seçmesini ister: C veya C ++. Neden?

C ve C ++ arasında birçok ince fark var. Örneğin, C ++ 'da, constglobal kapsamdaki bir değişken bildirilmediği sürece iç bağlantıya sahiptir extern, ancak C'de bildirilmediği sürece dış bağlantıya sahiptir static. "C / C ++" diyerek OP, soruya verilen cevabın hem C hem de C ++ 'da aynı olamayacağına dair bilgiyi iddia ediyor. Bu, gereksiz cevap verenler için işleri zorlaştırır.

• Bazen, kodun bir dilde veya diğerinde geçerli olmadığını görebiliriz (örneğin, void*işaretçi ile nesneden nesneye örtülü dönüşümler C ++ 'da geçerli değildir). Bu can sıkıcı bir durum. C ++ 'da geçerli olan ancak C ++' da geçerli bir kod parçanız varken neden "C / C ++" diyorsunuz? C niyetinde miydin, yoksa bu sadece C ++ olması gereken koddaki bir hata mı?

• Bazen cevap, dile bağlı olarak farklılık gösterebilir (örneğin, değişken uzunluklu diziler C99'da bulunur, ancak C ++ dilinde değildir). Hangi dilden bahsettiğimizi bilmiyorsak, ya tahmin etmek zorundayız ya da ikisinin de ne zaman gerçekten yararlı olacağı konusunda bir cevap yazmalıyız, çünkü gerçekte hangi dili kullandığınızı biliyorsunuzdur; Sadece bize söylemiyorsun!

• Bazen cevap her iki dilde de aynıdır ancak emin olmak zor. Örneğin, C ve C ++ 'ın aynı tamsayı dönüşüm kurallarına sahip olduğunu düşünüyorum, ancak gerçekten, gerçekten emin olmak için her iki standardı da dikkatlice okumak zorundayım. Yine, bu muhtemelen dillerden sadece birini önemsiyorsan, bana iki kat daha fazla iş yapmamı sağlıyor.

Neyse, diğer sorularınızı cevaplamak için:

1. Evet.

2. C ve C ++ kodlarını birbirine bağlıyorsanız, her iki etiketi de kullanmak kabul edilebilir, ancak lütfen her dosyanın hangi dilde olduğunu belirtin.

3. Bazen kırılma değişiklikleri olabilir, ancak nadir görülürler ve genellikle etkileri sınırlıdır (aksi halde onaylanmazlar). Örneğin, autoC ++ 11’de.

4. Doğrudan işbirliği yaptıklarını sanmıyorum, ancak diğer dildeki gelişmelere dikkat ediyorlar ve uyumluluğu daha da zorlaştıracak değişiklikler yapmaktan kaçınmaya çalışıyorlar.

Ve eğer iki dili de gerçekten bilmek istiyorsanız, sorun değil ve bunu sorunuza söyleyebilirsiniz. "C / C ++" deyince ne demek istediğinizi tam olarak anlayamadım ve iki dil hakkında bir varsayımda bulunmuş gibi görünüyorsunuz.

Her zaman C'nin bir C ++ alt kümesi olduğu ya da C ++ 'nın C sınıfı olduğu söylenirdi. Ve bu, C ++ x0, C ++ 11 (ya da genel olarak modern C ++ 11/14/17) ortaya çıkana kadar sessizdi.

C hiçbir zaman C ++ 'in alt kümesi olmamıştır. Örneğin, C89, C ++ 98'in bir alt kümesi değildir.

Birkaç örnek:

• işlev parametresi bildirimi için C89 tanımlayıcı listesi formu C ++ 'da desteklenmiyor
• C89 ve C ++ 98 karakter sabitleri için farklı türleri vardır
• C89 ve C ++ 98 dize değişmezleri için farklı türleri var
• mantıksal operatörler, C89 ve C ++ 98'de ( intvs bool) farklı türler verir

1. C / C ++ terimini kullanmayı bırakmalı mıyım?

Evet.

2. # 1 cevabı evet ise, C ve C ++ karışımı kullanan bir programı nasıl çağırırım?

Bir program C veya C ++ (eğer çok temel bir program bile bir C veya C ++ derleyicisi ile derlenebilirse). Derlemek için hangi derleyiciyi kullanıyorsunuz? Soruna cevap vermeli. Harbison & Steele , C ve C ++ ortak bir alt kümesini belirlemek için Clean C terimini kullandı, ancak bunun kötü bir fikir olduğunu düşünüyorum.

EDIT : Ancak teknik olarak C ve C ++ nesneleri dosyalarını tek bir programda bağlayabileceğinizi itiraf ediyorum, ancak OTH, örneğin Java ve C ++ gibi tek bir programda karıştırılmasına izin verilen birçok dil var. C / C ++ programını kullanmanın sadece C / C ++ adlı tek bir dilde yazılmış olduğu karmaşasına katkıda bulunduğunu düşünüyorum.

3. Her ikisinin de 'farklı' dilleri olduğu göz önüne alındığında, bir noktada C ++ derleyicilerinin C dilinde yazılmış kodu desteklemeyi bırakması muhtemeldir (modern c ++, işaretçiler, dinamik bellek kullanımı vb. Gibi temel şeyler için C zihniyetinden ayrılmaktadır).

_GenericC99 veya C11'in C ++ sürümleri tarafından desteklenmeyen birçok özellik (örnek: değişken uzunluk dizisi, esnek dizi üyesi ,, ...) vardır.

Bazı programlar C ve C ++ karışımı ile yazılmıştır.

Bu sadece yaşamın bir gerçeğidir. Nesne dosyalarını C ve C ++ 'dan derleyebilir ve bunları birbirine bağlayabilirsiniz. Sonuç oldukça makul bir şekilde "C / C ++ programı" olarak adlandırılabilir.

Ama bu sadece bir bütün olarak program. Bireysel derleme birimleri ne durumda?

C ++ 'nın bir alt kümesi olan bir C altkümesi var.

Bu alt kümede yazılmış bir program (veya derleme ünitesi), C ve C ++ derleyicileri uyarınca aynı şekilde derlenecek ve davranacaktır. Böyle bir program veya dosya haklı olarak "bir C / C ++ programı" veya "bir C / C ++ dosyası" olarak adlandırılabilir.

Başlık dosyası gibi kısmi bir program hem C hem de C ++ programlarında da kullanılabilir. Bu gibi başlık dosyalarına haklı olarak C / C ++ başlıkları denebilir.

Alıntı yapan Profesör Bjarne Stroustrup:

C, C ++ alt kümesi mi?

Kesin matematiksel anlamda C, C ++ 'nın alt kümesi değildir. Geçerli C ++ olan, ancak geçerli olmayan C ++ programları ve hatta C ve C ++ dillerinde farklı anlamlara sahip kod yazma yöntemleri de vardır. Bununla birlikte, C ++, C tarafından desteklenen her programlama tekniğini destekler. Her C programı, aynı çalışma zamanı ve alan verimliliği ile C ++ dilinde aynı şekilde yazılabilir. Birkaç saat içinde, on binlerce ANSI C satırını C stili C ++ 'ya dönüştürmek nadir değildir. Bu nedenle, C ++, ANSI C'nin bir üst kümesidir, ANSI C, bir K&R C'nin üst kümesidir ve ISO C ++, 1985'te olduğu gibi C ++'ın bir üst katıdır.

İyi yazılmış C de yasal C ++ olma eğilimindedir. Örneğin, Kernighan & Ritchie'deki her örnek: "C Programlama Dili (2. Baskı)" aynı zamanda bir C ++ programıdır.

• http://www.stroustrup.com/bs_faq.html#C-is-subset

Yani evet , C / C ++ diye bir şey var. Hem geçerli C hem de geçerli C ++ olan herhangi bir şey.

C ön işlemcisi, C dilinin bir parçasıdır. C ++ ön işlemcisi C ++ dilinin bir parçasıdır

C veya C ++ altında derlenecek ve farklı olacak bir derleme birimi yazabilirsiniz . Örneğin, C'de derlenmiş temel fonksiyonlara sahip olabilir, ancak C ++ 'da derlenmişse bir C ++ kütüphanesinden yararlanın.

Program aslında aynıysa, ancak ek özelliklere sahipse, aynı program olduğunu söylemek yanlış olmaz . Aynı, aynı zamanda farklı.

Çoğu C programcısı en az bir miktar C ++ ve bunun tersi yapabilir.

Böyle bir kişiye C / C ++ programcısı demesi mantıklı değildir. Evet, muhtemelen birinde uzmanlaşırlar, ancak kelimenin tam anlamıyla diğer dillerden birini yapamayan yetkin bir C veya C ++ programcısı olan biri var mı? Bir şekilde, hepsi C / C ++ programcıları değil mi?

"C / C ++" derken yanlış bir şey yok. Önemli olan ne anlaşılıyor?

İngilizce, dilbilgileri ifade etmek için bir araç değildir . Sen edebilirsiniz mantık için İngilizce kullanmak, ama sadece ve büyük çabayla.

Bunun nedeni, kelimelerin doğal olarak kesin anlamlara sahip olmaları değil, belirsiz bir ifade ve çağrışım bulutundan ibaret olmasıdır. Önemli olan, insanlar söylediklerinizi anlarsa.

1. C / C ++ terimini kullanmayı bırakmalı mıyım?

Kesinlikle. Bu yapının neyi ifade etmesi gerektiği açık değil, belki de, C ve C ++ 'nın terimi kullanan kişi adına ne olduğu konusunda kafa karışıklığı dışında.

Bu karışıklık bu kadar yaygın bir hayal kırıklığı kaynağı olduğundan, birçok insan bu konuda oldukça duygusal bir hal aldı ve bu terimin tek başına ortaya çıkması, katkılarınız konusunda olumsuz olmaları için yeterli neden olacak. Bu aptalca görünebilir ama elimizdekiler gibi görünüyor.

“C / C ++” hakkında konuşmak yerine, aslında ne demek istediğinizi açıkça belirten bir terim kullanmanızı öneririm.

• C ++ 'ta C ++ için de geçerli olabilecek ya da olmayabilecek bir şeyden bahsediyorsanız, sadece C deyin .

  Örnek: İşlev C dilinde nasıl mainbildirilmelidir?

  İlk başta, C ++ cevabının aynı olduğu görünebilir: int main()veya int main(int, char**). Ancak tartışma devam ettikçe, C ++ 'da, işlevin global kapsamda bildirilmesi gerektiğini, bunun C de bir anlam ifade etmeyeceğini, çünkü namespaces' ye sahip olmadığını belirtmek uygun olabilir . Öte yandan, C maintekrarlayan bir şekilde C ++ çağırırken izin verir . C ++ 'da return 0;“düşmek” durumunda bir örtüklük vardır, mainancak C'de returnherhangi bir yolda ifade gereklidir. Liste devam eder ve tartışılacak dilin ne olduğunu açıkça belirtirseniz, tartışmayı çok daha basit hale getirir.

• C ++ 'da C için de olabilecek ya da olmayabilecek bir şeyden bahsediyorsanız, sadece C ++ deyin .

  Örnek: Bir Will malloc()ed dizisi ints başlangıçta C ++ her sıfır olabilir mi?

  C için kısa cevap aynı olur: hayır. Ancak cevap devam ettikçe, callocC ++ 'ın iyi bir alternatif std::vector<int>olabileceğini, ilk etapta daha iyi bir seçim olabileceğini belirtmek faydalı olabilir.

• C ve C ++ arasındaki benzerliği işaret etmek istiyorsanız, C ve C ++ tuşlarına basın .

  Örnek: C ve C ++ 'da, sizeofbir intuygulama tanımlanmıştır ve derleyiciler ve mimariler arasında değişebilir.

  Burada, C ve C ++ 'nın aynı şekilde davrandığını belirtmek isteriz. Açıkça her iki dilden de bahsediyoruz .

Aslında daha spesifik olmanızı ve sadece “C” veya “C ++” hakkında değil, tam sürüm hakkında konuşmanızı da öneririm. Her iki dil de evrim geçiriyor ve böyle açık bir cümle

C ++ yalnızca C stili destekler, yorum /* … */ve // …yorumlar /* … */.

ne doğru ne de yanlış.

2. # 1 cevabı evet ise, C ve C ++ karışımı kullanan bir programı nasıl çağırırım?

Dillerin çakışması nedeniyle, her bir C programı, C ++ 'ya benzeyebilecek veya bunun tersi görünebilecek parçalar içerecektir . Bununla birlikte, yazarlar muhtemelen bir C veya C ++ derleyicisi kullanmaya karar vermişlerdir. Yani “programı yazılmıştır söylemek C bir C derleyicisi ve” programı yazılır ile derlenmiş ise “ C ++ onlar herhangi bir modern C ++ özelliklerini kullanmayı reddetme olsalar bile, onlar C kullanırsanız ++ Derleyici”. Bazı insanlar C ++ kodunu C tarzı C ++ olarak adlandırır . Aşırı yüklenmenin olmaması, istisnalar, polimorfizm, şablonlar ve G / Ç bu kodun ortak bir özelliğini taşır.

Bunun yerine, bazı dosyalar C dilinde yazılır ve bir C derleyicisi ile derlenir ve diğer bazı dosyalar C ++ ile yazılırsa ve bir C ++ derleyicisi ile derlenir ve ardından birbirine bağlanan nesne dosyaları, “program bir C ve C ++ 'nın karışımı ”aslında aslında yaptınız.

Bununla birlikte, yazarlar her dosyayı bir C veya C ++ derleyicisi ile derlenebilecek şekilde yazmak için büyük özen göstermişlerse ve sonuçta ortaya çıkan program aynı şeyi yapacaktır, “programın ortak bir C ve C ++ alt kümesinde yazılmıştır ”.

İkincisi, genellikle C ve C ++ kodu arasında paylaşılması gereken başlık dosyaları için geçerlidir. Bu arada, böyle bir kod yazmak kolay değil. Eğer daha fazla ancak böyle yapılar C ve C ++ içinde geçerli olduğunu kullanıldığını vurgulamak istiyorsanız ve çok farklı derleyici satıcılar tarafından desteklenmektedir terimi bir taşınabilir C ve C ++ ortak alt küme kullanılabilir bu vurgulamak.

3. Her ikisinin de “farklı” dilleri olduğu göz önüne alındığında, bir noktada C ++ derleyicilerinin C dilinde yazılmış kodları desteklemekten vazgeçmesi olasıdır (modern C ++, işaretçiler, dinamik bellek kullanımı vb. Gibi temel şeyler için C zihniyetinden uzaklaşmaktadır)?

Bu soruyu anladığımdan emin değilim. C ve C ++ yana olan farklı dil, bunlardan biri için bir derleyici diğeri için yazılmış bir programı kabul bekleyemezsiniz. Bununla birlikte, derleyiciler genellikle modüler bir şekilde tasarlanmıştır ve bir derleyicinin bir C ++ ön ucu varsa , olasılıklar iyidir, ayrıca bir C ön ucuna sahip olacaktır. (Daha sonra bunlardan hangisini komut satırı düğmesi veya benzer yöntemlerle istediğinizi seçersiniz.) Her iki dil de yaygın kullanımda olduğu sürece, bunun değişmesi pek mümkün görünmüyor. “Modern C ++” hakkındaki düşünceniz temel olarak iyi kodlama standartları ve standart kütüphane meselesidir. Gönderen derleyici'nın açısından, her iki dilde evrimi yerine uzaklaşan daha yakınsama olduğunu.

4. Şu anda uyumluluğu korumak için C / C ++ standartlarını yapan kişiler arasında herhangi bir işbirliği var mı?

Evet. Bellek modeli ve C ++ 11 ve C11'de tanıtılan atomik işlemler kütüphanesi buna iyi bir örnektir. Her iki dilin tasarımcılarının da uyumluluğun önemli olduğunu ve onu geliştirmek için çalıştıklarını fark ettikleri görülüyor. Şahsen, işbirliğinin daha yoğun olmasını ve iki ISO çalışma grubunun belki de bir araya gelmesini diliyorum, ancak dileklerim önemli değil.

Bjarne Stroustrup, C ve C ++ sürümleri arasındaki farkları ve ortaklıkları , ironik bir şekilde “C / C ++ Uyumluluğu” başlıklı C ++ Programlama Dilinin 4. baskısının § 44.3'ünde konuşur . Terimin kullanımı, bu durumda ne anlama geldiği açıkça belli olduğundan, uygun olabilir.

5. Eğer # 4 evet ise, böyle bir işbirliği yakın bir gelecekte modern C ++ 'ın ortaya çıkması ile sonuçlanabilir (11/14/17).

Yukarıda tartışıldığı gibi, C ++ 11'de gerçekleşti ve tekrar olması bekleniyor / umuyor / gerekiyordu.

C / C ++, C ve C ++ ile kesişimdir.

int new;C / C ++ değil ve ikisi de değil vector<int> foo;.

Benzer şekilde, C89 / C99 ne bu iki dil, kesişme olduğu enum bool { false, true };veya for(int i = 0;;)izin verilir.

Ve C ++ 11 / C ++ 14 vb.

Birinin altında derleme, diğeri altında derlenme anlamına gelmese de, C ++ 11 ve C ++ 14 altında derleyen (ve doğru çalışan) kod yazmak mümkündür. Aslında, birçok insan bunu yapar.

Ve birçok insan C ve C ++ 'da çalışan kod yazar.

Açıkçası, örtüşme ne kadar büyük olursa, o kadar anlamlı olur; C / C ++ / Java kodu hakkında herhangi bir soru görmeyi beklemiyorum.

Bu dillerin ortak bir alt kümesinden bahsetmek "mantıklı" olsa da, birçok soru bu alt kümede cevap vermeyecektir, örneğin C ve C ++ 'da main () ne dönmeli?

Ancak, bu özelliklerin "sürüm" veya "dil adı" veya başka bir şekilde farklılaştırılmış olup olmadığına bakılmaksızın, çoklu dil özellikleri için çalışan kod hakkında konuşabilirsiniz.

Bu, diğer cevap ve yorumların bazılarında görülen "bu, metale yakın çalışan programcılar için bir koddur ve yönetim bağlamında tamamdır" pozisyonuna bir cevaptır.

Bu yorumun bile dikkatli yapılmasını savunuyorum.

En azından 90'ların ortasından başlayarak, bir C ++ programcısı ve kendilerini bir C programcısı olarak tanımlayan biri istemeniz durumunda, nesneye yönelik tasarım hakkında ne kadar bilgi sahibi olduklarını, bir nesnede hata ayıklama konusunda ne kadar deneyime sahip olduklarını sormanız gerekirdi. odaklı bağlam ve şablon kütüphanelerini kullanma yetenekleri hakkında. Görüşme ve işe alım sürecinde tam olarak bu sorunları araştırmak istersiniz.

Kapak tarafında, C ++ guruları "modern C ++" yu bastırmaya başladığından bu yana on yıldan fazla bir süre geçti. C ++ 11'in ortaya çıkmasıyla birlikte, artık çok paradigma programlama için açık bir destek var ve hiçbir çıplak işaret göstermeyen koda doğru itme çok güçlü. Bunun anlamı, bugün bir C pozisyonu için bir C ++ programcısıyla röportaj yaparsam, bu kişinin gerçek, ayak atışlarına uygun işaretçilerle ne kadar tanıdık olduğunu kontrol etmekten çok endişe edeceğim.

Bugünlerde iş dünyasında değilim (Stack Overflow'un bebeklik dönemindeyken bile), bu nedenle hayali görüşmecilerin ne sıklıkla geçiş becerilerine sahip olamayacağı konusunda bir tahmin yapmayacağım. Bence en sık uygulanan diller artık gerçekten çok farklı.

Kısacası "C / C ++" sadece teknik bağlamlarda değil, aynı zamanda birçok iş ortamında da bırakılmalıdır.

Bu sorunun en basit cevabı bu terimi hiç kullanmamış olmanız gerektiğidir . Olmaması gereken bir terimdir. Bir anlamı yok. Her program C veya C ++.

Ve bu, C ++ x0, C ++ 11 (ya da genel olarak modern C ++ 11/14/17) ortaya çıkana kadar sessizdi.

C ++ 98 ve 03 sınıfları ile uzaktan bile C değil. Bunu sana kim öğretti, hiçbir şey bilmiyor ve onları unutabilirsin. Bu asla doğru olmadı.

Kavramsal olarak, C kaynak dosyalarının tasarlanmasında özel bir zorluk olmamalıdır, böylece C ++ ile olduğu gibi derlenebilirler. Bunu yapmanın gerçekten önemli avantajları olabilir. Örneğin, gömülü bir sistem için kod yazarken kodu barındırılan bir PC ortamında test edebilmek bazen yararlı olabilir. Kod C ++ gibi temiz bir şekilde derlenirse, "MOTOR_ENABLE = 1;" gibi bir deyim olabilir. Gömülü sistemdeki geçici bir G / Ç bitine (C olarak derlenir) yazın, ancak PC'deki emülasyon mantığını tetikleyin (C ++ olarak derlenir). Bilgisayarda, bir uint16_t'nin daha küçük gömülü sistemler üzerinde davranması gibi davranacak bir C ++ tipi tasarlanması da muhtemelen mümkün olacaktır (örn u16 x=65533;.x*xDokuz olarak, istediği herhangi bir şeyi yapmak için serbest hüküm sürmek yerine), ancak henüz öykünücülerimin hiçbiri [kısmen kullandığım C ++ derleyicileri bu gibi durumlarda tuhaf bir şey yapmadı].

Ne yazık ki, C programcıları ve C ++ programcıları, dillerin yıllar içinde uyumlu şekillerde geliştiği birbirlerine karşı yeterli antipatiye sahipler. C89, C ++ 'ın (faydalı prototipler gibi) bazı faydalı özelliklerinden bazılarını adapte etmeye çalışırken, C ++' ın özelliklerinden herhangi birini isteyen programcıların C ++ 'ı kullanmaları gerektiği, bunun birçok durumda olacağı gerçeğini göz ardı ederek bir tutum ortaya çıktığı görülmektedir. C ++ 'nın bazı özelliklerini (örneğin, gerekmeyen diğer özelliklerle ilgili maliyetleri kabul etmek zorunda kalmadan statik veya statik satır içi bağlantıya sahip işlevleri aşırı yükleme yeteneği (örneğin, dışa aktarma ile ilgili isim yönetimi) kullanabilmek için yardımcı olabilirsiniz. aşırı yüklenmiş işlevler).

C89 ve C ++ 98'in kesişimi çalışılabilir bir dil olsa da, daha sonraki C sürümlerinin C ++ sürümleriyle kullanılabilir olması büyük olasılıkla büyümekten ziyade küçülmüştü (Strict Aliasing Rule gibi şeyler sayesinde) ve trendler her zaman lehinedir. artan çatlak.