[#34011] Should --verbose be equal to -v ? — Yugui <yugui@...>

Yuguiです。

15 messages 2008/03/10
[#34012] Re: Should --verbose be equal to -v ? — Yukihiro Matsumoto <matz@...> 2008/03/10

まつもと ゆきひろです

[#34105] rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...>

rational と complex が組み込みになったことで、lib/mathn.rb の意義は薄

29 messages 2008/03/22
[#34106] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

現時点で rational.rb と complex.rb を残しているのは、それが無難だから

[#34107] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/22

で、かなり選択肢を絞った叩き台です。

[#34120] Re: rational.rb, complex.rb and mathn.rb — keiju@... (石塚圭樹) 2008/03/24

けいじゅ@いしつかです.

[#34125] Re: rational.rb, complex.rb and mathn.rb — Shin-ichiro HARA <sinara@...> 2008/03/25

原です。

[#34130] Re: rational.rb, complex.rb and mathn.rb — Tadayoshi Funaba <tadf@...> 2008/03/25

> 私も Complex の組み込みは Rational とは比較にならないくらい、仕様が決め

[#34158] Complex組み込み — Masahiro TANAKA <masa16.tanaka@...>

Complexが組み込みになるそうですが、これはcomplex.rbを踏襲して、

49 messages 2008/03/27
[#34161] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/28

原です。

[#34168] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> 今までの Complex は、complex.rb にほぼ残して、たとえば Rational 成分

[#34186] Re: Complex組み込み — Shin-ichiro HARA <sinara@...> 2008/03/31

原です。

[#34187] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/31

> そうです。Complex が難しい、という話を書いておくと、

[#34193] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/03/31

まつもと ゆきひろです

[#34203] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/04/01

> |僕としては、/ 演算子の振舞いについて前向きに検討してほしいです。

[#34215] Re: Complex組み込み — Yukihiro Matsumoto <matz@...> 2008/04/02

まつもと ゆきひろです

[#34166] Re: Complex組み込み — Tadayoshi Funaba <tadf@...> 2008/03/28

> となるようですが、別の実装として、

[ruby-dev:34065] Re: ruby coding guideline

From: "NARUSE, Yui" <naruse@...>
Date: 2008-03-15 22:07:36 UTC
List: ruby-dev #34065
成瀬です。

U.Nakamura wrote:
> こんにちは、なかむら(う)です。
> 
> In message "[ruby-dev:34033] ruby coding guideline"
>     on Mar.13,2008 19:40:42, <naruse@airemix.com> wrote:
> | * long == pointer 前提不可 (LLP64等 (Win64))
> (中略)
> | * long はポインタと演算を行う整数で用いる
> 
> いきなり矛盾してますよぅ。
> 
> trunk前提だと、SIGNED_VALUEを使ってください、が答えになりそう
> です。
> 
> なお、1.8ではlong == pointerを前提にしてよくなります、というか、
> そうでないプラットフォームはサポートしていません。

この部分は問題提起に枕のつもりでした。
つまり、わたしの読み取った限りでは、long はポインタとの演算用として
用いられているのに、LLP64 があるために破綻していると。

なお、実際の例として、String や Array の長さや添え字、
加えて Fixnum が long ベースですね。

[ruby-dev:29024] Fixnum on IL32LLP64 では long のサイズが
ポインタよりも小さい環境での悲哀が語られています。
Fixnum のベースを SIGNED_VALUE に切り替える案がでましたが、
結局ここではいくつかの問題によってとん挫しています。

具体的には、[ruby-dev:29054] にありますが、SIGNED_VALUE に切り替えた場合、
* FIX2xxx の名前
* printf で Fixnum の数値を出力したい場合、書式指定子がアーキテクチャ依存
* 変更が複雑
あたりがネックになったようです。

さて、より楽な代案として、SIGNED_VALUE の代わりに intptr_t を使うのはどうでしょう。
名前は FIX2INTPTR なり FIX2PTR でいいでしょうし、
書式指定子は %"PRIdPTR" が C99 で標準化されています。
(intmax_t に対応する %j か %"PRIdMAX" で代替もいいかも)

また、変更は long を intptr_t に置き換えるだけです。
なにより、1.8 時代での long == pointer の仮定を、
仕様から常に成り立つ intptr_t == pointer に移して続行できるのは楽でしょう。
さらに、SIGNED_VALUE と違って C99 で標準化されている型なので、
エディタ等の支援も多少期待できるかもしれません。

> あと、私が知っていて既に誰かが踏んだことがある問題としては、
> 
> * 配列を負のインデックスでアクセスするのは不可(C規格でも未定
>   義動作)
> 
> というのがありますね。

なるほど、負が絡むものだと、負の値の右シフトとかも実装依存でしたね。

-- 
NARUSE, Yui  <naruse@airemix.com>
DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA


In This Thread

Prev Next