アカウント名:
パスワード:
WindowsだとQtとかwxWindowsとかboostみたいな巨大ライブラリはDLLだとパスが関係してきたりするし、静的リンクにするにはサイズが大きかったりと扱いづらいと感じます。
特に、最近は64bitプラットフォームが一般化してきて32bitだけ入れとけばいいと言う訳にはいかなくなってきたので、適切なプラットフォーム用のDLLを読ませるためにアプリと同じディレクトリに入れたりすると共有ライブラリの意味が薄らいでしまうし、DLL名の衝突を避けられる置き場所が限定されるので共有ライブラリ化には疑問を持っているのですが、ビルド済みのライブラリの配布はDLLになっていることが多いですね(DLLを使用する設定がデフォルトだったり静的リンクにするとCのランタイムも静的リンクになってしまうとか)。
フレームワークにも新機能を追加していくから、一度組み込まれた物は簡単に外すことができなくてさらに巨大化してしまうというのもあります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
巨大なフレームワーク (スコア:0)
WindowsだとQtとかwxWindowsとかboostみたいな巨大ライブラリはDLLだとパスが関係してきたりするし、
静的リンクにするにはサイズが大きかったりと扱いづらいと感じます。
特に、最近は64bitプラットフォームが一般化してきて32bitだけ入れとけばいいと言う訳にはいかなくなってきたので、
適切なプラットフォーム用のDLLを読ませるためにアプリと同じディレクトリに入れたりすると共有ライブラリの意味が薄らいでしまうし、
DLL名の衝突を避けられる置き場所が限定されるので共有ライブラリ化には疑問を持っているのですが、
ビルド済みのライブラリの配布はDLLになっていることが多いですね
(DLLを使用する設定がデフォルトだったり静的リンクにするとCのランタイムも静的リンクになってしまうとか)。
フレームワークにも新機能を追加していくから、一度組み込まれた物は簡単に外すことができなくてさらに巨大化してしまうというのもあります。
Re:巨大なフレームワーク (スコア:0)
たしかに、OSによって、C#、Objective C、Javaと使える言語がまちまちすぎるのは問題ですが、
C++は大規模プロジェクトには明らかに向いていないですよね。
フレームワークの選択以前に、言語の選択が将来を狭めるので、どうするかは本当に真剣に悩まないといけないですが。