Haruskah saya berhenti menggunakan istilah C / C ++?

Saya mengerti C dan C ++ adalah bahasa yang berbeda tetapi ketika saya belajar C ++ saya selalu diberitahu bahwa C adalah bagian dari C ++ atau C ++ adalah C dengan kelas. Dan itu cukup benar sampai munculnya C ++ x0, C ++ 11 (atau C ++ 11/14/17 modern secara umum). Bahkan (terutama ketika bekerja pada sistem embedded) sangat mungkin untuk menemukan kode yang ditulis dalam C ++ tetapi dengan banyak bagian yang ditulis seluruhnya dalam bahasa C murni. Di sini saya punya beberapa pertanyaan:

1. Haruskah saya berhenti menggunakan istilah C / C ++?
2. Jika jawaban ke # 1 adalah ya, bagaimana saya memanggil program yang menggunakan campuran C dan C ++?
3. Mengingat bahwa keduanya adalah bahasa yang 'berbeda', ada kemungkinan bahwa pada titik tertentu kompiler C ++ berhenti mendukung kode yang ditulis dalam bahasa C (karena c ++ modern menyimpang dari mentalitas C untuk hal-hal dasar seperti pointer, penanganan memori dinamis, dll)
4. Apakah sekarang ada kolaborasi antara orang-orang yang membuat standar C / C ++ untuk menjaga kompatibilitas
5. Jika # 4 adalah ya, kolaborasi tersebut dapat berakhir dalam waktu dekat dengan munculnya c ++ modern (11/14/17)

Saya tahu bahwa sudah ada pertanyaan serupa, tetapi saya yakin bahwa banyak orang membagikan pertanyaan ini jadi saya sangat tertarik untuk mendapatkan jawaban yang baik terutama untuk poin-poin yang berkaitan dengan kecenderungan C ++ dalam waktu dekat.

C tidak pernah menjadi bagian dari C ++. Contoh paling jelas dari hal ini adalah int new;. Ini benar sejak C89 dan C ++ 98, dan bahasa-bahasa hanya tumbuh lebih jauh satu sama lain ketika standar baru telah keluar.

Haruskah saya berhenti menggunakan istilah C / C ++

Iya

Jika jawaban ke # 1 adalah ya, bagaimana saya memanggil program yang menggunakan campuran C dan C ++?

File sumber ditulis dalam satu bahasa atau yang lain. Suatu program dapat terdiri dari kode dari beberapa bahasa yang bekerja bersama-sama, atau sebuah executable yang dihasilkan dengan menghubungkan berbagai objek yang dikompilasi. Anda akan mengatakan program itu ditulis dalam C dan C ++, "C / C ++" bukan bahasa.

Mengingat keduanya adalah bahasa yang 'berbeda', ada kemungkinan bahwa pada titik tertentu kompiler C ++ berhenti mendukung kode yang ditulis dalam bahasa C

3) Mereka tidak pernah melakukannya. char *a = malloc(10);. C dan C ++ belum pernah sepenuhnya kompatibel setidaknya selama mereka memiliki standar ISO (saya tidak tahu semua detail tentang hari-hari pra-standar). klik tautan atau lihat di bawah untuk file yang baik-baik saja dengan C89 dan lebih tinggi, tetapi tidak valid di bawah standar C ++ apa pun.

4) afaik tidak, kelompok kerja saling menyadari satu sama lain tetapi standar membuat keputusan yang terbaik untuk diri mereka sendiri.

