今日、ソフトウェアプロジェクトにCを使用しますか？[閉まっている]

はいの場合、どこで、なぜそれを使用しますか？

いいえの場合、Cが受け入れられない理由を説明してください。

Cはシステムプログラミングに最適な言語です

いくつかのハードウェアドライバーを実装した場合、Cを使用します。また、独自のオペレーティングシステムカーネルまたは仮想マシンを実装する場合は、Cを使用します。

Windows API、Linux、Mac OS X、Solarisなどのハードウェアまたは低レベルのOS APIを扱う必要がある場合、低レベルのことを行うのは非常に良い言語です...コンパイラ+開発キット。

はい、もちろん。システムの重要な部分や低レベルの通信部分を記述するためにCを使用します。たとえば、ErlangプロジェクトでNIFを作成するためにCを使用するのは、それがこの種のジョブに適したツール（tm）だからです。または、Perlプロジェクトで同様の部分（XS）を作成するためにCを使用します。

私はプロとして、ほぼ毎日Cを使用しています。実際、Cは私が定期的にプログラムしている最高レベルの言語です。

Cを使用する場合：可能な限り効率的である必要がある低レベルのライブラリコードを記述します。私のグルーコードはCで書かれており、内部の計算ループはアセンブリで書かれています。

Cを使用する理由：複雑な引数の構造とエラー条件を処理するのはアセンブリよりもはるかに簡単であり、実際の計算を開始する前のそのような条件チェックのパフォーマンスオーバーヘッドはほとんど無視できます。Cはシンプルで明確に指定された言語であるため、許容できないパフォーマンスハザードを伴うコンパイル済みコードを見るたびに、コード生成を改善するために作業中のコンパイラチームと簡単に作業できます。

移植性は、Cのもう1つの大きな長所です。接着剤コードは、作業中のライブラリのハードウェア固有の複数の実装で共有されます。ほとんどのプラットフォームには、今月の言語フレーバー用の仮想マシンまたはインタープリターがありません。一部のプラットフォームには、優れたC ++コンパイラがありません。使用可能なCコンパイラが不足しているプラ​​ットフォームはほとんどありません（また、コンパイラチームと良好な関係を築いているため、通常、必要なサポートを得るのに苦労することはありません）。

はい、リソースに厳しい制約のある組み込みシステムでCを使用します。私はあり、それはソフトウェアコンポーネント間の強力なインターフェースを促進するために簡単にそれを作るため、代わりにC ++を使用しますが、プロジェクトに取り組んですべてのエンジニアは、C ++のコードサイズの肥大化につながる誤用に簡単であることを理解している場合にのみ（仮想関数とテンプレートを避けるために、物事の一例であり、 ）。

また、C ++プログラマーが1Kスタック上に10Kオブジェクトを作成しようとしているのを見ましたが、これは良い考えではありません。

私は主に、Xenハイパーバイザー、それが備えている各種ライブラリー、およびLinuxカーネルを使用しています。時々、デバイスドライバーを作成する必要があります（または、nxx仮想マシンがHRNGなどの単一のデバイスを共有できるように、ドライバーを再作成する必要があります）。Cは私の第一言語であり、私はそれにとても満足しています。

それを使用してスプレッドシートプログラムを作成しようとしますか？ありえない。各ツールにはアプリケーションがあり、多くのツールがあることを嬉しく思います。

私はCが大好きですが、ハンマーでネジをたたこうとはしません。

Cが新しいプロジェクトにとって賢明な選択である場合、必ず。そうでない場合は、別のものを使用します。

私はいくつかのプロジェクトにしたいと思います。組み込みシステムを実装する必要がある場合は、間違いなく、自律型航空機のコントローラーなどになります。一部の部品では、アセンブリを行うとさらに低レベルになる場合があります。

それがプロジェクトに合っていれば、私はそれに問題はありません。

Webアプリケーションを開発したい場合は、うーん、おそらくそうではありません（または、非常に強力で事実に裏打ちされた正当化を確認する必要があります）。

また、ボトルネックが明確に特定され、ネイティブコードを使用して最適化を実装できる場合は、主に他の言語で開発された他のプロジェクトからも使用します。たとえば、高度なレンダリング（レンダリングエンジンなど）のために集中的な計算を実行する必要があるJavaソリューション。サポートされているプラ​​ットフォームでない場合は、デフォルトでJava実装を使用できますが、一部のサポートされているプラ​​ットフォームではCからネイティブにコンパイルされた実装を提供し、パフォーマンスを大幅に向上できます。

そこにあるすべての言語にはまともなニッチがあります。私は頻繁に物事をより高レベルの言語で実装し、それらをより高性能にしたい、あるいは単によりポータブルにする必要があれば、それらを徐々にC-landに持っていきます。存在するほぼすべてのCコンパイラがあり、普遍的に利用可能なAPI（POSIXなど）に書き込む場合、非常に便利です。

今日、プログラミングの学習に興味のある人によく言うのは、ある時点でCを学習し、Cに慣れるようにすることです。あなたはそれを必要とする状況にいるかもしれません。複数回、静的にリンクされた小さな「高速再起動」プログラムをコンパイルし、scpを使用して、ディスクサブシステムが完全になくなったサーバー上のRAMディスクに配置する必要がありました。（安く、安価なサーバー、オンラインの冗長性はなく、小さなプログラムをロードする能力しかありませんか？Cが道です。）

また、自分で足を撃たずにCで作業する方法を学ぶことは、他の言語や環境で効率的に書く能力に大きく貢献します。少なくとも、それは私の経験でした。

