C ++を介したC、およびCを介したC ++を使用する場合

私はもう1年以上コンピューターサイエンスを紹介されていますが、私の経験から、CやC ++はどちらも「超高速」言語と見なされているようですが、Pythonやその他のスクリプト言語などは通常やや遅いと思われます。

しかし、ソフトウェアプロジェクトまたは小さなプロジェクトでさえ、それらのファイルの特定の数nがCで書き込まれ、それらのファイルの特定の数mがC ++で書き込まれるファイルをインターリーブする多くのケースを見てきました。

（C ++ファイルにはほとんどの場合対応するヘッダーがありますが、Cファイルにはそれほど多くないことに気付きました）。しかし、私の主な質問のポイントは、C ++を介してCを使用するのが適切な場合、およびCを介してC ++を使用する方が適切な場合の一般的な直感を得ることにあります。（1）C ++がオブジェクト指向であるという事実以外Cはそうではなく、（2）構文は非常に似ており、C ++は多くの点でCに似ているように意図的に作成されましたが、その違いはわかりません。それらは多くのドメインで（ほぼ）完全に互換性があるように思えます。

だから誰かが状況を解決できたら幸いです！ありがとう

あなたがCを選ぶとき

• なんらかの理由でポータブルアセンブラが必要です（これがCです）。
• プラットフォームがC ++を提供していない（Cコンパイラを実装する方がはるかに簡単です）
• Cとのみ対話できる他の言語と対話する必要があります（通常、どのプラットフォームでも最小の共通分母です）。コードはインターフェイスのみで構成され、C ++コード上にCインターフェイスを配置する価値はありません。
• オープンソースプロジェクトをハッキングする（さまざまな理由でCにこだわる）
• C ++を知らない。

その他の場合はすべて、C ++を選択する必要があります。

Cを好む理由はいくつかあります。主な理由は、C ++で本当に小さな実行可能ファイルを作成するのがより困難になる傾向があることです。本当に小さなシステムの場合、とにかく大量のコードを書くことはめったになく、CではなくC ++に必要な余分なROMスペースが重要になる可能性があります。

ただし、非常に小さなシステムでは、Cにはまったく同じ理由で問題があり、アセンブリ言語がほぼ唯一の妥当な選択であることも付け加える必要があります。Cが実際に意味をなすシステムサイズの範囲は非常に小さく、絶えず縮小しています（ただし、かなりゆっくりと認めます）。

Cを使用するもう1つの時間/理由は、基本的に他の任意の言語からバインドできる一連の関数を提供することです。あなたはできるようにそれらを定義することにより、C ++でこれらの関数を書くextern "C"の機能、しかし、そうすることは、世界に基本的にC-生活「顔」を提示し、それらの機能を制限-などのクラス、オーバーロードされた関数、テンプレート、およびメンバ関数、必要はありません適用します。ただし、これは必ずしも開発をCに限定するものではありません。外部インターフェースがCのように見える限り、あらゆる種類のC ++機能を内部で使用することは完全に合理的です。

同時に、@ Tollの回答（明らかな例の1つ）には、ほとんどの点でほぼ後方にあるものがあると言わざるを得ません。合理的に記述されたC ++は、一般的に少なくともCと同じくらい高速で、多くの場合少なくとも少し高速です。もっとも簡単なアルゴリズムやデータ構造、すべてのエラー処理などのために、すべてのコードの雪崩に埋もれないためだけに、読みやすさは一般的にはるかに優れています。

テンプレートは「言語の型システムの問題を修正する」のではなく、テンプレートなしのCやC ++にはほとんどない基本的な機能を追加するだけです。元々の意図の1つは、タイプセーフなコンテナを提供することでしたが、実際にはそれをはるかに超えています。

自動化されたツールは、ほとんどが赤いニシンでもあります.Cパーサーを記述する方がC ++パーサーを記述するよりも作業が少ないことは事実ですが、実際には最終的に違いはありません。どちらのパーサーでも使用できるパーサーを作成したい、または作成できる人はほとんどいません。そのため、合理的な出発点はどちらの方法でもClangです。