/* 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) { }

Saya selalu merasa perlu menyebutkan bahwa C adalah bagian dari Objective-C.

Ada memiliki menjadi alasan mengapa hal ini datang bersama-sama begitu sering. Meskipun Anda seharusnya tidak memberi tahu guru C Anda bahwa bahasanya adalah bagian dari C ++, ada beberapa kebenaran di sini. Orang lain sudah mengungkapkan sudut pandang guru Anda. Ini sangat bagus (dan diilustrasikan dengan contoh, dll.). Tapi kita tidak hidup di menara gading, atau buku.

Bos besar Anda tidak peduli tentang bahasa yang Anda gunakan. Jika dia tahu sedikit tentang pemrograman, katakan saja Anda menggunakan C / C ++ dan itu akan terdengar seperti "Saya menggunakan bahasa yang perlu dikompilasi ke kode mesin, dengan DLL dan semua hal yang rumit". Ini adalah bagian "komunikasi eksternal".

Jika Anda membuat perpustakaan yang dapat dihubungkan oleh C dan C ++, Anda pasti ingin menyebutnya pustaka C / C ++. Tentu saja, seseorang akan mengangkat tangan dan bertanya mengapa Anda tidak menyebutnya pustaka C yang kebetulan memiliki pembungkus C ++, dan lagi pula C ++ dapat menautkan ke pustaka C sehingga Anda tidak perlu menyebutkannya sama sekali. Jawab saja: "Ya, Anda benar, ini adalah perpustakaan C / C ++". Ini adalah bagian "komunikasi internal".

Jika Anda membuat analisa leksikal untuk C ++, Anda akan terkejut betapa baiknya kerjanya dengan C. Anda bahkan mungkin tidak perlu memodifikasi semuanya. Ini adalah "jika terlihat seperti bebek, dll." bagian.

Dll

Mayoritas program C yang pernah saya lihat kompilasi (dan bekerja) tanpa modifikasi sebagai kode C ++. Jangan biarkan beberapa pengecualian atau programer dogmatis (betapapun berpengaruh) menipu intuisi Anda. C dan C ++ sangat dekat, dan seringkali kompatibel, dan sering dicampur dan dicocokkan bersama, sehingga istilah C / C ++ digunakan. Ini digunakan karena berguna untuk menggambarkan situasi seperti ini di mana tidak terlalu penting apakah Anda mempertimbangkan C atau C ++, asalkan bukan Java atau PHP . Kita tahu itu "salah", tetapi kita tidak peduli, itu lebih bermanfaat daripada salah.

Mungkin disalahgunakan, mungkin bodoh, tapi tetap saja, saya tidak yakin manfaat apa yang akan Anda dapatkan dengan menjadi lebih bertele-tele daripada yang dibutuhkan dan menolak untuk berkomunikasi dengan cara yang dipahami orang lain. Jika Anda merasa tidak nyaman dalam beberapa situasi tertentu, maka jangan gunakan istilah umum C / C ++, tetapi yang relevan dengan kasus (baik C atau C ++).

Jangan takut dengan masa depan. Sistem operasi kami ditulis dalam C. Cukup banyak C / C ++ produksi perangkat lunak saat ini terjadi di C ++. Pasangan ini akan tinggal sebentar di sini. Tidak ada yang tertarik pada satu yang dibuat lebih tidak kompatibel dengan yang lain (sebenarnya sebaliknya).

Untuk lebih spesifik tentang poin Anda:

1) Itu tergantung. Ya ketika itu dapat menyebabkan kebingungan, ketika Anda merasa tidak nyaman, atau ketika itu salah atau di luar konteks. Tidak ketika Anda merasa sudah cukup.

2) N / A

3) Saya pikir tidak, tapi saya tidak punya bola kristal.

4) tidak tahu

5) Saya tidak berpikir sehingga tidak ada yang mendorong ke arah ini

Melawan arus saya akan mengatakan itu tergantung pada konteksnya .

Istilah "C / C ++" biasanya tidak sesuai ketika mengatakan sesuatu seperti "ini adalah program C / C ++", tetapi ini telah dieksplorasi secara mendalam pada jawaban lain.

Namun, mungkin ada konteks di mana C / C ++ dapat sesuai.

• Ada berbagai pustaka yang biasanya memiliki API C dan C ++. Saya kira itu tidak jauh dari kebenaran jika Anda menyebutnya perpustakaan C / C ++. Kita manusia suka mengompres informasi, sehingga mengatakan "opencv adalah perpustakaan C / C ++" pendek, jelas, dan dapat dimengerti, bandingkan dengan mengatakan "opencv adalah perpustakaan, yang dikirimkan dengan header baik untuk C dan C ++".
• Anda dapat berbicara tentang desain bahasa dan sintaksis. Dari sudut pandang sintaks bahasa, Anda mungkin mengatakan bahwa suatu bahasa memiliki sintaks mirip C / C ++.
• Anda mengatur kontes coding, dan Anda menerima kedua solusi yang ditulis dalam C dan C ++
• Anda sedang merekrut seorang programmer baru, dan sebagian besar tugasnya adalah C atau C ++, sehingga programmer diharapkan mengetahui kedua bahasa tersebut. Ini umum dalam pengembangan tertanam, di mana C lebih cocok untuk beberapa mikrokontroler (biasanya sangat kecil), dan C ++ untuk yang lain. Dalam hal ini Anda mungkin mengatakan Anda mencari seorang programmer C / C ++.

Secara umum, pengguna SO meminta orang yang mengajukan pertanyaan untuk memilih bahasa: C atau C ++. Mengapa?

Ada banyak perbedaan halus antara C dan C ++. Misalnya, dalam C ++, sebuah constvariabel di lingkup global memiliki hubungan internal kecuali dideklarasikan extern, tetapi di C memiliki hubungan eksternal kecuali dinyatakan static. Dengan mengatakan "C / C ++", OP menegaskan pengetahuan bahwa jawaban untuk pertanyaan mereka adalah sama di C dan C ++, ketika itu sangat baik mungkin tidak. Hal ini tentu saja mempersulit calon penjawab.

• Terkadang kita dapat melihat bahwa kode tidak valid dalam satu bahasa atau yang lain (misalnya, konversi implisit dari void*ke penunjuk ke objek tidak valid dalam C ++). Ini menyebalkan. Mengapa Anda mengatakan "C / C ++" ketika Anda memiliki sepotong kode yang valid dalam C tetapi tidak C ++? Apakah Anda bermaksud C, atau ini hanya kesalahan dalam kode yang dimaksudkan sebagai C ++?

• Kadang-kadang jawabannya akan berbeda tergantung pada bahasa (misalnya, array panjang variabel ada di C99 tetapi tidak di C ++). Jika kami tidak tahu bahasa apa yang Anda bicarakan, kami harus menebak, atau menulis jawaban untuk keduanya ketika hanya satu yang benar-benar bermanfaat, karena Anda tahu bahasa apa yang sebenarnya Anda gunakan; Anda hanya tidak memberi tahu kami!

• Terkadang jawabannya benar-benar sama untuk kedua bahasa, tetapi sulit untuk memastikannya. Sebagai contoh, saya pikir C dan C ++ memiliki aturan konversi integer yang sama, tetapi agar benar-benar yakin, saya harus membaca kedua standar dengan cermat. Sekali lagi, ini membuat saya melakukan pekerjaan dua kali lebih banyak dari yang diperlukan ketika Anda mungkin hanya peduli pada salah satu bahasa.

Bagaimanapun, untuk menjawab pertanyaan Anda yang lain:

1. Iya.

2. Jika Anda menautkan kode C dan C ++, Anda dapat menggunakan kedua tag tersebut, tetapi harap sebutkan bahasa masing-masing file.

3. Terkadang ada perubahan yang dipatahkan, tetapi jarang terjadi dan biasanya berdampak terbatas (jika tidak disetujui). Misalnya, autodalam C ++ 11.

4. Saya tidak berpikir mereka berkolaborasi secara langsung, tetapi mereka memperhatikan perkembangan dalam bahasa lain dan mencoba menghindari memperkenalkan perubahan yang akan membuat kompatibilitas lebih sulit.

Dan jika Anda benar-benar ingin tahu tentang kedua bahasa itu, tidak apa-apa, dan Anda bisa mengatakan itu dalam pertanyaan Anda. Ketika Anda mengatakan "C / C ++", saya benar-benar tidak yakin apa yang Anda maksud, dan sepertinya Anda membuat asumsi tentang dua bahasa tersebut.

Saya selalu diberitahu bahwa C adalah himpunan bagian dari C ++ atau C ++ adalah C dengan kelas. Dan itu tenang benar sampai munculnya C ++ x0, C ++ 11 (atau C ++ 11/14/17 modern secara umum).

C tidak pernah menjadi bagian dari C ++. Misalnya C89 bukan bagian dari C ++ 98.

Beberapa contoh:

• formulir daftar pengidentifikasi C89 untuk pernyataan parameter fungsi tidak didukung di C ++
• C89 dan C ++ 98 memiliki tipe berbeda untuk konstanta karakter
• C89 dan C ++ 98 memiliki tipe berbeda untuk string literal
• operator logis menghasilkan berbagai jenis dalam C89 dan C ++ 98 ( intvs bool)

1. Haruskah saya berhenti menggunakan istilah C / C ++?

Iya.

2. Jika jawaban ke # 1 adalah ya, bagaimana saya memanggil program yang menggunakan campuran C dan C ++?

Suatu program adalah C atau C ++ (jika bahkan beberapa program yang sangat mendasar dapat dikompilasi dengan kompiler C atau C ++). Kompiler apa yang Anda gunakan untuk mengkompilasinya? Itu harus menjawab pertanyaan Anda. Harbison & Steele menciptakan istilah Clean C untuk menunjuk subset umum C dan C ++ tapi saya pikir itu ide yang buruk.

EDIT : Namun saya mengakui bahwa secara teknis Anda dapat menautkan file objek C dan C ++ dalam satu program tetapi OTH ada banyak bahasa yang diizinkan untuk dicampur dalam satu program misalnya Java dan C ++. Saya pikir menggunakan istilah C / C ++ program hanya menambah kebingungan bahwa itu ditulis dalam satu bahasa yang disebut C / C ++.

3. Mengingat bahwa keduanya adalah bahasa yang 'berbeda', ada kemungkinan bahwa pada titik tertentu kompiler C ++ berhenti mendukung kode yang ditulis dalam bahasa C (karena c ++ modern menyimpang dari mentalitas C untuk hal-hal dasar seperti pointer, penanganan memori dinamis, dll)

Ada banyak fitur (contoh: array panjang variabel, anggota array fleksibel _Generic,, ...) dari C99 atau C11 yang tidak didukung oleh versi C ++.

Beberapa program ditulis dalam campuran C dan C ++

Ini hanya fakta kehidupan. Anda dapat mengkompilasi file objek dari C dan C ++ dan menautkannya bersama. Hasilnya cukup bisa disebut "program C / C ++".

Tapi itu hanya program secara keseluruhan. Bagaimana dengan unit kompilasi individu?

Ada subset dari C yang juga merupakan subset dari C ++

Suatu program (atau unit kompilasi) yang ditulis dalam subset itu akan mengkompilasi dan berperilaku sama di bawah kompiler C dan C ++ yang sesuai. Program atau file seperti itu dapat dengan tepat disebut "program C / C ++" atau "file C / C ++".

Program parsial seperti file header juga dapat digunakan di kedua program C dan C ++. File header seperti itu dapat dengan tepat disebut sebagai header C / C ++.

Mengutip Profesor Bjarne Stroustrup:

Apakah C bagian dari C ++?

Dalam pengertian matematis yang ketat, C bukan bagian dari C ++. Ada program yang valid C tetapi tidak valid C ++ dan bahkan beberapa cara penulisan kode yang memiliki arti berbeda dalam C dan C ++. Namun, C ++ mendukung setiap teknik pemrograman yang didukung oleh C. Setiap program C dapat ditulis pada dasarnya dengan cara yang sama dalam C ++ dengan run-time dan efisiensi ruang yang sama. Bukan hal yang aneh untuk dapat mengubah puluhan ribu baris ANSI C ke C-style C ++ dalam beberapa jam. Dengan demikian, C ++ adalah superset dari ANSI C sebagaimana ANSI C adalah superset dari K&R C dan sebanyak ISO C ++ adalah superset dari C ++ seperti yang ada pada tahun 1985.

Ditulis dengan baik C cenderung legal C ++ juga. Misalnya, setiap contoh di Kernighan & Ritchie: "Bahasa Pemrograman C (Edisi ke-2)" juga merupakan program C ++.

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

Jadi ya ada yang namanya C / C ++. Ini adalah segala sesuatu yang valid C dan valid C ++.

Pra-prosesor C adalah bagian dari bahasa C. Pra-prosesor C ++ adalah bagian dari bahasa C ++

Anda dapat menulis unit kompilasi yang akan dikompilasi di bawah C atau C ++ dan berbeda . Misalnya, ini mungkin memiliki fungsionalitas dasar yang dikompilasi dalam C tetapi mengambil keuntungan dari pustaka C ++ jika dikompilasi dalam C ++.

Jika program pada dasarnya sama, tetapi dengan fitur tambahan, tidak salah untuk mengatakan itu adalah program yang sama. Itu sama, tetapi juga berbeda.

Kebanyakan programmer C dapat melakukan setidaknya sedikit C ++ dan sebaliknya

Bukanlah tidak masuk akal untuk menyebut orang seperti itu seorang programmer C / C ++. Ya, mereka mungkin spesialisasi dalam satu, tetapi ada orang yang adalah C kompeten atau C ++ programmer yang benar-benar tidak bisa melakukan apa pun dari bahasa lain? Di satu sisi, bukankah mereka semua programmer C / C ++?

Tidak ada yang salah dengan mengatakan "C / C ++". Yang penting sedang dipahami

Bahasa Inggris bukan alat untuk mengekspresikan silogisme . Anda dapat menggunakan bahasa Inggris untuk logika, tetapi hanya adil, dan dengan usaha keras.

Ini karena kata-kata tidak secara alami memiliki makna yang tepat, tetapi lebih merupakan awan samar dari denotasi dan konotasi. Yang penting adalah jika orang mengerti apa yang Anda katakan.

1. Haruskah saya berhenti menggunakan istilah C / C ++?

Benar. Tidak jelas apa yang ingin diungkapkan oleh konstruk ini kecuali, mungkin, kebingungan tentang apa yang C dan C ++ atas nama orang yang menggunakan istilah tersebut.

Karena kebingungan ini merupakan sumber frustrasi yang umum, banyak orang menjadi sangat emosional tentang hal itu dan penampilan istilah itu saja akan menjadi alasan yang cukup bagi mereka untuk menjadi negatif tentang kontribusi Anda. Ini mungkin tampak konyol tetapi tampaknya seperti yang kita miliki.

Saya merekomendasikan bahwa alih-alih berbicara tentang "C / C ++" Anda menggunakan istilah yang benar-benar menjelaskan apa yang Anda maksud.

• Jika Anda berbicara tentang sesuatu di C yang mungkin atau tidak mungkin juga berlaku untuk C ++, hanya mengatakan C .

  Contoh: Bagaimana seharusnya mainfungsi tersebut dinyatakan dalam C?

  Pada awalnya, sepertinya jawaban untuk C ++ sama: int main()atau int main(int, char**). Tetapi ketika diskusi berlangsung, mungkin relevan untuk menunjukkan bahwa dalam C ++, fungsi tersebut harus dideklarasikan pada lingkup global, yang tidak masuk akal dalam C, karena tidak memiliki namespaces. Di sisi lain, C memungkinkan panggilan mainsecara rekursif sementara C ++ tidak. Di C ++, ada implisit return 0;jika Anda "jatuh" maintetapi dalam C returnpernyataan diperlukan di jalan apa pun. Daftar berjalan dan membuat diskusi lebih sederhana jika Anda membuatnya jelas di muka apa bahasa yang akan dibahas.

• Jika Anda berbicara tentang sesuatu dalam C ++ yang mungkin atau mungkin juga tidak berlaku untuk C, cukup katakan C ++ .

  Contoh: Apakah malloc()array ed intpada awalnya adalah all-nol di C ++?

  Jawaban singkat untuk C kebetulan sama: tidak. Tetapi ketika jawabannya terus berlanjut, mungkin bermanfaat untuk menunjukkan bahwa dalam C, callocakan menjadi alternatif yang baik sementara di C ++, menggunakan std::vector<int>mungkin merupakan pilihan yang lebih baik di tempat pertama.

• Jika Anda ingin menunjukkan kesamaan antara C dan C ++, ucapkan C dan C ++ .

  Contoh: Dalam C dan C ++, yang sizeofmerupakan intadalah implementasi didefinisikan dan dapat bervariasi antara compiler dan arsitektur.

  Di sini, kami ingin menunjukkan bahwa C dan C ++ berperilaku dengan cara yang sama. Kami secara eksplisit berbicara tentang kedua bahasa.

Saya sebenarnya menyarankan agar Anda lebih spesifik dan tidak hanya berbicara tentang "C" atau "C ++" tetapi versi yang tepat. Kedua bahasa tersebut berevolusi dan pernyataan tumpul seperti

C ++ mendukung /* … */dan // …berkomentar sementara C hanya mendukung /* … */style.

