私は読書の途中ですLinuxプログラミングインターフェイスおよび例によるLinuxのプログラミング両方とも非常に良い本であり、Linux APIについて非常によく説明しています。しかし、実際には、実際のプロジェクトでは、可能な限り、C++標準ライブラリ、Boostまたはその他の優れたC++ライブラリ（よく書かれた移植性の高いC++ライブラリがあります）をC APIよりも好むと思っています。なぜなら、良いC++コンパイラとライブラリ（Boost、TBBなど）がターゲットプラットフォームで利用可能な場合、Linux APIを直接使用する必要があるのはなぜですか？私はWindows APIについても同じことが言えると思いますが、Windowsシステムのプログラミングについてはあまりよく分かりません。C++はLinux APIの一部を非難しますか？
これはC++の新機能ではありません。 Cでは、長い、長い時間のためのファイルを開くには二つの方法があった：
// Only on POSIX
int fdes = open("file.txt", O_RDONLY);
または：だから、
// Any hosted C environment, POSIX or otherwise
FILE *fp = fopen("file.txt", "rb");
であれば、なぜ誰もがPOSIX固有のバージョンを使用するのでしょうか？答えは簡単です - POSIXファイル記述子で動作するシステムコールが多数あります。たとえば、select。パイプやソケットのようなファイル以外のものを作ることもできますし、他のプロセスに渡すこともできます。 POSIXファイル記述子を使用する長い伝統があり、我々はそれらとネットワークプログラミングを行う方法に関する多数の書籍と参考文献を持っています。
したがって、ポータブルバージョンとパワフルバージョンの間のトレードオフです。それはいつもありました。
このの残りの半分は、Linux上のファイルで作業しているときにPOSIXインターフェイスで作業している時間です。ライブラリはそれをあなたから隠すだけです。 Boostはそれを使用し、Cランタイムはそれを使用し、JREはそれを使用し、GHCはそれを使用します。多くの（ほとんどの）言語ランタイムはC言語で書かれており、システムコールへの直接アクセスが優先されます。
できるだけ上位レベルのAPIを使用する必要があります。通常は作業が速く、コードを別のプラットフォームに移植する方が簡単です。しかし：あなたがより高いレベルのAPIを隠すことができなかったことを、様々な癖やパフォーマンスの問題を理解して、それはunderylingオペレーティングシステムのAPIを知っておくと便利だためlaw of leaky abstractionsへ
*漏れ抽象の法則を思い出させることに感謝します*。 – pic11
特定のプラットフォームではC++標準が公開されていません。プラットフォームに依存しないため、いくつかのプラットフォーム機能/機能を使用する場合は、通常はsystem apiというプラットフォーム依存機能を使用する必要があります。その意味では、C++ライブラリはlinux/windows apiを非難しません。
使いやすさと安全性と電力のトレードオフがあります。 Boostのライブラリは、しかし、espのパワー引数のビットを切り捨てます。 ASIOソケット・ライブラリを備えています。 –
@larsmans：残念ながら、ASIOは通常、Linuxでの仕事にとって間違ったツールです。 ASIOは、POSIXの傘下にある多くのAPIの1つにすぎません。 –
@Dietrich：Boost.AsioとPOSIX ASIOは大きく異なります。 IIRCブースト。AsioはPOSIX ASIO APIを使用していません。 –