作成しているバイナリがあり、実際には使用されないファイルの束をインクルードし、それらのインクルードファイルによって記述されたライブラリへの後続のリンクを実行するとしますか？（繰り返しますが、これらのライブラリは使用されません）
コンパイル時間の増加を超えて、これの悪影響は何ですか？
質問する
506 次
13 に答える
8
私が考えることができるいくつかは、名前空間の汚染とバイナリサイズです
于 2009-04-15T14:29:07.800 に答える
5
コンパイル時間に加えて; 複雑さの増大、デバッグ中の不必要な注意散漫、メンテナンスのオーバーヘッド。
それを除けば、何もありません。
于 2009-04-15T14:30:39.733 に答える
4
サーシャがリストしているものに加えて、メンテナンス費用があります。未使用のものを削除することを選択した場合、使用されているものと使用されていないものを簡単に検出できますか？
于 2009-04-15T14:30:14.147 に答える
4
ライブラリが使用されない場合は、実行可能ファイルのサイズが大きくならないようにする必要があります。
于 2009-04-15T14:33:32.627 に答える
3
正確なリンカによっては、未使用のライブラリのグローバルオブジェクトがまだ構築されていることに気付く場合もあります。これは、メモリオーバーヘッドを意味し、起動コストを増加させます。
于 2009-04-15T14:42:55.567 に答える
1
含めているが使用していないライブラリがターゲットシステム上にない場合、それらが必要でなくてもコンパイルできません。
于 2009-04-15T14:58:58.057 に答える
1
これは、Cライブラリと静的ライブラリに関する同様の質問に対する私の答えです。おそらく、C++のコンテキストでも役立つでしょう。
于 2009-04-15T15:00:14.513 に答える
1
コンパイル時間の増加について言及されています。そのことから、ライブラリは動的ではなく静的にリンクされていることがわかります。この場合、リンカが未使用の関数をどのように処理するかによって異なります。それらを無視すると、ほとんどの場合、メンテナンスの問題が発生します。それらが含まれる場合、実行可能サイズは増加します。さて、これはハードドライブ上の場所よりも重要です。大きな実行可能ファイルは、キャッシュの問題が原因で実行速度が低下する可能性があります。アクティブなコードと非アクティブなコードがexeで隣接している場合、それらは一緒にキャッシュされ、キャッシュが効果的に小さくなり、効率が低下します。
VC2005以降には、PGOと呼ばれる最適化機能があります。これは、頻繁に使用されるコードの効果的なキャッシュを保証する方法で、実行可能ファイル内のコードを順序付けます。g ++にも同様の最適化があるかどうかはわかりませんが、調べる価値はあります。
于 2009-04-15T15:00:25.933 に答える
1
ここに問題を少しまとめました。必要に応じてwikiで編集してください。
主な問題は次のように思われます。名前空間の汚染 これは、将来のデバッグ、バージョン管理、および将来のメンテナンスコストの増加に問題を引き起こす可能性があります。
関数/クラス/名前空間の参照が維持されるため、少なくともマイナーなBinary Bloatもあります（シンボルテーブル内？）。ダイナミックライブラリは、バイナリサイズを大幅に増やすべきではありません（ただし、バイナリを実行するための依存関係になりますか？）。GNU Cコンパイラから判断すると、静的にリンクされたライブラリは、ソースで参照されない場合は、最終的なバイナリに含めるべきではありません。（Cコンパイラに基づく仮定、明確化/修正が必要な場合があります）
また、ライブラリの性質によっては、グローバルおよび静的オブジェクト/変数がインスタンス化され、起動時間とメモリオーバーヘッドが増加する場合があります。
ああ、コンパイル/リンク時間が長くなりました。
于 2009-04-15T15:05:31.940 に答える
1
ソースツリーでファイルを編集すると、作業中のシンボルがソースファイルに表示されるため、イライラします（たとえば、プロトタイプを変更したばかりの関数名、または悲しいことに、より一般的には、プロトタイプをヘッダーに追加しました）、使用法が正しいことを確認する必要があります。そうしないと、コンパイラーがそのファイルでの使用法が正しくないことを通知します。そこで、ファイルを編集します。次に、問題が発生します-このファイルは何をしているのですか？そして、コードは製品で「使用」されていますが、実際にはまったく積極的に使用されていないことがわかりました。
月曜日にこの問題の発生を発見しました。10,000行以上のコードを含むファイルが関数'externvoid add_remainder（void）;'を呼び出しました。引数は0です。それで、私はそれを修正しに行きました。次に、残りのコードを調べました...それは約15年前の開発スタブであり、削除されたことはありませんでした。コードをきれいに削除すると、半ダース以上のファイルに小さな編集が含まれることが判明しました。万が一の場合に備えて、列挙型の途中から列挙型定数を削除しても安全かどうかはまだわかりません。一時的に、「未使用/廃止-安全に削除できますか？」とマークされます。
そのコードのチャンクは、過去15年間、コーブカバレッジがゼロでした-生産、テスト、...確かに、それは広大なシステムのほんの一部にすぎません-パーセンテージで言えば、チャート上で1％未満のブリップです。それでも、それは余分な無駄なコードです。
不可解。迷惑。気のめいるように一般的です（今年これまでに少なくとも半ダースの同様のバグをログに記録して修正しました）。
そして、私の時間と他の開発者の時間の無駄です。このファイルは、私が行っていたことを他の人が行っていることによって、何年にもわたって定期的に編集されていました。
于 2009-04-15T15:30:04.707 に答える
0
非常に小さな部分しか使用されていない.libファイルのリンクで問題が発生したことはありません。実際に使用されるコードのみが実行可能ファイルにリンクされ、リンク時間は（Visual Studioを使用して）著しく増加しませんでした。
于 2009-04-15T14:46:10.320 に答える
0
バイナリにリンクして実行時に読み込まれると、重要な初期化が実行される可能性があります。これにより、少量のメモリを割り当てて不足しているリソースを消費し、予期しない方法でモジュールの状態を変更することができます。下。
未知のものをたくさん排除するために、不要なものを取り除くほうがよいでしょう。
于 2009-04-15T14:48:07.303 に答える
0
ビルドツリーが適切に維持されていないと、コンパイルに失敗する可能性さえあります。スワップスペースのない組み込みシステムでコンパイルする場合。コンパイラは、大量のオブジェクトファイルをコンパイルしようとしているときにメモリが不足する可能性があります。
それは最近私たちの仕事で起こりました。
于 2009-04-15T15:49:33.397 に答える