偶然にも、CとC ++は同じプロジェクトでかなり頻繁に一緒に使用され、同じ人によって管理されています。これにより、非常にまれなことが可能になります。2つの言語で記述されたコードの保守性を、全体的に同等の能力を持つ人々（つまり、まったく同じ人々）で直接客観的に比較する研究。少なくともリンクされた研究では、1つの結論が明確で明確でした。「Cの代わりにC ++を使用すると、ソフトウェアの品質が向上し、保守作業が軽減されることがわかりました...」

CとC ++の違いは、すでにここで詳細に列挙されています。時には人々はどちらかを選択する正当な理由があるかもしれませんが（たとえば、C ++の追加機能が望ましくないオーバーヘッドを導入するように感じたときのOOPまたはCのC ++）、私の経験では通常は好みになります。このファイルに取り組んでいる人々は、何をより良く知っており、より好きですか？これらの言語の両方がパフォーマンスが重要なアプリケーションに取り組むことは事実であるため、私はこれがほとんどの場合の理由であると信じています。

（補足：Linus Torvadsの、C ++をC ++よりも好む理由についての暴言をご覧ください。必ずしも彼の主張に同意するわけではありませんが、C ++よりもCを選択する理由についての洞察を提供します。むしろ、彼に同意する人々これらの理由でCを選択する場合があります。）

（この投稿の時点で）既存の回答から欠落している主な問題は選択です。

それは簡単です。何らかの不合理な理由で、例外にオーバーヘッドの価値がないと感じた場合、それらを使用する必要はありません。テンプレート、RAII、および標準ライブラリを引き続き使用でき、単一の「スロー」を記述することはできません。テンプレートについても同じことが言えます。なんらかの理由で、取り消せない（そして実際には重要な、埋め込みにのみ存在する）実行可能な膨張を引き起こすと感じた場合、驚き-一日中void *とsizeof（T）を使用することもできます。C上のC ++機能を強制的に使用することはありません。

そのため、C ++は本質的に優れた言語です。必要な機能を選択して、特定の機能が気に入らない場合はCスタイルのプログラミングにフォールバックできます。したがって、C ++がCのすべてであり、C ++が優れた言語であることは明らかです。別の方法で提案することは、4が5より大きいことを提案しようとするようなものです。

Cプログラマーを緊張させるC ++に関すること

内部では多くの魔法が発生しています。コンストラクタ、デストラクタ、仮想メソッド、テンプレートなどにより、C ++コードは同等のCコードよりもはるかに簡単かつ高速に記述できますが、理解と推論が難しくなります（C ++とその関連する規則をどれだけ知っているかによって異なります）。クラス（およびそれが依存するクラス）のコンストラクターがどのように定義されているかに応じてFoo newFoo;、多くのコードを呼び出すような単純なものFoo。postfix にはコストのかかるコピー操作が含まれることが多いため、これはまた、コンテナを反復処理するときでは++itなく、書くという規則である理由でもあります。 it++++

何をしているのかにもよりますが、特に単純なタスクの場合、わずかなオーバーヘッドが発生する可能性があります。次の2つのプログラムを使用します。1つ目はC、2つ目はC ++です。

/* C version */
#include <stdio.h>
int main(void)
{
  char greeting[] = "Hello, world";
  printf("%s\n", greeting);
  return 0;
}
/* end C version */

/* C++ version */
#include <iostream>
#include <string>
int main(void)
{
  std::string greeting("Hello, world");
  std::cout << greeting << std::endl;
  return 0;
}
/* end C++ version */

同一の動作で、ソースの点で大きな違いはありませんが、gcc 4.1.2で作業しているSLES 10ボックスでは、前者は〜9kbのサイズの実行可能ファイルを生成しますが、2番目は12.5kbを引き継ぎます（最適化なし） ）、ほぼ28％大きくなります。C ++ string型はC文字列ライブラリよりもIMOでの作業がはるかに簡単であり、C ++ストリームはCストリームよりもはるかに柔軟でカスタマイズ可能ですが、このような本当に頭の痛いコードの場合、オーバーヘッドの価値はないかもしれません。

