Cプログラミング言語はまだ使用されていますか？
私はC＃プログラマーです。私の開発のほとんどは、いくつかのWindowsアプリケーションと共にWebサイト用です。 Cに関しては、必要がなかったので、長い間使用していませんでした。私の友人がC＃の学習を手伝っているときに、友人の1人がテストジョブのためにCを学習する必要があると言ったとき、それは驚きました。
Cで開発が行われている場合、誰かがテストのためにCを学ぶだけだと思っていました。私の知る限り、COMおよびハードウェア設計に関連するすべての開発もC++で行われます。したがって、C++を使用する必要がある場合、Cを学習しても意味がありません。私も歴史的な重要性を信じていないので、なぜCの学習に時間とお金を浪費するのでしょうか。
Cはまだ新しいソフトウェア開発などで使用されていますか？
Cには、比較的小さい言語であるという利点があり、これにより- Cコンパイラを実装するのは簡単（C++コンパイラは書くべきモンスターですが）、それを作成します簡単言語を学ぶ。 TIOBEインデックス も参照してください。CはC++よりもわずかに進んでいます。
（IMO）正当化の降順で、Cはまだ多くの場合に使用されます
埋め込まれたもの
C++コンパイラを移植するよりも、Cコンパイラを小さなプラットフォームに移植する方が簡単です。また、Cの擁護者は、C++が「背後でやりすぎている」と主張しています。ただし、IMOはFUDです。システムプログラミング
繰り返しますが、これは通常、「コンパイラが何をしているかを知る」ことがより簡単であるという主張によるものです。ただし、多くの埋め込みプログラムは、テンプレートやその他のC++の主要機能などの恩恵を受けます。オープンソースソフトウェア
しかし、それは主に態度の問題です：OSSは常にC++よりもCを好んでいます（一方、業界の大部分でそれは反対です）。 Torvaldsの不合理な憎悪が、実際にはこれの最も重要な理由かもしれませんLinux。
Cは、リソースが不足している組み込みハードウェアプログラミングでよく使用されます。
LinuxカーネルはCで書かれています。なぜなら、Linus Torvalds氏によれば、 C++は恐ろしい言語です 。
すべて私が見た現代の言語のうち、Cと相互作用するかもしれません：
- C++
- Java
- C＃
- Python
- ハスケル
- 目的C
Cと対話する必要性は、以下から派生します。
- 単純なABIを持つC
- Cは長い間使用されています
つまり、これらの言語はCと通信できるため、次のことができます。
- ライブラリを活用する
- throughCを介して相互に通信します（たとえば、ClangはC++で記述されていますが、Python Cにフックされたバインディングを提供していますインターフェース）。
そして、私はそれらのすべてがランタイムにCに依存しているに違いない（彼らが完全なアセンブリを行ったのでない限り、疑わしい）。
Cは、プログラミング言語のLingua Francaであり、特定のアーキテクチャー（Assemblyのような）に関連付けられていない最も単純な（ABI的に）の1つです。それを取り除くために大きなシフトをとります。
私の意見では、これは「友達と私はレゲエを聴いています。まだラップをまだ聴いている人はいますか？」のような、非常に短い目先の質問です。
そこにあるすべての言語がその用途を持っています。異なる言語にはニッチがあります。しかし、Cについて質問します。 CよりもC＃を日常的に使用している人は少ないと思います（誰もC＃を使用していない店で働くという偏った見方から）。
言語の相対的な人気を調べているグーグル。
これは信頼できるものではないと確信していますが、それを使用して傾向を確認できます。
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
SOタグの質問の比率：
https://stackoverflow.com/tags
- C＃：209845
- 他の16のタグ
- C：38790
したがって、CはSOに関する18の最も人気のあるトピックです（他にも多くの言語があります）。
注：上記のTIOBEインデックスは、10年以上にわたって絶えず更新されており（30年前に遡るいくつかのデータがあります）、各言語で作業するエンジニアを測定することになっています（正確さはわかりません）。 Java/Visual Basicを除く上位10言語のうち、私の店の人が知っていることを反映しています（ただし、サンプルサイズがはるかに小さいため、比率は少し異なります）。
Cは役に立たないため無視できることを納得させようとしているようです。あなたの質問を分解してみましょう：
「Cで開発が行われた場合にのみ、誰かがテストのためにCを学ぶだけだと思った」
いいえ、Cを学ぶ多くの理由があります。私がまだそのような包括的なステートメントを使用しないことをまだ知らなかったとしても、特に循環論理と組み合わせて。コードを適切にテスト/修正できるようにするには、コードが記述されている言語を知っている必要がありますが、これは、言語が指定されたとおりに使用され、Cだけでなくすべての言語に当てはまることを前提としています。
「私の知る限りでは、COMおよびハードウェア設計に関連するすべての開発もC++で行われます。」
不正解です。
「したがって、C++を使用する必要がある場合、Cの学習は意味がありません。私はまた、歴史的な重要性を信じていないので、なぜCの学習に時間とお金を浪費するのですか？」
これは、すべての中で最も疑わしいロジックです。まず第一に、歴史的な重要性はあなたが何かすべき信じるものです。なぜなら、もしあなたがCがC++のサブセットであることを知っていたからです。プログラマー。もちろん、Cはその後に続くほとんどの言語にも影響を与えたので、利点はそこで止まりません。さらに、Cは非常に重要であるため、歴史的な意味だけを持っていると見なすことはできません。それはまだ広く使われているので、そのような二次的な立場に追いやることはできません。これは、すべてのプログラマーが使用する必要のある言語ではなく、完全に理解している言語であると主張できますが、それは正しいと思いますが、真のメリットを最初に検討することなく、何かを信じないと言ってはいけません。
組み込みシステムに加えて、ほとんどの新しい言語にはCとやり取りする方法がいくつかあります。それらすべての言語で簡単に使用したいライブラリを作成する場合、Cは当然の選択です。 C++は一部の言語（Python（CPythonのみ）など）とのインターフェースも可能ですが、C++の一部の機能（特に名前の変換）のため、これより多くの言語とインターフェースをとることはできません。テンプレートは問題を解決しません。CABIは、最も簡単にインターフェイスできるものの1つです（C++を記述して、インターフェイスにextern "C"を使用できることはわかっています。気にしません）。
また、CおよびC++がシステムプログラミングに最適な言語であり、Cコンパイル時間がはるかに高速であるという利点もあります。 C++のコンパイル時間は、私が使用した言語の中で最悪です。
現在、人気のシステム言語になりたい他の言語がありますが（特に [〜＃〜] d [〜＃〜] について知っています）、ソフトウェアの大多数はC/C++。 Dのような言語では、（C++のように）直接使用するのではなく、誰かがCライブラリのラッパーを作成する必要があります。
IPad/iPhone用に開発しているほとんど毎日使用しています。多くのライブラリはCで記述されており、Objective-Cに相当するものはありません。したがって、はい、それはまだ使用されており、市場で最も新しいデバイスの1つによって使用されています。
Cを使用すると、多くの組み込みシステムをプログラムすることができます。それは小さくて便利であり、おそらく今後何年も使用できます（つまり、時間とお金を浪費せずに学習できます）。
langpop.com をチェックしてください。特に、FreshmeatとGoogle Codeのグラフをご覧ください。 Cがまだ先を行っていることを示しています。
Cは、金属（つまり、組み込みシステム）に近づく必要があるシステムや、パフォーマンスを要求するアプリケーションで依然として人気があります。
移植性。
Cコードを実行すると思われるすべてのシステムのリストを作成してから、他のすべての言語について同様のリストを作成します。
あなたが私と同じ答えを思いついたなら、結論はイエスです。
一般に、組み込みシステムでは、Cがまだ広く使用されています。
これは question で他の例を示しています。
Tiobe index は、popularity/usageによって言語を分類しようとし、一貫してCを最初の場所。
次の理由により、Cが最も強力な言語だと思います。
1）AT最初のC、これはシステム言語です（つまり、最小限の実行時間または実行時間なしで低レベルのプログラミングを行うために使用できます）。
2）結果のアプリケーションの速度。言語セットは比較的小さく、非常に効率的であるため、Cソースコードは高水準言語よりもはるかに最適化できます。アセンブリ言語でプログラミングしなくても、アセンブリ言語でプログラミングできる程度に近づきます。アセンブリとCを一緒に使用することもできます。
3）Cは、ファームウェアプログラミング（ハードウェア）でのアプリケーションです。これは、アセンブリを使用/操作し、コントローラ、プロセッサ、およびその他のデバイスと直接通信する機能によるものです。
4）Cは、現在知られている他の多くの言語の構成要素です。 Cの履歴を調べると、しばらくの間（プログラミング言語が進んでいるため）、それが存在していることがわかります。 Pythonたとえば、完全にオブジェクト指向の高水準プログラミング言語など）を見てください。これは、C（おそらくC++でも）で書かれています。他の言語の内部で、Cとそれがどのように機能するかを理解することが不可欠です。
アプリケーション言語は、高度なプログラミングに使用されます。ワープロやゲームを書く。アプリケーション言語の例は、Java、C＃です。その理由は、ガベージコレクション、自動タイピング、ランタイム検証などが含まれているためです。
システム言語は、低レベルのプログラミングに使用されます。例えばマイクロコントローラー、ドライバー、OSカーネル。例には、Cのアセンブリが含まれます。ハードウェア上でコードを直接実行するためのランタイムはほとんどまたはまったく必要ありません。プログラマーがハードウェアを直接制御することに重点が置かれています。
全体として、それはアプリケーション言語として衰退しているが、システム言語としては依然として強い。
ああ、そうです。私はネットワークパケット処理の分野で働いています。私はネットワークパケットを処理する2つの異なる会社にいました。つまり、TCPの上のレベルではなく、イーサネットまたはIPレベルで動作しています。
興味深いことに、どちらの会社でも、C++よりCが選ばれました。ある会社では、2つの製品の1つがLinuxカーネルの上に構築され、もう1つの製品はLinuxユーザー空間で構築されました。 LinuxカーネルはCでプログラムされているため、カーネル製品は明らかにCを使用しましたが、ユーザースペース製品にもCを使用することを選択しました。どちらの製品も2000年頃から開発されました（カーネル製品は2000年少し前、ユーザースペース製品は2000年少し後）。
その後私が行った会社では、製品はC++ではなくCで構築されていました。実際には1990年代半ばからのプロジェクトの継続ですが、最近のパフォーマンス向上の要求により、本質的にすべてが書き直されることが決定されました。この書き換えにより、C++を選択するオプションがありましたが、選択しませんでした。
ネットワークパケット処理の分野では、パフォーマンスが非常に重要です。そこで、既存のハッシュテーブルよりもパフォーマンスの高い独自のハッシュテーブルを実装したいと考えています。使用するハッシュ関数を選択するのは、ハッシュテーブルの作成者ではなく私です。おそらく、パフォーマンスが必要なので、 MurMurHash を選びます。おそらく私はセキュリティを求めて SipHash を選びます。メモリアロケータは明らかにカスタムです。実際、私たちが使用するすべての重要なデータ構造は、最高のパフォーマンスを実現するためにカスタム実装されています。
C++の使用を妨げるものはありませんが、通常はお勧めできません。パケットごとに1つの例外がスローされると、パケット処理速度が許容できないレベルに低下します。したがって、C++の例外は使用できません。遅すぎる。データ構造を構造体として実装し、それらの構造体で動作する関数を実装することで、一種のオブジェクト指向のCコードを既に使用しています。 C++では仮想関数を使用できますが、仮想関数呼び出しをどこで使用してもパフォーマンスが低下します。したがって、仮想関数呼び出しが必要な場合は、明示的にして関数ポインターを用意することをお勧めします。
C++は、メモリの割り当てなど、背後で多くのことを行います。一方、Cでは通常、それは起こりません。メモリを割り当てる関数を記述できますが、通常、関数のインターフェイスから、割り当てが行われていることがわかります。
Cでプログラミングするときに行うことができるマイクロ最適化の種類の例として、Linuxカーネルのcontainer_ofマクロを見てください。もちろん、C++コードでcontainer_ofを使用できますが、それは誰が行うのですか？つまり、ほとんどのCプログラムで完全に受け入れられますが、通常のC++プログラマーは、リンクノードを個別のブロックとして割り当てるリンクリストなど、すぐに何か他のものを提案します。割り当てられたすべてのメモリブロックはパフォーマンスに悪影響を与えるため、これは望ましくありません。
おそらく、C++で私たちに利益をもたらす唯一のことは、C++がテンプレートのメタプログラミングを許可することです。つまり、関数パラメーターを保持しながら仮想関数の呼び出しを回避し、コンパイラーが関数をインライン化できるようにすることができます。しかし、テンプレートのメタプログラミングは複雑であり、Cのすべての要件を満たすことができたため、C++でのこの機能の利点はそれほど重要ではありません。
ある会社では、機能の一部が実装されたカスタムコンパイル言語を実際に使用していました。コンパイラのターゲット言語はどれだったでしょうか。アセンブリ？いいえ、32ビットと64ビットの両方のアーキテクチャをサポートする必要がありました。 C++？確かにあなたは冗談を言う。明らかに、GCCの computed goto を使用したCでした。したがって、カスタム言語はC（または実際には計算されたgotoをサポートするCのgccバリアント）にコンパイルされ、CコンパイラはAssemblyを生成しました。
私は今でもCを日常的に使用しています。主な理由の1つは、他の言語との相互運用性と、さまざまな言語のすべての種類のコンパイラーによってビルドされたプラグインで使用するように設計されたSDKです。
Lua、C＃、Python、Cなどから使用できる、コンストラクターとデストラクターおよびvtables、関数のオーバーロード、例外のスローなどのクラスを使用するC++ APIは記述できません。異なるコンパイラーを使用して記述されたC++プラグインは言うまでもありませんと私たち自身の設定。
たとえば、Pythonから呼び出すことができるC＃SDK、またはPython C＃から呼び出すことができるSDKは作成できません。
Cは、これらの言語から呼び出すことができるAPIを作成できる唯一の言語です。そうは言っても、私はしばしばC++を使用してこれらのCインターフェースを実装します（ただし、Cで実装することもあります）。
その上、低レベルのデータ構造やメモリアロケータなどの場合、Cが最も使いやすい言語である場合があります。整列されたビットとバイトをプールするように設計されたメモリアロケータを作成している場合、C++で得られるすべての追加の型安全性は役に立ちません。 C++の豊富な型システムと例外処理に対して、独自のデータ構造をロールするのは簡単ではありません-例外にしたい場合は、std::vectorと同じくらい簡単なデータ構造を書くのにどれだけの労力が必要かを見てください。 -safeで、コンテナーに挿入しなかった要素に対してctorとdtorを呼び出さないようにします（私はC++標準ライブラリ全体を実装した人として話しています）。拡張可能な配列だけをうまく実装することが非常に難しい場合は、本番環境品質のBVHを実装するために必要な作業を想像してみてください。
se既存のデータ構造を使用する場合、または既存のデータ構造を使用して高レベルのデータ構造を実装する場合は、CよりもC++を優先しますが、低レベルのデータ構造をコアに実装する場合既存のデータ構造を使用しないエンジンであるCは、ここでのmemcpyのこととmemmoveのことだけを可能にするその超単純型システムを使用することで、はるかに簡単に実行できます。malloc連続したブロックとreallocがあり、コンストラクター、デストラクタ、および例外のスローについて心配する必要はありません。