OSASKスレッド Part2

>>634
そんなに使うかヴォケ。使えもしない事を考えてどうすんのよ。
WindowsAPIを比較すんならまずそんだけWindowsでウインドウ開いてから言ってくれ。

だいたい、
0x0FFFFFFF：Window
0x1FFFFFFF：サウンド
　　…
ってアプリ側で割り振ればいいじゃねーか。アプリ側は何のライブラリを使うか
わかってんだし使い方も分かってんだから同時使用できないわけねーだろ。
ＬＣはアフォなのか？

>>629

>LightCone

「あっさりしたとうもろこし」、「軽いとうもろこし」の意味だと
思い込んでいたよ‥‥。

>>624
VBにも空き番号を返すぐらいの関数はあったと思うけど…？

>>628
マジでだれか止めてください
今日は家でパソの前にいるからいいものの、もし、家にいなかったらと思うと、ぞっとします

>>636
基本的な質問だけど、OSASKのスロットって、予約するだけなの？
さすがに、0x0FFFFFFF 個も「確保」はできないと思うんだけど。

>>636
勝手に無関係な人の名を出すな。

　「個数の見積もり」は、高速化とか効率を考える時にはかなり
重要で役に立つものでもあるけど、せいぜい1000個で十分だから、
1000個までしか使えなくてもいいだろう、的な見積もりは、
かなり危険。
　
　CPUアーキテクチャなどの制限で、他のあらゆる方法を使っても、
どうにもならない場合を除き、純粋のソフト的な設計で制限を
作ってしまうのは、ソフトの設計の問題となる。

　Window の個数がたかだか 1000 個、っていう見積もりは、
今のハードのパワーや、メモリ容量などを鑑みた時、正しい
見積もりだとは思うし、実際、Windows などでもそういう制限
はあるかもしれない。しかし、「スロット」の概念は、どうしても
必要なものではない。他の優れた代替法が明らかに存在している
のに採用してしまったことによって、「足かせ」になってしまって
いるのだから、最悪。

だから、1000個じゃないんだって、ちょっと遠慮しても0x00FFFFFF個だぞ？
ソフト側の設計もクソもないだろ。そんなのリソース無駄遣いするアプリなんて
使いたくもない。

Windowsだって32bitハンドルに依存してるんだし、それで足りなくなったら
64bitに移行するだろ？　スロットも足りなそうになったら64bitに移行すれば
いいだけ。何か問題でも？


しかしBBSのアレ、システム側の問題なんだろうか、それともF5連打なのだろうか。
リロードやめてくれ〜、の投稿の後すぐにロコ氏の投稿が出てるのがどうも
漏れ的にうさんくさいのだが…。

>>643
今のOSASKにスロットの「予約」が出来るの？

そういう実装はOS側のコーディングが面倒なはずだけど、
実際やってるの？

>>644
なんで「予約」なんかする必要あるの？　アプリが責任持って管理すれば
いいんでしょ？　スロットはアプリ固有のものなんだから。

逆に言えばそういう面倒な部分をOSが管理しない分だけスロットの方が
効率が良くなると言えるよな。

0x00FFFFFF 番から使って、ってライブラリに言ったからには、
当たり前だけど、0x00FFFFFF 番以後のスロットもつかえると
いうことでなければならない。

もし、単純な方法でこれを実現するなら、百万個程度の配列
を確保しないとならなくなる。

それを避けるには、ハッシュを使うか、何らかの「予約」の
考え方に基づいた実装をしなければならない。

　と　ん　が　り　コ　ー　ン　必　死　だ　な　！

>>647
別に。

>>643
F5連打とみたが、どうやらそれだけでもないらしい。
通りすがり1の言うように、ブラウザがOperaなら
勝手にリロードを繰り返す時があるので多少は納得できる。
F5連打だから、投稿があったのが分かったのだと思うが、違うのかな
うさんくさいが、こっちがどうこう言えるものでもないし。
あと、通りすがり2が誰だか知りたいな、1のほうは誰だかしっとるしｗ

>646
実装の話に移るのか？（ｗ