C ++は、Cと比較して非常に複雑なセマンティクスを持つ巨大な言語です。C ++に習熟するには、Cよりもはるかに長い時間がかかります。つまり、C ++を知っていると主張する多くの人々は、C ++を自分が思っているほど知らないのです。

C ++プログラマーを緊張させるCのこと

Cは想像力の広がりによって安全なプログラミング言語ではありません。アレイ上のチェックはとどまるところを（今死んを通してそれをも攻撃可能な行動の多くにつながるしないgets、またはスルー機能scanf付き%sと%[変換指定子）。C ++は少なくとも、現在定義されている範囲外にアクセスしようとすると、例外をスローするコンテナーを提供します。Cが提供するものはすべて（幸運なら）セグメンテーション違反です。

Cでのメモリ管理は、C ++が提供するツールと比較して、非常に労働集約的でエラーが発生しやすいです。独自のコンテナを構築している場合、すべてのmallocおよびfree呼び出しを照合し、割り当てが成功したことを確認し、エラーが発生した場合に部分的な割り当てを取り消すなどの責任があります。C++では、コンテナからアイテムを削除します。問題がある場合、例外がスローされます。

同様に、Cでのエラー処理は、C ++が提供するツール（つまり、例外）に比べて苦痛です。本当に楽しいのは、大量のメモリを割り当ててから、処理中に壁にぶつかったときです。バックアウトする必要があるため、適切な順序でメモリを解放する必要があります。C ++およびRAIIの原則を使用すると、これは（比較的）簡単に実行できます。

それで、いつ私は一方をもう一方の上に使うのですか？

何を書いていることは湿原シンプルであれば、その動作が入力と出力の観点できれいに説明することができ、それアプリケーション、取り除く/それでそれ/堆肥を読むと、パフォーマンスの問題、そしてC ++上でCを好みます。それ以外の場合は、C ++を優先します

Bjarne Stroustrupは、C ++を使用するアプリケーションと企業のリストを管理しています。手続き型プログラミングとOOPプログラミングのすべてについては議論の余地がありますが、過去20年間の業界の結果について議論することはできません。

C ++は、モジュール化されたコンポーネントの作業を別の人が必要とする、大規模でマルチマンの複雑なプロジェクトによく使用されます。もちろん、Cでモジュール化されたコードを構築および保守できますが、C ++固有のOOPの性質により、優れたモジュール化、テスト容易性、およびコードの再利用が可能になります。

C ++標準ライブラリ（STL）は、ベクターとマップのみを備えているため、C ++を使用するのに十分な理由です。

Cは一般に組み込みシステムに使用されます。

C APIのみを備えたライブラリがある場合にのみ、個人的にCを使用します。

私がC ++よりもCを選択する主な理由は、NASAのようなものに「これは1000％安定しなければならない」に頼らざるを得ないときだけだと思います。

パフォーマンスを見ると、C ++は〜99％Cであり、はるかに生産的です。そのため、CでC ++よりも高速なコードを書くことができます（例外、仮想、ストリーミング、抽象化などもせずにC ++のサブセットを使用できますが、基本的にはCです）。 STLはテスト済みで既に実行されていますが、STLアルゴリズムは専門家グループによって作成されており、おそらくすべての専門家ではないため、達成できる小さなパフォーマンスゲイン以上のコストがかかります。

一方、C ++には多数の抽象化があります。状況下でそれらが漏れると、これはあなたをトラブルに巻き込みます。C ++の落とし穴を100％知っている人はほとんどいませんが、すべてのCの落とし穴を知っている人はもっと多いと思います。そのため、Cのすべてのメンバーがすべてのステップを完全に理解できるソリューションを作成するのははるかに簡単です。

例：いつshared_ptr<smthn>参照カウントがオーバーフローするか、例外をスローするかを知っていますか？シャトルが大気圏に再び入らなければならないとき、これらのようなものはクールではありません。少なくともそうは思います。

また、例外処理はエラーコードと比較して非常に困難です。クラスが100％例外安全であり、リークしやすいかどうかを確認するのは困難です。多くの高代表者がこの意見を表明しています。

Cは構文が改善されたポータブルアセンブリであり、プログラマがすべてを完全に制御できます。

一方、C ++は、多くのファンキーマジック（仮想関数、オーバーロード、自動変換など）を実行します。

• 必要以上にメモリを使用しないでください
• メモリーページに無制限にアクセスしない（vtableはどこでもかまいません）
• 誤って多くのコードを呼び出さないでください

パフォーマンスに集中しているので、本当にシンプルなものが必要です。

驚きはありませんが、それは非常に貴重です。

必要に応じて（推奨）、軍事用アビオニクス制御用のC ++を作成する際に考慮する必要のあるJSFコーディングガイドラインをお読みください。そこにあなたが注意する必要がある多くのtrapであり、それはあなたを捕まえるかもしれません。Bjarneはそのドキュメントの一部であったため、それが何であるかを知っています。

また、Cは稲妻に打たれたやけどしたトロールのようにコンパイルされます。C ++、OTOHは、おそらくSSD企業に投資した同じ人々によって後援されました。:)

