[Tokyo-pm] Re: これはどう動くの？

[Shinya Hayakawa]

こんにちは。早川です。

On 2004 8月 27 金曜日 12:41 午前, Dan Kogai wrote:
> それにしても早川君って「モツ好き」だよなあ....

モツ?...あぁ、gutsってことですね(^^;

> > my 変数と同様に、参照カウントを増やすことで
> > スコープを抜けた後も、中身が解放されない事を利用してます。
>
> え？この場合は、REFCNTは関係ないはず。以下を実行してみて実際のref countを確認してみてください。
>
> perl -MDevel::Peek -le '@a=qw/a b c/; sub a{ \@_ }; $b=a(@a);Dump $b'
>
> $b のREFCNTは1のまま。@$bのREFCNTも1のまま。というか1で充分。

いえ、Dumpする場所を追加すると,
perl -MDevel::Peek -le '@a=qw/a b c/; sub a{Dump \@_; \@_ }; $b=a(@a);Dump $b'
REFCNTは3に増えている事が分かります。

@_ 自身はスクラッチパッド上に確保されるので
保存の仕組みはクロージャと全く同じですよね。

> ＃ただし、$b->[]の各要素のSVのref countは１づつ上がる。
> ＃うむむ、むしろこちらの方が不(思議|可解)だ！

引数スタックに積まれる時にcountが上がるのでしたっけ。
後で調べてみます。

> 特にコワいのは、
>
> substr(shift,0,-1), @_;
>
> では同一statementで@_の内容を変更していること。shiftと@_とどっちが先に評価されるかというのはCでは未定義なんだよね(K&R
> pp.
> 52)。perlでも明示的に定義はしてなかったように思うが、今のところどのplatformでもshiftの方が先に評価されるみたい。だけどCは
> そうは行かない。

あっ、でも自分の場合は@_のリファレンスを使ってるだけだから
shiftが実行されるのは先でも後でも問題なかったですね。
-- 今気づいた(^^;


-- 
Shinya Hayakawa
hayakawa at livedoor.jp