tidak benar atau salah.

2. Jika jawaban ke # 1 adalah ya, bagaimana saya memanggil program yang menggunakan campuran C dan C ++?

Karena bahasa memiliki tumpang tindih, setiap program C akan berisi bagian yang mungkin terlihat seperti C ++ dan sebaliknya. Namun demikian, penulis mungkin akan memilih menggunakan kompiler C atau C ++. Jadi katakan “program ini ditulis dalam C ” jika dikompilasi dengan kompiler C dan “program ditulis dalam C ++ ” jika mereka menggunakan kompiler C ++, bahkan jika mereka mungkin menolak untuk menggunakan fitur C ++ modern. Beberapa orang menyebut kode C ++ seperti C-style C ++ . Tidak adanya overloading, pengecualian, polimorfisme, templat dan I / O stream karakteristik umum dari kode tersebut.

Jika, sebaliknya, beberapa file yang ditulis dalam C dan dikompilasi dengan kompiler C dan beberapa lainnya file yang ditulis dalam C ++ dan dikompilasi dengan C ++ compiler, dan kemudian file objek terkait bersama-sama, saya akan mengatakan bahwa “program ini ditulis dalam sebuah campuran C dan C ++ "seperti, pada kenyataannya, Anda sudah melakukannya.

Namun, jika, sebagai gantinya, penulis sangat berhati-hati untuk menulis setiap file sedemikian rupa sehingga dapat dikompilasi dengan kompiler C atau C ++ dan program yang dihasilkan akan melakukan hal yang sama, Anda dapat mengatakan bahwa “program ditulis dalam subset umum dari C dan C ++ ”.

