![GNU/Linux 世界で C++ を使用する [閉じる]](https://linux33.com/image/161122/GNU%2FLinux%20%E4%B8%96%E7%95%8C%E3%81%A7%20C%2B%2B%20%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%99%E3%82%8B%20%5B%E9%96%89%E3%81%98%E3%82%8B%5D.png)
組み込みシステムを使用するC ++開発者として、Linux APIを継続的に使用しながらC ++の「考え方」を維持することは困難です。たとえば、ポーリングを使用してデバイスの接続/切断を監視し、ステータスコンテキストを使用し、通常C ++標準ライブラリを使用してよく表現できるパターンを使用するlibudevを使用したいとします。
stat。C++17は今std::filesystem。
さらに、コードの明確さと「完全性」のために対話したいすべてのGNU / Linuxサブシステムに対してC - > C ++バインディングを作成する時間はありません。これらのユーザー空間インターフェイスのほとんどは非常に現時点では成熟段階に達し、C++へのバインディングが存在し維持されると期待するのはそれほど野心的なことではないと思います。前の例を考えてみると、Pythonはpyudevlibudevの素晴らしい抽象化を提供します。
私の質問は次のとおりです。
GNU / Linux環境でプログラミングするとき、ほぼすべてのものに対してハッキーバインディングを書くことなく、C ++コードをきれいで表現力のあるものに保ちます（C ++哲学を維持）。
答え1
一般に、人々はC ++でのみC APIを使用します。
他の人がもう少しオブジェクト指向のC ++インターフェイスを作成したことを確認できます。たとえば、「udev C ++」のGoogle検索の最初の結果はGitHubリポジトリです。ディミツリーイシュチェンコ/udev、役に立つかもしれません（大胆ではありません）。たとえば、C++ D-Bus を使用して udev とのやり取りを実装することもできます。sdbus-C++。
宣伝する標準のPOSIXライブラリのC ++スタイルインタフェースでいくつかのスペースを埋めることができる他の「半標準」C ++ライブラリの主なソースです。たとえば、ファイルシステムライブラリはC ++ 17で採用される前にBoostに存在していました。プロセス間の強化共有メモリ、mmapなどを処理します。ブーストプロセス、Boost.Program_optionsとブースト。一部のPOSIX領域もカバーしています。