私は確かにすべて、またはほとんどのものにそれを使用しませんが、その場所を持ち、ほぼ普遍的です：はい、私は過去に使用しましたが、将来的に使用します（私はしませんが現時点で知っている）。

はい、私はいつもそれをしています。

ライブラリを呼び出さない場合、Cから生成されたコードはOSサポートを必要としません。また、生成された機械語を細かく制御できます。したがって、カーネル空間に存在するドライバーや他のコードを書くのに最適であり、多くの種類の組み込みシステムのような制約のある状況が機能します。また、X Windows、GTK +、Clutterなど、私が共同作業するオープンソースプロジェクトの主要言語でもあります。

C ++でできることはすべてCでできますが、多くの場合、C ++のメカニズムによりコードの記述がより速く簡単になります。OOPとC ++クラスが機能をカプセル化する方法が大好きで、RAIIも大好きです。オブジェクトがスコープ外に出たときにデストラクタの自動呼び出しを慎重に使用すると、Cプログラミングの悩みの種であるメモリリークとリソースリークのほとんどがなくなります。STLは基本的に、高度に最適化されたアルゴリズムとデータ構造の巨大なライブラリです。Cから使用したい場合は、自分で作成するか、どこかで購入する必要があります。

残念ながら、私が理解できない理由のために、Linuxのランタイムシステムは、C ++を実行するために特別な共有オブジェクトライブラリ（WindowsのDLL、Macのdylibと同等）を必要とし、Cプログラムを実行しても見つかりません。だから、C ++ベースの共有オブジェクトをCベースのAPIで記述し、それをCプログラムから呼び出すという、私のお気に入りのMacとWindowsのトリックの1つはできません。

だからここに私の意思決定プロセスがあります：

1. デバイスドライバーのような制約のある状況で作業していますか？Cを使用します。
2. 他の人が使用しなければならないLinuxライブラリを書いていますか？Cを使用します。
3. すでにCで記述されているコード内で作業していますか？Cを使用します。
4. MacまたはWindowsライブラリ、または自分だけが使用するLinuxライブラリを作成していますか？内部をC ++で記述しますが、脆弱なバイナリインターフェイスの問題を回避するために、Cインターフェイスのみを公開します。
5. C ++を使用します。

1つの良い点は、C ++がCをコンパイルできるため、特定の状況で生成されたコードをきめ細かく制御する必要がある場合は、そのためにCを記述し、残りをC ++で記述し、すべてをC ++コンパイラでコンパイルできることです。

はい、ただしプロジェクトに依存します。Cは、低レベルのプロジェクトや最大のソリューションの一部に非常に適しています。

例えば。Bussinesロジックの場合は問題ありませんが、ユーザーインターフェイスの場合は問題ありません。

両方でなければならない場合

• 速い、そして
• ポータブル

その後、Cを使用します。

はい、実際に私は最近持っています！

私はCでのプログラミングが好きです。私はほとんどのプログラミングをpythonで行いますが、高速なコードが必要な場合があり、言語のシンプルさから得られる優雅さを本当に楽しんでいます。

私が現在取り組んでいるプロジェクトはデータベースであり、ご想像のとおり、パフォーマンスが重要です。現時点では、Cといくつかのpythonを使用していますが、最終的には完全にCではないにしても、大部分が使用されます。

はい！

Cは低レベルの言語であり、マイクロコントローラーのプログラミングにCを使用したり、パラレル、シリアル、モデムなどのクラシックポートからデバイスとやり取りするためにコードをまとめたりするような、Cがほとんど唯一のオプションである状況があります！

はい。キャリアのほとんどをC ++のプログラミングに費やしましたが、今ではほとんどのコードをRubyで記述し、パフォーマンスや低レベルのものへのアクセスが必要な場合は、C拡張機能を記述します。それは未来の男です！

オペレーティングシステムを記述している場合は、Cを使用します。これは今後20年以内には起こらないので、宝くじに当たって自分だけの素晴らしいLinuxディストリビューションを作る以外に何もすることがなければ、おそらくC＃、Java、Pythonなどに固執するでしょう。長い間Cを使用していませんでしたが、私はいつもCを使用して楽しんでいました。しかし、最近、頭をオブジェクト指向に取り巻くようになったので、それに戻らなければならない場合は、再び動き出すのに少し時間がかかります。

C ++は、プラットフォームおよびマイクロコントローラなどの組み込みデバイス間で移植可能です。（C ++はC、つまりマイクロコントローラーにコンパイルできます。）

Cは（他の関数として）他の言語に移植可能です。したがって、低レベルライブラリをプログラムする場合は、C ++よりも多くの互換性が必要です。

Haskellはプラットフォーム間で移植可能です（ARMは近日公開予定）が、マイクロコントローラなどの組み込みデバイスは移植できません。その速度はCとC ++に匹敵します。しかし、それは機能的であるため、ランタイムスタックの代わりにガベージコレクターを使用します。したがって、さまざまな時点（ガベージコレクション）およびさまざまな状況（サブルーチン呼び出しの代わりに継続）でCよりも高速および低速になる可能性があります。

プログラムの速度は変わらず、開発時間とバグ率が異なるため、可能な限り最も抽象的な言語を選択します。CとC ++は大きく異なりますが、Haskellの観点からは違いません。

私は片手または両手いっぱいを知っていても、他の言語は好みません。…いくつかの場合を除き、まあ、bash。

組み込みシステムには、数MHzのプロセッサクロックレートで、数キロバイト以下のRAMとおそらく数十キロバイトのフラッシュが搭載されていることがよくあります。Cは、このようなベアメタル環境で意味をなす唯一のオプションです。