Yang terakhir sering terjadi pada file header yang harus dibagi antara kode C dan C ++. Ngomong-ngomong, menulis kode semacam itu tidak mudah. Jika Anda ingin lebih menekankan bahwa hanya konstruksi seperti yang digunakan yang berlaku di C dan C ++ dan secara luas didukung oleh vendor compiler yang berbeda, istilah yang portabel bagian umum dari C dan C ++ dapat digunakan untuk menekankan ini.

3. Mengingat keduanya adalah bahasa yang “berbeda”, apakah ada kemungkinan bahwa pada titik tertentu kompiler C ++ berhenti mendukung kode yang ditulis dalam bahasa C (karena C ++ modern menyimpang dari mentalitas C untuk hal-hal dasar seperti pointer, penanganan memori dinamis, dll)?

Saya tidak yakin saya mengerti pertanyaan ini. Karena C dan C ++ adalah bahasa yang berbeda, Anda tidak dapat mengharapkan kompiler untuk salah satu dari mereka menerima program yang ditulis untuk yang lain. Namun, kompiler sering dirancang dengan cara modular dan jika kompiler memiliki C + + front-end , kemungkinan bagus itu juga akan memiliki C front-end. (Anda kemudian akan memilih yang mana dari yang Anda inginkan melalui saklar baris perintah atau cara serupa.) Selama kedua bahasa akan digunakan secara luas, tampaknya sangat tidak mungkin bahwa ini akan berubah. Poin Anda tentang "C ++ modern" Saya pikir pada dasarnya adalah masalah standar pengkodean yang baik dan perpustakaan standar. Dari sudut pandang kompiler , evolusi kedua bahasa agak konvergen daripada menyimpang.