（個人的には、私はC ++を好むだろうが、私はそれが好きではない......どちらか。;-P）

（両方の言語に同等の知識がある場合）

プラットフォームにC ++コンパイラがない場合を除き、C ++を使用します。好きではない言語の部分（クラス、例外、仮想継承、適用したい個人的な制限なし）なしでC ++コードを記述できます。結局のところ、これらの機能は簡単に使用できます。C ++には、Cスタイルのコードを書くことを妨げるものは何もありません。

（同等のツールセットと開発者の知識がある場合）プラットフォームにC ++コンパイラがある場合、C ++よりもCを選択する理由はありません。あなたは、今日拡張したい言語のサブセットに自分自身を制限し、後で拡張のためにドアを開けたままにすることができます。

どちらの言語も優れています。多くのポスターが、それぞれの長所とさまざまな用途を詳しく説明していると思います。これを単純に追加します。

C言語は4つの領域で完璧だと思います：1）最初にあらゆる種類のプログラミングを学習するときに使用するのに最適な言語だと思うソフトウェア、および4）最低レベルのシステムソフトウェア。

C ++はオブジェクト指向言語ですが、手続き型にすることもできます（非常にCのように）。大規模なプロジェクト、GUIベースのソフトウェア、ゲームソフトウェア、およびその他のグラフィック中心のソフトウェアに取り組んでいる場合、C ++、Java、またはObjective-Cが最良の選択であることがわかります。ただし、コマンドラインプログラムやシステムソフトウェアが豊富にあり、C ++がCと同等以上であることがわかります。

私の意見では、この議論に欠けている点が1つあります。Cでは、ライブラリから安定したバイナリインターフェイスを提供する方が簡単です。他の言語とC ++の両方で使用します。

C ++では、異なるコンパイラーは異なる名前のマングリングを使用するため、ライブラリーとは異なるコンパイラーでコンパイルされたライブラリーのコンシューマーは、ライブラリーの使用に問題がある可能性があります。Cでは、通常、バイナリインターフェイスはプラットフォーム用に標準化されています。

最近のコンパイラには、gcc互換のものを生成するためのスイッチがあることがよくありますが、それが常に役立つとは限りません。

私はこれを比較的頻繁にSolarisで観察しています。ディストリビューションおよびさまざまなソフトウェアベンダーは通常、特にSparcシステムでより良い結果を提供するため、Sun Studioを使用します。しかし、オープンソースプロジェクトはgcc固有のコードで記述されています。それらを一緒に動作させるためにかなりの痛みになる可能性があります。

Cは、Cコードが生成されるとき（たとえば、高レベル言語の実装）に、おそらくC ++よりも望ましいです。例えば、そこにCのコード（例えば発するいくつかのLispのようなコンパイラですチキン、Scheme48は ...）、しかし、私は本物のC ++コードを発するどれも（私の知っているMELTのツールはC ++のコードを発しないが、私は本物のそのコードを呼び出すことはありませんC ++コード。使用するC ++機能はごくわずかです。

Cコードは、半自動で証明するのも簡単です。Frama-Cのような静的アナライザー（CコードにACSLコメントを付けてコードに関する証明者の理由を説明します）は、Cで使用できますが、完全なC ++ 11では使用できません。