[#43284] [Ruby 1.9 - Bug #4456] [Open] Time#strftime で %F 指定子に大きな幅を指定した際の不具合 — tadayoshi funaba <redmine@...>

14 messages 2011/03/02

[#43317] [Ruby 1.9 - Bug #4474][Open] 複数のスレッドからトランザクションに入ろうとした場合のPStoreの挙動 — Masaki Matsushita <redmine@...>

9 messages 2011/03/06

[#43327] [Ruby 1.9 - Feature #4483][Open] PStoreをデフォルトで複数のスレッドから扱えるようにしたい — Masaki Matsushita <redmine@...>

10 messages 2011/03/08

[#43365] [Ruby 1.9 - Bug #4536][Open] 定数参照について1.8と1.9の違い — Yukihiro Matsumoto <matz@...>

11 messages 2011/03/29

[ruby-dev:43363] Re: [Ruby 1.9 - Feature #4529][Rejected] date_core と long 型

From: "NARUSE, Yui" <naruse@...>
Date: 2011-03-26 22:24:33 UTC
List: ruby-dev #43363
(2011/03/26 21:40), Tadayoshi Funaba wrote:
>> 大きなユリウス日を将来的に扱えるようにしたいという話は理解できます。
>> で、ならば long ではなく int64_t を使った方がよいのではないかと。
>> long だと 32bit 環境はもちろん、LLP64 な環境 (64bit Windows) で残念なことになるので。
> 
> 特に 64bit 欲しいわけではなく、比較的小さい値に留まる年と、大きな数にな
> る可能性のあるユリウス日を考慮して、最終的に表現されうる上限が、long で
> 表現できるのユリウス日か、int で現わされる年の大晦日かのどちらか小さい
> ほうになることを想定しているだけですね。

ここでユリウス日を long にしているのはなぜか、という話です。

long は int より大きいわけですが、どういう時に大きいかはその環境の趣味で決まっています。
多くの Unix 系 64bit 環境では long は 64bit になりましたが、
mswin64 ではおそらくソース互換性のため 32bit のままです。
つまり、基本 32bit だけど 64bit が速い時は 64bit にしたいと言う場合には不適で、
たぶんそういう場合には intptr_t の方が意図に近いでしょう。

もっとも、そもそも Ruby よりも C で実装した方が速いのですから、
常に int64_t にした方がいいのではなかろうかとか。

> これがダメなら C 自体がダメだというしかないと思います。

C 自体がダメだという主張は含意していますが、
C でもポータブルに書こうと思えば書けますからね。

> そもそもこういう
> 運動みたいなのは、一面的になりがちで、

longは避けるべきという話は、「こういう運動」が指していると思われるwarning消し
とは別の話で、可搬性の話です。

> この間の成瀬さんの修正は、汎用的
> に利用される可能性のあるマクロで型変換を強制していたりして、何を表現し
> ようとしているのか全く考えられていないものだったと思います。

マクロへの修正がまずいと言う指摘は仰るとおりだと思います。

> そういう事で疑念もありますが、間違ってるところがあれば、それは直しても
> らっていいと思います。しかし、long を使うなってのはよくわかりません。

long を使うなという点は合意頂けてないので勝手に入れないとして、
とりあえず y は int、jd と offset は long ってことでいいのでしょうか。

-- 
NARUSE, Yui  <naruse@airemix.jp>

In This Thread