[#43767] UDP通信時のエラー検出 — "中田雅美" <mimiger2007@...>
中田(雅)と申します。
小西 弘将です。
In message <6DC7D411CB0FB4konishi@raax.co.jp>
中田(雅)です。
In message <407af920708010215n6cb6a4a7o32a164da7d0b6901@mail.gmail.com> 2007-08-01T18:15+0900,
[#43777] gsub! で定数を書き換えられてしまう — 古川大輔 <mogya99@...>
はじめまして。もぎゃ と申します。
[#43781] WEB公開されるML投稿記事について — REI OKAMOTO <okamoto@...>
昨日投稿した岡本です。
[#43796] mod_ruby 環境の Rails での日本語文字列の truncate — "IKEDA Katsumi" <ikedak@...8.so-net.ne.jp>
池田と申します。
[#43806] Procの仕様について — "SHIMADA Koji" <snoozer.05@...>
しまだです。
[#43809] 配列についての質問 — "142QN4969@..." <ohrsts@...>
小原です。御世話になっています。
[#43815] 日本Rubyの会のHPでHikiError — "SHIMADA Koji" <snoozer.05@...>
しまだです。
[#43846] 質問:シェルスクリプトにすると uninitialized constant DATA — sw@...
環境は Windows XP
なかだです。
コメント、ありがとうございます。
[#43857] Hashへの生成順は保障されないのか? — Hiroshi Kasamatsu <qqmn89yb9@...>
こんにちは、笠松と申します。
Hiroshi Kasamatsu wrote:
皆さん、早速のレスありがとうございます。
Hiroshi Kasamatsu wrote:
Urabeさん、笠松です。レスありがとうございます。
Hiroshi Kasamatsu wrote:
cuzic です。
cuzic wrote:
In article <46C9E7BB.4060100@ruby-lang.org>,
おお、田中さんを満足させる説明ってのは結構ハードル高そうだな。
# 出遅れたので、レスすべきメールが判らなくなってしまったので、手近なのに
まつもと ゆきひろです
なかだです。
ささだです。
まつもと ゆきひろです
なかだです。
At Tue, 21 Aug 2007 13:59:43 +0900,
ささだです。
At Tue, 21 Aug 2007 19:29:11 +0900,
In article <86sl6dgikh.knu@iDaemons.org>,
In article <87zm0kaz60.fsf@fsij.org>,
Yuguiといいます。
まつもと ゆきひろです
ささだです。
[#43868] ruby1.8でssl通信@stmp/pop3 — "Tomo Matsumoto" <tomoyuki28jp@...>
松本と申します。
[#43923] [ANN] isi-1.1.3 released! — NISHIMATSU Takeshi <t_nissie@...>
西松と申します。
[#43939] Windows で正確なファイル名を取得するには — Five point Five <5.5@...>
Five point Five です。
[ruby-list:43937] Re: Hashへの生成順は保障されないのか?
まつもと ゆきひろです
In message "Re: [ruby-list:43936] Re: Hashへの生成順は保障されないのか?"
on Sat, 25 Aug 2007 01:59:53 +0900, m-ohkubo@sakura.email.ne.jp (Mitsuhiko OHKUBO) writes:
|> * 全く同じ機能で性質だけ異なるクラスを複数用意するのは大ク
|> ラス主義を標榜するRuby的でない
| 「大クラス主義」が良くわからかったのですが、「少機能のクラス
|を多数用意するよりも多機能なクラスを少数用意しましょう」というこ
|とだろう、と思っての提案なのですが、違ってたらご指摘ください。
そういうような意味です。
| Hashインスタンス生成時に順序維持の特性を持つハッシュライブラ
|リの実装を使うか、持たないハッシュライブラリの実装を使うかを指定
|できるようにはならないでしょうか?順序維持の特性が重要な場合があ
|る一方で、他の特性(メモリ使用量とか)が重要な場合もありますので、
|選択できる道を残しておいて欲しいです。
選択肢が多い方がよいかと言うと必ずしもそうではないのです。と
いうか、ハッシュエントリひとつあたり2ワードの増加が問題にな
るような局面ではRubyの使用そのものが不適切な可能性が高いと思
います。
|> * Hashに順序を導入する(ただし、インスタンス変数やシンボルテー
|> ブルなどにはない)
| 将来、さらに高性能なハッシュライブラリが現れた場合に、Hashの
|仕様が順序維持を含むために、Hashの実装にそのライブラリを利用でき
|ない、という状況は起き得ることなのでしょうか?
| もう一つ、同様の場合に、Hashの実装にそのライブラリを利用する
|ためにHashの仕様から順序維持が外される、という状況は起き得ること
|なのでしょうか?
これはknuさんの懸念ですね。ですが、ハッシュと言うのはかなり古
典的なアルゴリズムですし、これから極端に性能が違うライブラリ
が登場する可能性はかなり低いと思います。Judyのような「キャッ
シュラインを意識した高速でHashっぽいライブラリ」というのは存
在しますが、JudyはHashではありませんし。
まつもと ゆきひろ /:|)