4. Apakah sekarang ada kolaborasi antara orang-orang yang membuat standar C / C ++ untuk menjaga kompatibilitas?

Iya. Model memori dan pustaka operasi atom yang diperkenalkan dalam C ++ 11 dan C11 adalah contoh yang baik. Tampaknya para perancang kedua bahasa menyadari bahwa kompatibilitas itu penting dan berupaya meningkatkannya. Secara pribadi, saya berharap kolaborasi ini lebih intens dan dua kelompok kerja ISO bahkan mungkin bergabung, tetapi keinginan saya tidak penting.

Bjarne Stroustrup berbicara tentang perbedaan dan kesamaan antara berbagai versi C dan C ++ di § 44,3 dari edisi ke 4 Bahasa Pemrograman C ++ yang, ironisnya, berjudul "C / C ++ Kompatibilitas". Penggunaan istilah ini mungkin sebenarnya sesuai untuk kasus ini karena jelas apa yang dimaksud.

5. Jika # 4 adalah ya, kolaborasi tersebut dapat berakhir dalam waktu dekat dengan munculnya C ++ modern (11/14/17)

Seperti dibahas di atas, itu terjadi di C ++ 11 dan diharapkan / diharapkan / perlu terjadi lagi.

C / C ++ adalah persimpangan C dan C ++.

