標準の C ライブラリに加えて、 C 用の優れた汎用ライブラリを探していたところ、 glibを使用するための提案がいくつか見られました。あなたのコードではどれくらい「目障り」ですか？押し付けがましさの意味を説明すると、リファレンス マニュアルで最初に気付いたのは基本的な型のセクションで、「何gint、、、gcharおよび gprefixing geverything gin gmy gcode gnow を使い始めようか?」と考えました。
より一般的には、コード内の他の関数やファイルがその使用を認識しなくても、ローカルでのみ使用できますか? コードに特定の仮定を課したり、コンパイル/リンク プロセスに制約を課したりしますか? グローバルデータ構造のために実行時に多くのメモリを消費しますか? 等
glib の最も目立たない点は、glib を使用するプログラムまたはライブラリがリソースの枯渇に対して堅牢ではないことです。失敗すると無条件に呼び出さabortれmalloc、ライブラリ全体が内部割り当て関数g_mallocが「失敗しない」という概念に基づいて設計されているため、これを修正するためにできることは何もありません。
醜い "g" 型に関しては、キャストは絶対に必要ありません。型は標準型と 100% 同等であり、基本的に glib の初期の (誤った) 設計からの粗悪品です。残念ながら、glib 開発者は C についてあまり理解していません。これは、次の FAQ からも明らかです。
g_print、g_malloc、g_strdup などの glib 関数を使用する理由
「g_malloc()、g_free()、および兄弟に関して、これらの関数は libc の同等の関数よりもはるかに安全です。たとえば、g_free() は NULL で呼び出された場合に戻ります。
(ソース: https://developer.gnome.org/gtk-faq/stable/x908.html )
参考までに、free(NULL)完全に有効な C であり、まったく同じことを行います。単に返されます。
私はプロとして 6 年以上 GLib を使用してきましたが、それは称賛に値します。これは非常に軽量で、リスト、ハッシュテーブル、rand 関数、io ライブラリ、スレッド/ミューテックス/条件、さらには GObject などの多くの優れたユーティリティを備えています。すべて移植可能な方法で行われます。実際、Windows、OSX、Linux、Solaris、iOS、Android、および Arm-Linux で同じ GLib コードをコンパイルしましたが、GLib 側で問題は発生しませんでした。
目立たないという点では、私は間違いなく「g を購入」しました。これが、安定した移植可能なコードを高速で作成する上で非常に有益であったことに疑いの余地はありません。高度なテストを書く場合は特にそうかもしれません。
g_malloc が目的に合わない場合は、代わりに malloc を使用してください。
もちろん、「他の場所で忘れる」ことができます。もちろん、他の場所がglibコードと何らかの形でやり取りしない限り、接続があります(そして、議論の余地がありますが、実際には「他の場所」ではありません)。
g先頭に(gcharなど)が付いた通常の型を使用する必要はありませんgint。などと同じであることが保証されていcharますint。gintたとえば、キャストする必要はありません。
意図は、アプリケーション コードで を使用してはならないということだと思います。gintこれは、glib コードの一貫性を高めるために含まれているだけです。