別に単純に配列100万用意してもいいだろうよ。
一つ16Bとしてたかだか16MBだ。
で、16MBの物理メモリが必要になるの？

>>646
意味分からん…。アプリ側のライブラリでリストでも使って、使用スロットの
管理すりゃいいだけでしょ？　おそらくスロットを重なるように指定した時の
ことを言ってるんだと思うけど、それはアプリ側の責任と言えるんじゃないのか？

>648
とんがりコーンなのかよ！

>>652
漏れも思った（ｗ

ML面白いことになってるな

doc000bとか、最近のスレとか読んで思うに、アプリ側で使うリソースを
きっちり管理するってポリシーならスロット方式も有りかもね。
リソース管理をなるべく抽象化する方向にある汎用OSとは逆行してるけど、
敢えてやっているんだろうし。むしろリソースの厳しい組込み用途なんかに
(スロット方式は)適していそうだけど。

ただ、プラグインみたいに実行時に外部から与えられるデータでdlopen()
するような場合はアプリ側でスロット使用量を見積もれないよなあ。
アプリ側ではdlopen()されたライブラリが使える上限を決めておいて、
それ以上のリソース使用は拒否することになるんだろうか。
それともdlopen()でない別のパラダイムがある?

>>651
　使用する予定のスロットや、実際に使用しているスロットなんかを
内部的にリストで管理するの？

　そんなら、効率はめちゃくちゃ落ちるよ。

>>650
たかだが、16MB だなんて、気軽に考えれないでしょうが。
まず第一に、OSASK は、セグメント方式でタスク間の保護を行ってい
るので、「線形アドレス空間」自体は、タスク全体の合計で 4GB
に制限されてしまう。

だから、16MB のうち、実際にメモリに割り付けられていないアドレス
領域があったとしても、アドレス空間自体は、圧迫されてしまう。

しかも、100万個というのは、飽くまでも例で、ライブラリの数が
増えてくればもっと増える。


それから、スロット方式を採用するためにこんなに面倒なことに
なる、ってことだよ。ハンドル方式ならもっと簡単。

川合の「ちょっと一言」:

川合氏は、こんな変わった意見をお持ちのようです。
オブジェクト指向を全く理解していません。
相手が使用するリソースは相手が勝手に確保するのが基本です。
多人数で行う大規模なプロジェクトの場合、一々他人のプログラム
がどれだけのリソースを食うか責任持てるほど生やさしくないです。
　スロットが多すぎれば「無駄」、逆に少なすぎれば、
突然のダウン、を導き、スロットの消費数の決定は、
恐ろしく難しいです。それは、技術力があれば解決する問題
ではなく、根本的なもの。技術力がある人は、こういう方式を
採用しません。それが真の技術力です。

-----------------------------------------------------
　申し訳ありません、僕は634さんの真意を汲み取り間違えました。
ここまで物分かりの悪い方だとは思わなかったんですが、とにかく
僕の読解力の無さをお詫びいたします。

　Lib1GetNumberOfSlots()なんていう関数をどうして使うのかと
思ったら、ライブラリに聞いているんですか・・・。なんでライブラ
リに聞くんですか。人にお使いを頼むときに、にんじんとピーマンを
買ってきてくれと言ってから、相手にいくらほしいか聞いているわけ
ですよね？そんなの吹っかけられますよ。第一、そのライブラリに
したって、ライブラリをどのくらい利用するつもりなのか分からな
いから、答えようがないじゃないですか。そういうことはライブラ
リのドキュメントに書いてあるべきことだと思います。つまり
「このライブラリは、まず基本値として最大で10個のスロットを
利用する上に、ウィンドウ一つにつき4つのスロットを消費します」
というふうに。だからメインルーチンはライブラリに聞くなんてい
う愚かなことはいたしません。自分はLib1をこれくらい使うつもり
だから、スロット0x200〜0x300はLib1に与えよう、となるわけです。