int new;bukan C / C ++, dan tidak juga vector<int> foo;.

Demikian pula, C89 / C99 adalah persimpangan dari dua bahasa ini, di mana tidak ada enum bool { false, true };atau for(int i = 0;;)diizinkan.

Dan C ++ 11 / C ++ 14, dll.

Dimungkinkan untuk menulis kode yang mengkompilasi (dan berjalan dengan benar) di bawah C ++ 11 dan C ++ 14, walaupun kompilasi di bawah satu tidak berarti mengkompilasi di bawah yang lain. Faktanya, banyak orang melakukan ini.

Dan banyak orang menulis kode yang bekerja di C dan C ++.

Jelas, semakin besar tumpang tindih, semakin masuk akal; Saya tidak berharap melihat pertanyaan tentang kode C / C ++ / Java.

Meskipun "masuk akal" untuk berbicara tentang subset umum dari bahasa-bahasa ini, banyak pertanyaan tidak akan memiliki jawaban dalam subset ini, misalnya Apa yang seharusnya main () kembali dalam C dan C ++?

Tetapi Anda dapat berbicara tentang kode yang berfungsi untuk spesifikasi berbagai bahasa, apakah spesifikasi itu dibedakan berdasarkan "versi" atau "nama bahasa" atau sebaliknya.

