Cプログラミング言語（C言語の問題点）
(hut.mearie.org)-
メモリの問題: GCや静的解析など、どのようなツールの助けも受けない。
-
未定義動作: 低水準環境を中心に使われるようになり、最適化の要求が多く、最適化のために未定義動作が増えた。低水準の性能と移植性の両立ができていない。
-
大規模プログラミングに不向き: モジュールやパッケージマネージャーが存在しない。
#pragma onceなど広く使われているものにも標準がない。
メモリの問題: GCや静的解析など、どのようなツールの助けも受けない。
未定義動作: 低水準環境を中心に使われるようになり、最適化の要求が多く、最適化のために未定義動作が増えた。低水準の性能と移植性の両立ができていない。
大規模プログラミングに不向き: モジュールやパッケージマネージャーが存在しない。#pragma once など広く使われているものにも標準がない。
7件のコメント
良い記事の共有ありがとうございます。ただ、些細ながら少し気になった点があり、コメントを残します。
筆者です（笑）。現在サイトはソフトリリース段階にあり、試験的に記事を作成しているため、内容は継続的に修正される可能性があることをご容赦ください。こちらでも直接トラッキングしていますが、メールでご意見をお送りいただくのも受け付けていますので、ご参考までに。
vcpkg はご指摘のとおり、現時点でもっとも有望なパッケージマネージャーに見えますし、Conan も実際にはかなり以前から存在していたプロジェクトです（元の記事を書いた時点ともそれほど離れていません）。ただし、これらのプロジェクトの最大の特徴は、それ自体にはビルドシステムが存在しないメタビルドシステムだという点です。（主要なサポート対象である CMake 自体がメタビルドシステムであることを考えると、メタ・メタビルドシステムと言えるかもしれません……）したがって、ビルドシステムそのものから生じる問題を特に解決するのは困難です。vcpkg にはもう少し考慮した痕跡が見られます。たとえば、同じ依存関係の異なるバージョンが（異なる依存経路を通じて）1つのプロジェクトで必要になる場合、enlistment を分割することは可能ですが、これはビルドシステム自体の限界を回避する方法にすぎません。たとえば Rust と Cargo であれば、この場合は両方のバージョンをビルドして、1つの crate から参照しても支障がありません。
また、vcpkg は現時点では Visual Studio において NuGet レベルのツール統合すら行われていないようです（MSBuild 統合のみ……）。Linux/BSD ディストリビューションのパッケージマネージャーとの統合も、それほど進んでいないように思われます。この問題は、現在の言語別パッケージマネージャーが直面している最大の課題でもあります。Rust のような新しい言語は個別撃破で解決していますが、C/C++ のパッケージマネージャーであれば、既存システムとの統合を必ず志向すべきところ、その進展はまだ鈍いままです。この部分が解決されて初めて、vcpkg 系のものが C/C++ 開発で一般的に利用可能なツールになったと言えるでしょう。そうなっていないことが、私が記事でパッケージシステムを低く評価した主な理由です。（記事で示した single-file library の氾濫もまた、vcpkg 系のシステムがそれほど訴求できていないことを示す間接的な証拠でもあります。）
詳細なご回答ありがとうございます。とはいえ、根本が = m=.. ビルドなので、npm やほかのパッケージマネージャーと違って追随できない壁があるのでしょうね。vcpkg は最近バージョンに関する悩みが多そうですが、乗り越えるのは簡単ではなさそうです。
C++20 のモジュールシステムがこの問題の解決策になるのでは。とも思いますが……。そうなると範囲が C 言語を超えてしまいますし（……）。C 言語にはいばらの道しか残っていなさそうですね。今さら C20 を策定したとしても、C++ のようにバージョン移行率がそれほど高くはならないでしょうし……。
良いご意見ありがとうございます。
私個人の考えはこうです。Cのパッケージマネージャーがいくつかあるのは良いことですが、問題はこうしたパッケージマネージャーがあまり使われていない点だと思います。もう少し正確に言えば、すでにCのレガシーがあまりにも巨大であるため、上で述べた問題点を解決するには、あまりにも遠くまで来てしまったのではないかと思います。だからこそ、Rustのような新しい言語へ移行しようとする試みが多いのではないでしょうか。
お話を聞いて改めて考えてみると、上のパッケージマネージャたちは C言語の延命というより、C言語を使わざるを得ないプログラマの延命に焦点が当たっているようです。
今や新しい家（C++、Rust...）に引っ越すべき時期になって、昔の家にあった OpenGL や Lua のような家具が必要になるとき、パッケージマネージャがなければ手作業で運ぶしかなかったのですが（リンクして、make して、DLL や lib のバージョンが合わずに頭を抱えて……LNK エラーを見て飛び降りたくなって……）、今はパッケージマネージャがあるので、梱包付き引っ越しのようにきれいに移せるようになりました。これまで作ってきたものがあまりにも多いので、新しい家でも使わなければならないことはあるでしょうし……
もはや言語そのものの長所より、これまで積み上がってきた蓄積のメリットのほうが大きいのを見ると、本当に死につつある言語なんだなと実感しますね……（
いろいろな面で、Rust が next C/C++ のイメージを最も強く持っているようです。 （next と見なされるいくつかの言語の中では、相対的に最も複雑だというイメージも……笑）
画像だけでなく、Rustは実際にも難しいようです。