C / C ++という用語の使用をやめるべきですか？
私はCとC++が異なる言語であることを理解していますが、C++を学んでいたとき、常にCはC++のサブセットまたはC++はクラス付きのCであると言われました。そしてそれは、C++ x0、C++ 11（または最近のC++ 11/14/17の一般）が登場するまではまったく同じでした。実際（特に組み込みシステムで作業している場合）、C++で書かれたコードを見つける可能性は非常に高いですが、多くの部分が完全に純粋なC言語で書かれています。ここで私はいくつかの質問があります：
- C/C++という用語の使用をやめるべきですか？
- ＃1の答えが「はい」の場合、CとC++の混合を使用するプログラムをどのように呼び出しますか？
- それらの両方が「異なる」言語であることを考えると、ある時点でC++コンパイラがC言語で記述されたコードのサポートを停止する可能性があります（最新のc ++は、ポインター、動的メモリ処理などの基本的なものについてCの考え方から分岐しているため）
- 現在、互換性を維持するためにC/C++の標準を作成する人々の間で何らかのコラボレーションがありますか
- ＃4がyesの場合、そのようなコラボレーションはmodern c ++の出現で近い将来に終了する可能性があります（11/14/17）
すでに似たような質問があることは承知していますが、多くの人がこれらの質問を共有していると思いますので、特に近い将来のC++の傾向と関係がある点については、良い回答を得ることに非常に興味があります。
CはC++のサブセットにはなりませんでした。この最もわかりやすい例は_int new;_です。これはC89とC++ 98以降に当てはまり、新しい標準が登場するにつれ、言語は互いにさらに成長してきました。
C/C++という用語の使用をやめるべきか
はい
＃1の答えが「はい」の場合、CとC++の混合を使用するプログラムをどのように呼び出しますか？
ソースファイルは、いずれかの言語で記述されています。プログラムは、一緒に動作する複数の言語からのコード、または異なるコンパイル済みオブジェクトをリンクすることによって生成された実行可能ファイルで構成できます。あなたはプログラムがCとC++で書かれたと言うでしょう、「C/C++」は言語ではありません。
それらの両方が「異なる」言語であることを考えると、ある時点でC++コンパイラがC言語で記述されたコードのサポートを停止する可能性があります
3）彼らは決してしなかった。 char *a = malloc(10);。 [〜＃〜] c [〜＃〜] と C++ は、少なくともISO標準がある限り、完全に互換性がありません（わかりません）。事前に標準化された日に関するすべての詳細）。リンクをクリックするか、以下を参照して、C89以降では問題ないが、C++標準では無効なファイルを参照してください。
4）afaikいいえ、ワーキンググループはお互いを認識していますが、基準は自分たちにとって最善の決定を行います。
_/* 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) { }
_CはObjective-Cのサブセットであることは言及する価値があるといつも感じています。
hasが、これらの用語が頻繁に組み合わされる理由です。 Cの先生に彼の言語がC++のサブセットであることを伝えるべきではありませんが、ここにはいくつかの真実があります。他の人はすでにあなたの教師の視点を公開しています。これはとてもいいです（そして例などで説明されています）。しかし、象牙の塔や本には住んでいません。
あなたの上司はあなたが使用した正確な言語についてそれほど気にすることはできませんでした。彼がプログラミングについて少し知っている場合は、C/C++を使用していることを伝えれば、「DLLとすべての複雑な機能を備えた、マシンコードにコンパイルする必要がある言語を使用した」と聞こえるでしょう。これは「外部コミュニケーション」の部分です。
CとC++の両方でインターフェースできるライブラリーを作成する場合は、C/C++ライブラリーと呼ぶことをお勧めします。もちろん、誰かが手を挙げて、なぜこれをたまたまC++ラッパーを持つCライブラリと呼ばないのかと尋ねるでしょう。そして、とにかくC++はCライブラリにリンクできるため、まったく言及する必要はありません。 「はい、そうです、これはC/C++ライブラリです」と答えてください。これが「内部コミュニケーション」の部分です。
C++用の字句アナライザーを作成すると、Cでうまく機能することに驚かれるでしょう。すべてを変更する必要はないかもしれません。これは「アヒルのように見える場合」などです。部。
等。
私がこれまでに見たCプログラムの大部分は、C++コードとして変更せずにコンパイル（および動作）します。いくつかの例外や独断的な（ただし影響力のある）プログラマーが直感をだましてはいけません。 CとC++はsoに近いため、互換性があり、しばしば混合して一致するため、C/C++という用語が使用されます。 これは、JavaまたはPHPでない限り、CまたはC++のどちらを検討しているかに関係なく、このような状況を説明するのに役立つために使用されます=。「間違っている」ことはわかっていますが、気にしないでください。間違っているよりも便利です。
乱用されたり、ばかげたりするかもしれませんが、それでも、必要以上に知識を深めることでどのようなメリットが得られるのか、他の人が理解している言葉でコミュニケーションを拒否することはできません。特定の状況で不安を感じる場合は、一般的な用語C/C++ではなく、ケースに関連するもの（CまたはC++）を使用しないでください。
未来を恐れてはいけません。私たちのオペレーティングシステムはCで書かれています。C/ C++の現在のソフトウェア生産のかなり多くがC++で行われています。このカップルはかなり長い間ここにいます。一方が他方とより非互換になることに関心を持つ人は誰もいません（実際にはかなり逆です）。
あなたのポイントについて具体的に言うと：
1）場合によります。はい、混乱を招く可能性がある場合、不安を感じる場合、または単に間違っているか、文脈外の場合。それが適切だと思うときは、いいえ。
2）該当なし
3）いいえと思いますが、水晶玉はありません。
4）わからない
5）私はそうは思わない
流れに逆らうと、私はコンテキストに依存しますと言います。
「これはC/C++プログラムです」のようなことを言うとき、「C/C++」という用語は通常適切ではありませんが、これは他の答えに深く掘り下げられています。
ただし、C/C++が適切なコンテキストがある場合があります。
- 通常、CおよびC++ APIの両方を備えたさまざまなライブラリがあります。このようなことをC/C++ライブラリと呼んでも、それほど真実ではないでしょう。私たち人間は情報を圧縮するのが好きなので、「opencvはC/C++ライブラリです」と短くて明確で理解できるので、「opencvはライブラリで、CとC++の両方のヘッダーが同梱されている」と比較してください。
- 言語の設計と構文について話すことができます。言語構文の観点から見ると、言語にはC/C++に似た構文があると言えます。
- コーディングコンテストを開催し、CとC++で書かれた両方のソリューションを受け入れる
- あなたは新しいプログラマーを雇っていて、ほとんどのタスクはCまたはC++のどちらかなので、プログラマーは両方の言語を知っていることが求められます。これは組み込み開発では一般的で、Cは一部の（通常は非常に小さい）マイクロコントローラーに、C++は他のコントローラーに適しています。この場合、C/C++プログラマーを探していると言えます。
一般にSOユーザーは、質問をしている人にCまたはC++の言語を選択するように求めます。なぜですか？
CとC++の間には多くの微妙な違いがあります。たとえば、C++では、グローバルスコープのconst変数は、externと宣言されない限り内部リンケージを持ちますが、Cではstaticと宣言されない限り外部リンケージを持ちます。 OPは「C/C++」と言って、質問に対する答えがCとC++の両方で同じであるという知識を主張しています。 これは不必要に回答者にとって事態を困難にします。
場合によっては、コードがいずれかの言語で無効であることを見つけることができます（たとえば、
void*からオブジェクトへのポインターへの暗黙的な変換はC++では無効です）。これは迷惑です。 Cで有効だがC++では無効なコードがあるのに、なぜ「C/C++」と言うのですか？ Cを意図したのですか、それともC++を意図したコードの単なるエラーですか？言語によって答えが異なる場合があります（たとえば、可変長配列はC99には存在しますが、C++には存在しません）。あなたが話している言語がわからない場合は、推測するか、どちらか1つだけが実際に役立つときに両方の答えを書く必要があります。なぜなら、あなたはどの言語を知っているからです。実際に使用する;あなたは私たちに言っていないだけです！
時々答えは両方の言語で本当に同じですが、それを確認するのは難しいです。たとえば、CとC++は同じ整数変換規則を持っていると思いますが、本当に確実にするには、両方の標準を注意深く読む必要があります。繰り返しますが、これにより、おそらく1つの言語のみに関心がある場合に、必要な作業が2倍になります。
とにかく、他の質問に答えるには：
はい。
CとC++のコードをリンクする場合は、両方のタグを使用できますが、各ファイルの言語を指定してください。
重大な変更が時々ありますが、それらはまれであり、通常は影響が限定されます（そうでない場合、承認されません）。たとえば、C++ 11では
autoです。彼らは直接協力しているとは思いませんが、他の言語での開発に注意を払い、互換性をより困難にするような変更を導入しないようにしています。
そして、もしあなたが本当に両方の言語について知りたいなら、それは問題ありません、そしてあなたはあなたの質問でそれを言うことができます。 "C/C++"と言ったとき、どういう意味かよくわからないので、2つの言語について仮定しているように見えます。
CはC++のサブセットであるか、C++はクラスを持つCであるといつも言われていました。そして、それはC++ x0、C++ 11（または最近のC++ 11/14/17の一般）が登場するまでは静かでした。
CはC++のサブセットではありません。たとえば、C89はC++ 98のサブセットではありません。
いくつかの例：
- 関数パラメーター宣言のC89identifier-list formはC++ではサポートされていません
- C89とC++ 98では、文字定数の型が異なります
- C89とC++ 98には文字列リテラルの異なる型があります
- 論理演算子はC89とC++ 98で異なる型を生成します（
intvsbool）
- C/C++という用語の使用をやめるべきですか？
はい。
- ＃1の答えが「はい」の場合、CとC++の混合を使用するプログラムをどのように呼び出しますか？
プログラムはCまたはC++です（非常に基本的なプログラムでさえ、CまたはC++コンパイラーでコンパイルできる場合）。コンパイルにはどのコンパイラを使用していますか？それはあなたの質問に答えるべきです。 Harbison＆Steeleは Clean C という用語を作り、CとC++の共通のサブセットを指定しましたが、それは悪い考えだったと思います。
[〜＃〜] edit [〜＃〜]：ただし、技術的には、CおよびC++オブジェクトファイルを単一のプログラムでリンクできますが、OTHはそこにありますJavaとC++のように、単一のプログラムで混合できる多くの言語です。C/ C++プログラムという用語を使用すると、単一の言語で書かれているという混乱が増えるだけだと思います。 C/C++と呼ばれます。
- それらの両方が「異なる」言語であることを考えると、ある時点でC++コンパイラがC言語で記述されたコードのサポートを停止する可能性があります（最新のc ++は、ポインター、動的メモリ処理などの基本的なものについてCの考え方から分岐しているため）
多くの機能があります（例：可変長配列、フレキシブル配列メンバー、_Generic、...）C99またはC11のC++バージョンでサポートされていないもの。
一部のプログラムはCとC++の混合で記述されています
これは人生の事実です。 CおよびC++からオブジェクトファイルをコンパイルして、それらをリンクできます。結果はかなり合理的に「C/C++プログラム」と呼ぶことができます。
しかし、それは全体としてのプログラムだけです。個々のコンパイルユニットはどうですか？
C++のサブセットでもあるCのサブセットがあります
そのサブセットで記述されたプログラム（またはコンパイル単位）は、準拠するCおよびC++コンパイラーでコンパイルおよび動作します。このようなプログラムまたはファイルは、「C/C++プログラム」または「C/C++ファイル」と呼ぶことができます。
ヘッダーファイルなどの部分プログラムも、CプログラムとC++プログラムの両方で使用できます。このようなヘッダーファイルは、C/C++ヘッダーと正しく呼ばれます。
Bjarne Stroustrup教授の引用：
CはC++のサブセットですか？
厳密な数学的意味では、CはC++のサブセットではありません。有効なCであるが無効なC++であるプログラムや、CとC++で異なる意味を持つコードを記述するいくつかの方法さえあります。ただし、C++はCがサポートするすべてのプログラミング手法をサポートします。すべてのCプログラムは、C++で基本的に同じ方法で、同じランタイムおよびスペース効率で記述できます。 ANSI Cの数万行を数時間でCスタイルのC++に変換できることは珍しくありません。したがって、C++はANSI Cのスーパーセットであり、ANSI CはK＆R Cのスーパーセットであり、ISO C++は1985年に存在していたC++のスーパーセットである。
よく書かれたCも、正当なC++である傾向があります。 たとえば、Kernighan＆Ritchieのすべての例：「Cプログラミング言語（第2版）」もC++プログラムです。
yesC/C++のようなものがあります。有効なCと有効なC++の両方です。
CプリプロセッサはC言語の一部です。 C++プリプロセッサはC++言語の一部です
CまたはC++でコンパイルしてdifferentになるコンパイルユニットを作成できます。たとえば、Cでコンパイルされた基本機能を備えていても、C++でコンパイルされている場合はC++ライブラリを利用できます。
プログラムが本質的に同じであるが、追加機能がある場合、それは正確にwrongではなく、同じプログラムであると言います。その同じですが、また異なります。
ほとんどのCプログラマは、少なくとも少しはC++を実行でき、その逆も同様です
そのような人をC/C++プログラマーと呼ぶのは不合理ではありません。はい、おそらく1つに特化していますが、文字通り他の言語のanyを実行できない有能なCまたはC++プログラマーはいますか？ある意味、彼らはall C/C++プログラマーではないでしょうか？
「C/C++」と言っても問題ありません。重要なことは理解されています
英語は三段論法を表現するためのツールではありません。あなたはcanロジックに英語を使用しますが、それだけで、多大な努力が必要です。
これは、単語には本来正確な意味があるのではなく、曖昧な意味の雲が含まれているためです。重要なのは、あなたが言っていることを人々が理解しているかどうかです。
- C/C++という用語の使用をやめるべきですか？
もちろんです。おそらく、CとC++がこの用語を使用する人のために何をしているのかについての混乱を除いて、この構文が何を表現しようとしているのかは明らかではありません。
この混乱はフラストレーションの非常に一般的な原因であるため、多くの人々はそれについて非常に感情的になり、その用語の出現だけが彼らがあなたの貢献について否定的になるのに十分な理由になります。これはばかげているように見えるかもしれませんが、私たちが持っているもののようです。
「C/C++」ではなく、実際に意味を明確にする用語を使用することをお勧めします。
C++にも当てはまる、または当てはまらないCの何かについて話している場合は、単に[〜＃〜] c [〜＃〜]と言います。
例：
main関数をCで宣言するにはどうすればよいですか？最初は、C++の答えは同じであるように見えるかもしれません：
int main()またはint main(int, char**)。しかし、議論が進むにつれて、C++では関数がグローバルスコープで宣言されなければならないことを指摘することは適切かもしれません。これはnamespacesがないため、Cでは意味がありません。一方、Cではmainを再帰的に呼び出すことができますが、C++ではできません。 C++では、mainが「落ちる」場合、暗黙の_return 0;_がありますが、Cでは、すべてのパスでreturnステートメントが必要です。リストは続きます、そしてあなたがそれが議論されるべき言語が何であるかを前もって明らかにするならば、それは議論をはるかに簡単にします。Cに当てはまるかどうかにかかわらず、C++で何かについて話している場合は、単にC++と言います。
例：
intsのmalloc()ed配列は、C++では最初はすべてゼロですか？Cの短い答えはたまたま同じです：いいえ。しかし、回答が進むにつれ、Cでは
callocが良い代替案になることを指摘する価値があるかもしれませんが、C++では、_std::vector<int>_を使用するのが最初のほうが適切な選択かもしれません。CとC++の類似点を指摘したい場合は、「CとC++」と言います。
例：CおよびC++では、
sizeofとintは実装定義であり、コンパイラとアーキテクチャによって異なる場合があります。ここで、CとC++の動作が同じであることを指摘しておきます。 両方の言語について明示的に話している。
「C」や「C++」だけでなく、正確なバージョンについても話してください。どちらの言語も進化しており、次のような率直な声明があります。
C++は_
/* … */_および_// …_コメントをサポートしますが、Cは_/* … */_スタイルのみをサポートします。
正しいことでも間違っていることでもありません。
- ＃1の答えが「はい」の場合、CとC++の混合を使用するプログラムをどのように呼び出しますか？
言語が重複しているため、すべてのCプログラムにはC++のように見えるpartsが含まれ、その逆も同様です。それにもかかわらず、作者はおそらくCまたはC++コンパイラーのどちらかを使用することに落ち着いているでしょう。したがって、Cコンパイラでコンパイルされている場合は、「プログラムは[〜＃〜] c [〜＃〜]で書かれていて、「プログラムはC++で書かれている” C++コンパイラを使用する場合、たとえ最新のC++機能の使用を拒否する場合でも。そのようなC++コードをC-style C++と呼ぶ人もいます。オーバーロード、例外、ポリモーフィズム、テンプレート、I/Oストリームが存在しないことは、そのようなコードの一般的な特性です。
代わりに、一部のファイルがCで記述され、Cコンパイラでコンパイルされ、一部のotherファイルがC++で記述され、C++コンパイラでコンパイルされた場合、および次に、オブジェクトファイルをリンクします。実際には、既に行ったように、「プログラムはCとC++の混合で記述されています」と言います。
ただし、代わりに、CまたはC++でコンパイルできるように、すべてのファイルを作成するように細心の注意を払った場合コンパイラと結果のプログラムは同じことを行います。「プログラムはCとC++の一般的なサブセットで書かれている」と言えます。
後者は、CおよびC++コード間で共有する必要があるヘッダーファイルの場合によく見られます。ところで、そのようなコードを書くのは簡単ではありません。 CおよびC++とで有効な構成だけが使用されていることをさらに強調したい場合は、さまざまなコンパイラベンダーが広くサポートしています。 aportableCおよびC++の共通サブセットを使用してこれを強調できます。
- それらの両方が「異なる」言語であることを考えると、ある時点でC++コンパイラーがC言語で記述されたコードのサポートを停止する可能性があります（ポインター、動的メモリー処理などの基本的なものについて、最新のC++はCの考え方から分岐しているため）。
この質問を理解したかどうかわかりません。 CとC++は異なる言語であるため、一方のコンパイラが他方用に作成されたプログラムを受け入れることは期待できません。ただし、コンパイラーはモジュール方式で設計されることが多く、コンパイラーにC++front-endが含まれている場合、Cフロントも含まれる可能性が高くなります。終わり。 （コマンドラインスイッチまたは同様の方法で、どちらを使用するかを選択します。）両方の言語が広く使用されている限り、これが変更される可能性はほとんどありません。 「モダンC++」についてのあなたのポイントは、基本的には優れたコーディング標準と標準ライブラリの問題だと思います。 コンパイラのの観点から見ると、両方の言語の進化は発散するというよりむしろ収束しています。
- 現在、互換性を維持するためにC/C++の標準を作成する人々の間で何らかのコラボレーションがありますか？
はい。 C++ 11とC11で導入されたメモリモデルとアトミック操作ライブラリがその良い例です。両方の言語の設計者は互換性が重要であることを認識し、それを改善するために取り組んでいるようです。個人的には、コラボレーションがより強力になり、2つのISOワーキンググループが参加することさえありますが、私の希望は重要ではありません。
Bjarne Stroustrupは、C++プログラミング言語の第4版の44.3で、CとC++のさまざまなバージョンの違いと共通点について語っています。タイトルは「C/C++互換性」です。意味が明確なため、この場合は実際にこの用語を使用するのが適切な場合があります。
- ＃4が「はい」の場合、このようなコラボレーションは近い将来、最新のC++（11/14/17）の登場で終了する可能性があります
上で述べたように、それはC++ 11で発生し、再び発生することが期待されています/期待されています/必要でした。
C/C++は、CとC++の共通部分です。
_int new;_はC/C++ではなく、どちらも_vector<int> foo;_ではありません。
同様に、C89/C99はこれらの2つの言語の共通部分であり、_enum bool { false, true };_もfor(int i = 0;;)も許可されていません。
そしてC++ 11/C++ 14など.
C++ 11とC++ 14でコンパイル（そして正しく実行）するコードを書くことは可能ですが、一方の下でコンパイルすると、もう一方の下でコンパイルされることを意味しません。実際、多くの人がこれを行っています。
そして、多くの人がCおよびC++で動作するコードを記述します。
明らかに、オーバーラップが大きければ大きいほど、それが意味を成します。 C/C++/Javaコードに関する質問は期待していません。
これらの言語の一般的なサブセットについて話すことは「理にかなっています」が、多くの質問ではこのサブセットに回答がありません。 CおよびC++でmain（）は何を返す必要がありますか？
しかし、複数の言語仕様で機能するコードについては、それらの仕様が「バージョン」または「言語名」などによって区別されているかどうかに関係なく話し合うことができます。
これは、他のいくつかの回答やコメントで見られる「これは金属に近いところで働いていて、管理コンテキストでは問題ないプログラマーのためのコードです」という立場に対する一種の応答です。
その解釈でさえも注意深く取り扱われるべきだと私は主張します。
少なくとも90年代半ばから、C++プログラマーや、Cプログラマーであると自称した人が適用したい場合は、オブジェクト指向設計についてどれだけ知っているか、オブジェクトでのデバッグの経験がどれだけあるかを尋ねる必要がありました。指向のコンテキスト、およびテンプレートライブラリを使用する能力について。面接と採用プロセス中にこれらの問題を正確に調査する必要があります。
反対に、C++の達人が「最新のC++」を推進し始めてから10年以上が経過しました。つまり、ベアポインターからより安全なポインターオブジェクトとイテレーターベースのイディオムに移行することに重点が置かれています。 C++ 11の登場により、マルチパラダイムプログラミングが明示的にサポートされるようになり、ポインターを示さないコードへのプッシュは非常に強力になりました。つまり、今日C++のプログラマーにCのポジションについてインタビューした場合、この人物が実際のフットショット対応のポインターにどれだけ精通しているかを確認することに非常に関心があることになります。
私は最近は仕事をしていません（Stack Overflowが幼少期にあったときでさえ私はそうです）ので、架空の面接担当者がクロスオーバースキルを持たない頻度を推測するつもりはありませんが、最も頻繁に適用されるように、言語は実際に非常に異なっていると思います。
つまり、「C/C++」は、技術的なコンテキストだけでなく、ほとんどのビジネスコンテキストでも削除する必要があります。
概念的には、CソースファイルをC++でそのままコンパイルできるように、Cソースファイルの設計に特別な問題はありません。これを行うことには確かにいくつかの重要な利点があります。たとえば、組み込みシステムのコードを作成する場合、ホストされたPC環境でコードをテストできると便利な場合があります。コードがC++として正常にコンパイルされる場合、 "MOTOR_ENABLE = 1;"のようなステートメントが存在する可能性があります。組み込みシステム（Cとしてコンパイル）の揮発性I/Oビットに書き込みますが、PC（C++としてコンパイル）でエミュレーションロジックをトリガーします。おそらく、小さな組み込みシステムでuint16_tが動作するように動作するC++タイプをPCで設計することも可能です（たとえば、u16 x=65533;が指定された場合、コンパイラーはx*xの値を9と見なす必要があります。ただし、私のエミュレーターのいずれもまだそれを組み込んでいません（一部は、私が使用したC++コンパイラーがそのような場合に奇妙なことをしていないためです）。
残念ながら、CプログラマーとC++プログラマーは、言語が長年にわたって互換性のある方法で進化してきたため、お互いに対して十分な反感を持っています。 C89がC++のより便利な機能（関数プロトタイプなど）をいくつか適応させようとした一方で、C++の機能のいずれかを必要とするプログラマはC++を使用するという態度が現れたようです。 C++の一部の機能（たとえば、関数をオーバーロードする機能静的または静的インラインリンケージを使用必要のない他の機能に関連するコストを受け入れる必要なく、たとえば、オーバーロードされた関数のエクスポートに関連する名前のマングリング）。
C89とC++ 98の共通部分は実行可能な言語ですが、新しいバージョンのCと新しいバージョンのC++の使用可能なスーパーセットは、成長するのではなく縮小する可能性があり（Strict Aliasing Ruleなどのおかげで）、トレンドは常に亀裂の増加。
この質問への最も簡単な答えは、あなたはneverがその用語を使用したはずであるということです。あってはならない言葉です。意味がありません。すべてのプログラムはCまたはC++です。
そして、それはC++ x0、C++ 11（または最近のC++ 11/14/17全般）が登場するまでは静かでした。
C++ 98と03は、リモートでCクラスを使用することすらできません。これを教えた人は誰でも、たわごとを知らず、あなたはそれらを忘れることができます。これは決して正しくありませんでした。