Ini adalah semacam tanggapan terhadap posisi bahwa "ini adalah kode untuk programmer yang bekerja dekat dengan logam dan tidak apa-apa dalam konteks manajemen" terlihat dalam beberapa jawaban dan komentar lainnya.

Saya berpendapat bahwa bahkan interpretasi itu harus dijaga dengan hati-hati.

Dimulai paling tidak pertengahan tahun 90-an jika Anda menginginkan seorang programmer C ++ dan seseorang yang menggambarkan diri mereka sebagai seorang programmer C yang diterapkan, Anda harus bertanya seberapa banyak mereka tahu tentang desain berorientasi objek, berapa banyak pengalaman yang mereka miliki dengan debugging pada suatu objek konteks yang berorientasi, dan tentang kemampuan mereka untuk menggunakan perpustakaan templat. Anda ingin menyelidiki dengan tepat masalah-masalah tersebut selama wawancara dan proses perekrutan.

Di sisi lain, sekarang sudah lebih dari satu dekade sejak guru C ++ mulai mendorong "C ++ modern" yang berarti penekanan pada perpindahan dari pointer kosong ke objek pointer yang lebih aman dan idiom berbasis iterator. Dengan munculnya C ++ 11 sekarang ada dukungan eksplisit untuk pemrograman multi-paradigma dan dorongan menuju kode yang tidak menunjukkan bare pointer sangat kuat. Apa artinya itu adalah bahwa jika saya mewawancarai seorang programmer C ++ untuk posisi C hari ini, saya akan sangat khawatir untuk memeriksa seberapa akrab orang ini dengan pointer aktual yang diaktifkan penembakan kaki.