　結局634さんはご自分にスロットを使いこなすだけの才能がないこと
を証明してくださっただけです。確かに634さんの方法だとうまく
いきませんね。勝手にしてください、もう。・・・分からないなら
教えてくださいって言えばいいのに、それすらできず、挙げ句のはて
にご自分が理解できないようなシステムは駄目だっておっしゃるん
ですよ。ただ単に634さんが実力以上に傲慢なだけじゃないですか。
口先だけなのは、あなたの方だったんですね。にぶい僕でも、ついに
分かりましたよ。

　ものはついでですので、もうちょっと書きましょう。ライブラリが
明らかにしておかなくてはならないのは、何もスロットの消費量だけ
ではありません。ヒープやスタックも目にみえて消費するなら明記
しておく必要があります(利用状況に応じて変化するというなら、
その見積もり方を)。リンク時にこれらを総合してユーザは指定する
わけですから。

-----------------------------------------------------
　

　それから、「ライブラリに関係したもの」は、ライブラリに問い合わ
せるのが当たり前。

　現状のバージョンでは、スロットの役割が、Window などに限定
されているものの、将来拡張が行われていっ場合、
自分以外の人が作ったライブラリが、どれだけのスロットを
消費するのか見積もるなんて簡単に出来るわけが無い。
　もし、ライブラリのドキュメントに書いてあったとしても、
現バージョンだけでしか保証できない。
　リソースの量なんかは、バージョンが上がれば、飛躍的に
大きくなるものだ。

　静的ライブラリなら、バージョンアップ時は、必ず再コンパイル
するからいいようなものの、こんな方式では、動的に自動アップデート
なんて出来様がないよ。

　Lib1GetNumberOfSlots() という関数を使っていればまだしも、
頭で見積もって埋め込み、なんてなんたる馬鹿げたコーディング。

　この関数に引数を持たせて、相手に見積もらせれば少しはまし
になるかもしれないが、それでも、随時に動的に確保するのに比べ
れば全くナンセンスだ。

　センスが最悪。

「ウィンドウ一つ辺り 4 つのスロットを消費します」
なんてこと、ライブラリがバージョンアップ後も保証できること
じゃない。

もし保証しようとすれば、それだけバージョンアップの制限になる。

ライブラリが保証することは「機能」。
リソースの量じゃない。

機能を向上させる際、昔のリソースの制限を保証なんてことを
考えれば、必ず無理が来る。

それは歴史が物語っている。

　アプリがバージョンアップする際、使用するウィンドウの枚数が一つ
増えたとする。

　そしたら、ライブラリのスロットの消費数を「４つ」増加させな
ければならない。

　ウィンドウの中に子ウィンドウを「いくつか」増やした場合どうな
るか。

　いちいち、何個増やしたか再点検して、再びその４倍だけライブラリ
のスロットを増やす、、、。


　リソースを「ギリギリ」に使った場合、最高の効率が出る。
こんな小手先な方法で効率をよくしようとしても無理。
　これは、アセンブラ時代に行われた古典的手法を彷彿とさせるが、
プログラミングが複雑化し、大規模な拡張が行えないことになるだ
ろう。
　オブジェクト指向が、開発効率が上がる理由は「余計なことを
考えなくて済む」からだ。特に、いったん、クラス化してしまえば、
内部実装がどうなっているかを考えなくて済むからこそ、開発
効率が上がる。

　しかし、OSASKの方式は、全くそうではなく、内側の仕様を
外側が常に気にしなければならなくなる。

だ、か、ら。多重投稿、しかも長文うぜーって言ってんだろ。
ちゃんとまとめろ。とんがりコーンは学習能力ないのか？

>>656
＞　使用する予定のスロットや、実際に使用しているスロットなんかを
＞内部的にリストで管理するの？

勝手に脳内補完しないでください。「実際に使用しているスロット」のみを
リストに保存するだけです。こうすればスロットを使い尽くすまでは単純に
最後のスロット番号から次の割り当てスロット番号を推定できるだろ？

（無いと思うが）使い切ってまた初めから回った時に使用リストを見て
重なって無い部分を使用するというイメージ。リストの参照や前進の
アルゴリズムをうまくやればかなりの効率が期待できると思うが。