Saya tidak berada dalam bisnis akhir-akhir ini (bahkan ketika saya masih berada di Stack Overflow saat masih bayi), jadi saya tidak akan berani menebak seberapa sering orang yang diwawancarai khayalan tidak memiliki keterampilan cross-over, tetapi Saya pikir seperti yang paling sering diterapkan bahasa sekarang memang sangat berbeda.

Singkatnya "C / C ++" harus dijatuhkan tidak hanya dalam konteks teknis tetapi dalam sebagian besar konteks bisnis juga.

Jawaban paling sederhana untuk pertanyaan ini adalah Anda seharusnya tidak menggunakan istilah itu. Itu adalah istilah yang seharusnya tidak ada. Tidak ada artinya. Setiap program adalah C, atau C ++.

Dan itu tenang benar sampai munculnya C ++ x0, C ++ 11 (atau C ++ 11/14/17 modern secara umum).

C ++ 98 dan 03 bahkan bukan C jarak jauh dengan Kelas. Siapa pun yang mengajarimu ini tidak tahu apa-apa dan kau bisa melupakannya. Ini tidak pernah benar.

Secara konseptual, seharusnya tidak ada kesulitan khusus dalam mendesain file sumber C sehingga mereka juga dapat dikompilasi apa adanya dengan C ++. Memang ada beberapa keuntungan signifikan untuk melakukan ini. Misalnya, ketika menulis kode untuk sistem tertanam, terkadang bermanfaat untuk dapat menguji kode pada lingkungan PC yang dihosting. Jika kode dikompilasi dengan bersih sebagai C ++, dimungkinkan untuk memiliki pernyataan seperti "MOTOR_ENABLE = 1;" menulis ke bit I / O yang mudah menguap pada sistem embedded (dikompilasi sebagai C), tetapi memicu logika emulasi pada PC (dikompilasi sebagai C ++). Mungkin juga akan mungkin untuk mendesain tipe C ++ pada PC yang akan berperilaku seperti yang dilakukan uint16_t pada sistem embedded yang lebih kecil (sehingga misalnya u16 x=65533;, kompiler harus memperhatikan nilai darix*xsebagai sembilan, daripada memiliki pemerintahan bebas untuk melakukan apa pun yang diinginkannya), meskipun belum ada emulator saya yang memasukkan itu [sebagian karena kompiler C ++ yang saya gunakan belum melakukan hal yang aneh dalam kasus seperti itu].

Sayangnya, pemrogram C dan pemrogram C ++ memiliki antipati yang cukup terhadap satu sama lain sehingga bahasa, selama bertahun-tahun, berevolusi dengan cara yang kompatibel. Sementara C89 berusaha untuk mengadaptasi beberapa fitur yang lebih berguna dari C ++ (seperti prototipe fungsi) suatu sikap tampaknya telah muncul bahwa programmer yang menginginkan salah satu fitur C ++ harus menggunakan C ++, mengabaikan fakta bahwa ada banyak situasi di mana ia akan akan membantu untuk dapat menggunakan beberapa fitur C ++ (mis. kemampuan untuk membebani fungsi dengan tautan inline statis atau statis tanpa harus menerima biaya yang terkait dengan fitur lain yang tidak diperlukan seseorang (mis. nama mangling yang terkait dengan ekspor) fungsi kelebihan beban).

Sementara persimpangan C89 dan C ++ 98 adalah bahasa yang bisa dikerjakan, superset yang dapat digunakan dari versi C yang lebih baru dengan versi C ++ yang lebih baru mungkin menyusut daripada tumbuh (berkat hal-hal seperti Aturan Keterbatasan Mengasingkan) dan tren mendukung yang selalu ada. meningkatkan celah.