スレッドメモ

◆ [XP-jp] エクストリーム・トレーニング

[4791] Y.Terada (1/5)

正月休の間，コタツで寝ながらミョーなことを考えていました． その名も「エクストリーム・トレーニング」です(^^;

要領が悪い私にはなかなかXPが難しいので，自分の脳をXP脳とかTDD脳に作り変 えるためのトレーニング方法があれば良いのにな，と妄想したものです． その名のとおり「極端な」トレーニング方法です．

味も素っ気もないホームページを作りまして，
→ http://www.geocities.jp/u_1roh/

その中にそのアイデアを書いてみました．
→ http://www.geocities.jp/u_1roh/columns/training.html

[4792] Narushima Hironori (1/5)

ある程度の「型」はXPのプラクティス自体が提供していると思います。それ以上の型を当てはめて、それが有用なら、それは大きな発見だと思いますが、その型の発見は難しいと思います。

[4795] Y.Terada (1/5)

私のイメージする「型」というのは単なるパターンとは違うんです．ですから，プログラミングのスタイルを単純なパターンに押し込めようという意図ではないのです．むしろ，Narushima さんが仰るような

「その場その場で違う」「それぞれのシーンによって違う」

という微妙なニュアンスを（も）身に付けられるようなトレーニング法を目標としています．

[4796] U Okumura (1/6)

拳法なら正拳突きに始まって演舞、とか楽器ならドミレファミソ...なんかの演習フレーズに始まってトッカータ,とかそんな感じで

「よし、じゃあ今日もまずはMoney.amount制作TDDサイクル50回！」

とか

「だいぶ覚えてきたからMoney演TDDを通して覚えてみるか」

とかやるわけですね?

[4798] t-ushio (1/6)

　余談ですが、私は昔、暇なときにやってたことには、「とことんまで○○する」というのがありました。

　例えば、モデリングをやっているときに、とことんクラスわけまくってみるとか、とことん抽象化してみるとか、とことん満足するまでリファクタリングしてみるとか（リファクタリングの本を片手に）、徹底的にテストファーストしてみる。とかです。

[4800] 石井 勝 (1/6)

ちゃんと読んでないのですが（すみません），こんなサイトがあるので参考にされてみてはいかがでしょう．

Code Kata
http://pragprog.com/pragdave/Practices/Kata

Kataは空手の型のことらしいです．

[4804] Y.Terada (1/6)

おお！

同じことを考える人っているんですね！

　　ミュージシャンもスポーツ選手も裏では多くの練習をこなしているのに，プロ
　　グラマーは全然練習していない．だから実戦で（実プロジェクトで）失敗する
　　んだ．プログラマももっと練習するべし．

と書いてありますね．

[4805] HIRANABE Kenji (1/6)

ちょっと外れますが、例えばクラシックピアノには、ある程度定型化された（よく認知された）練習方法ってありますよね、バイエルとか。また、クラシックギターなどにも、メソッド、と呼ばれる教育方法があります。

型は、こういうのに近いのかなー、と考えました。

[4807] Satoshi Sawada (1/6)

音楽やスポーツの練習は、体を動かすための神経回路を作ることが目的ですね。考えなくても体が動くようにするための。

これに対して、Code Kata はソフトウェア的な問題解決を早くするための頭のトレーニングって感じでしょうね。算数でいうところの九九だとか物理などの公式に近いように思います。

[4946] Y.Terada (3/12)

以前このMLで話題に出した「エクストリーム・トレーニング」ですが，やっと「型」（練習メニュー）の第一弾を公開しました！ なかなか忙しくて時間が取れなかったことと，予想通り（？）型の作成は困難であったため，ずいぶんと時間がかかってしまいました．

私のページ（ここから辿れます）
http://www.geocities.jp/u_1roh/

◆ [fj][fj.comp.lang.c] [Q] see return value (strncpy)

<YAS.04Jan9214824@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (1/9)

バッファ・オーバーフローを防ぐには、strncpy() は実は今一つで す。n を取りますが、最後に埋めるだけなので。結構、誤用される 関数だと思います。私もだいぶ長い間誤用していた気がします。

本当は、strlcpy() がいいんですよね。

ただ、strlcpy() は、Linux に入ってなくて困るんですよね。しょ うがないので代りに snprintf() を使うように勧めているんですけ ど。いくら snprintf() を使えと言っても、strcpy() とか strcat() 使う人が多くて困ります。どうしたらいいでしょうか。

<bto666$e39$2@caraway.media.kyoto-u.ac.jp> NIDE Naoyuki (1/10)

そういう場合は、strlcpy()互換品を作ってプログラムに添付しておいて、Linuxで使う場合はそれがリンクされるようにしておくのがよくある手ですよね。1度作っておけば以後使い回しもできるし。snprintf()だと(マニュアル見ても難しそうなので?)使ってくれない人も、strlcpy()だと(慣れているstrncpy()に似ているからと)使ってくれませんかね。

<m3ad4wl1yq.fsf@kzin.dip.jp> Mito (1/10)

すみません、もう少し詳しく教えてください。この文は、

strncpy(dest, src, n) は n > strlen(src) の場合に dest+strlen(src) 以降に nul を埋めるだけで、 strlcpy の場合はこれに加え、n <= strlen(src) の場合も dest+n に nul を埋めるので、バッファ・オーバーフローを防ぐ には strlcpy のほうがベターである

ということをおっしゃっているのでしょうか？

私は strcpy や strcat を好んで使いますし、これからも使ってい くと思います。strncpy などは n なしに比べてだいぶ遅いんです もん。

<YAS.04Jan12063406@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (1/12)

strncpy() は、0 を埋めるので遅いけど、strlcpy() は埋めないので速い。

<m34quy63bi.fsf@kzin.dip.jp> Mito (1/14)

とにかく、strlcpy() は strncpy() と違い、n 未満の文字列をコ ピーする場合も、dst[n] まで nul を埋めることはしないというこ とはわかりましたし、strlcpy() があるなら使うべきで、ない環境 でもある程度以上の規模のソフトを作るなら自前のものを用意して 使うべきだという意見にも同意します。

新城さんの考えは、たとえ strcpy の正しい使いかたを知ったとし ても使うべきではない、というふうに思われるのですが、もしそう なら理由を教えてもらえませんか？

私は正しい使いかたを知っていれば別に使ってはいけない関数では ないと思うのです。

<YAS.04Jan16033731@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (1/16)

strcpy() を使った方がよい局面というのが、なかなか出てこない ので、「strcpy()使うな」でいいんじゃないか、ということです。 何か「こういう時には strcpy() がいい」という状況はありますか？

<c17e5u$2eji$1@news2.rim.or.jp> Kazuo Fox DOHZONO (2/21)

# 今更感バリバリですが, 先の記事を読んで何も考えずに strcpy を strlcpy
# にする人がいるといけないと思って色々書いてみました. 意見を求めます.

どうも私の感覚と strlcpy って合いません. 特に strcpy の置き換えとしては考えられない.

マズイことの本質は「不適当な大きさのバッファを適当に取ってしまうこと」だと思うんです. 長さのチェックは入力時や文字列の切り出し時にやればいいわけで, *cpy なんかする前にわかるでしょ? ということ.

そもそもこれで足りなくなる場合はバグ (バッファ長不足) か仕様外の入力かのどちらかで, バグなら strlcpy を使ってもバッファを定められた長さまで増やさなければ正しく動作しないでしょうし, 仕様外の入力がこういうところにまで入り込んでくるのなら, そもそも strcpy を使える場面ではなかったわけです. 後者を問題にするのなら, 別の問題も抱え込んでいる可能性が大きい.

<YAS.04Feb21235337@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (2/21)

はい。それはそうです。strlcpy() は、バッファ・オーバーフロー を起さないという目的で使うものです。strlcpy() を使ったからと いって、間違ったプログラムが「正しく」動作するようになるわけ ではありません。

<c1fl9o$dl5$1@news2.rim.or.jp> Kazuo Fox DOHZONO (2/24)

確認しておきますが, strlcpy によってバッファオーバーフローが「起こらなくなる」ケースでは間違ったプログラムを前提としているわけであり, それは strlcpy を使っても依然として間違ったプログラムであることに変わりありません.

人的ミスならそういうものを持ち込ませない, 或は, 万が一持ち込まれてもテスト等で発覚するような設計にするべきで (Java を使うってのもこの辺に入ってくるわけでしょう), 「持ち込まれても strlcpy で」っていうのは問題に対処するベクトルがずれている気がするんです. 新人君に教える心得としても甚だ不適当なものでしょう.

<YAS.04Feb25010034@kirk.is.tsukuba.ac.jp> Yasushi Shinjo (2/25)

それより重要なことは、間違いには２種類あるということです。

（Ａ）セキュリティ上の弱点に繋がる間違い
（Ｂ）セキュリティ上の弱点には繋がらない間違い

strlcpy() を使うと、（Ａ）は出てきません。この性質を有りがた いと思う人は、多いでしょう。

最後の部分、同意できませんね。人間は間違う、だから、間違ったとしても安全側に倒れるように作るようにプログラムは作るべしと。

<c2esvq$2ta5$1@nsvn01.zaq.ne.jp> Takashi SHIRAI (3/7)

　この過ちを侵している代表例が Samba ですね。こいつは一つも strcpy() を使わないように工夫していますが、長さ指定ミスによ る buffer overflow は過去幾つも発見されています。

　開発チームは strcpy() を使っていないことから慢心してしまい、 文字列 copy に関するチェックを疎かにしているため、新たに何か 実装する度にこのミスが生じ、結果 buffer overflow は後を絶ち ません。

私は fgets() の代わりに asprintf() みたい な仕組みを実装することが多いですね。

◆ [fj][fj.news.policy] Re: 選管活動方針叩き台（問題把握・解決に向けて）

<btoumr$9ogc9$1@ID-123361.news.uni-berlin.de> kunihito takaYASHIKI (1/10)

ところで、fjvvですが、すでに休眠状態ではありますけど、ある事情から、私としては再開は非常に難しいのではないかと考えています。どうしたものか。

<btp8kh$avj$1@caraway.media.kyoto-u.ac.jp> MATSUMIYA Yoshihiko (1/11)

fjvv としてではなく, script を公開して誰か有志に投票サーバを運用してもらう, とかですか? script の著作権者がいいと言えば, それも可能ですよね.

公開が難しいとして, 似たようなものなら作れますから, 需要がある程度見込めるなら, フルスクラッチで書き起こしても良いのですけれどね.

<bu7v1h$duooj$1@ID-37799.news.uni-berlin.de> shuji matsuda (1/16)

これなんですが、おっしゃることは分かりますが、方法は二つあると思います。

（１）どうせ、サーバーを管理する人しかサービスを提供してくれない訳だから（つまり、松宮さんのこと）fjvvになってもらって、スクリプトを共有する。働かない人に渡しても仕方が無い、という考えですね。

（２）fj.news.policyで苦情が出るかどうかをみた上で、あっさり公開する。こちらは、久野さんに責任をとってもらう（どういう責任だ？（笑））という考えです。

<bu95o4$93n$1@caraway.media.kyoto-u.ac.jp> MATSUMIYA Yoshihiko (1/17)

松宮さん、どうしますか？

どうしますか, というのは, 新しくプログラムを書くか? ということでしょうか?

繰り返しになりますけど, 需要があるなら書いてもいいです.

<bu98f3$eimun$1@ID-37799.news.uni-berlin.de> shuji matsuda (1/17)

いや、それは無駄なので。プログラムを渡して、必要ならdebugの上で、実際に稼動させてもらえるのか？という意味です。

<bu99up$ciq$1@caraway.media.kyoto-u.ac.jp> MATSUMIYA Yoshihiko (1/17)

そういう意味ならば, 肯定です.

<bu9dhb$f7acb$1@ID-37799.news.uni-berlin.de> shuji matsuda (1/17)

じゃ、高屋敷さんを含めて異議がなければ、（異義ではない）送ります。よろしいですね？

<bu9v0f$hmj@utogw.gssm.otsuka.tsukuba.ac.jp> kuno (1/17)

それはいいんだけど。どういう条件で使ってもらうとかいう相談は済んでるんでしょうか、または松宮さんがfjvvに入るのか。どういう位置付けなのかよく見えないんで教えてくれませんか。

あとフリーで公開の方はしないという結論なの? 久野

<bubcef$fjtlg$1@ID-37799.news.uni-berlin.de> shuji matsuda (1/17)

こっちは、松宮さんの実績を見て考えるということで。

私は、江戸っ子じゃないので、気は長い（笑）。

◆ [XP-jp] JaSST'04

[04846] FUKUDA Fumiki (1/30)

>あと、SandBoxな話でJavaのメモリ管理が見えないということの弊害
>についてもお伺いしましたっけ。

そゆのもあったですね。JavaはGC持ってるからメモリ・リークがない、 なんて考えてたら大間違いで、誰かが捕まえて離さないとぢわぢわメモリ を食い潰し…てな事態は決してレア・ケースじゃない。C++はGCの持ち合わせ はないけれど、new/deleteを差し替えられるから取得/解放のログみたいなの を取るとか、取得失敗にみせかけることだってできる…とかなんとか

[04847] Kenji HIRANABE (1/30)

便乗質問。（最近C++から離れているもので。。。）

new/delete の置き換えによって、GCを実現できるのでしょうか？そういう、ライブラリあるのですかね？

あと、そのライブラリに置き換えてリンクするだけで、既存コードをまったくいじらなくて（再コンパイルもなし）GC対応ってできるのでしょうか？

[04848] FUKUDA Fumiki (1/30)

なにやらできるみたいですよん。

http://www.hpl.hp.com/personal/Hans_Boehm/gc/index.html

[04849] Shibukawa Yoshiki (1/30)

newで作ったオブジェクトのポインタをstd::auto_ptrとかboost::shared_ptrとかのスマートポインタで受け取るようにすれば、参照カウント式のGCができます。簡易的ですが。マーク＆スイープ方式のようにメモリ空間を探索する手間がなくて、パフォーマンス劣化も少ないのでC++向きかと思います。

[04852] Murayama Toshikiyo (1/30)

C++で保守的GCが使われるのは，言語の制約で，こういうのくらいしか使えるGCがないためです．

[04856] Shibukawa Yoshiki (1/31)

Cでも型情報を持っていて色々やるコードというのはあります。SWIGなんかもそうです。SWIGの場合はスクリプト言語とC/C++コードのコミュニケーションのために持っているのであってGCのためではないですけど。あとはスマートポインタの類も型情報を持っているからこそ参照カウントで消せるといえると思います。

[04866] Murayama Toshikiyo (2/2)

「型情報を手作業で付けることができる」というだけでしょ？Cのランタイムにはそういう機能はありません．

[04867] Shibukawa Yoshiki (2/2)

JavaのC++に対するメリットって「リッチな中間層」で提供されているものですよね。中間層を増やして柔軟性と機能を追加していくのがソフトウェアの基本的性質なら、C++はパフォーマンスのためにあえてその辺りを全部とっぱらった言語と言えます。

exact GCだって、newしたオブジェクトを全部shared_ptrに格納すればできるんですから。タイプ数はちょっと多くなりますけど。

[04873] Susumu YAMAZAKI (2/2)

言語処理系レベルの最適化ということを考えますと，必ずしも C++ 流の方法が性能がよいとは一概には言えません．全部 shared_ptr を使った C++ と，Java とでは，恐らく Java の方が性能がよいでしょう．Java はメモリモデルが単純で GC が全てで使われるため，最適化の効果が高く最適化の前提条件が立てやすいので，研究が進んだ結果だと言えます．

[04883] UEHARA Junji (2/4)

いっそ、生ポインタを使えない制約と、Objectを自動的に継承するようにサポートするなどの記法（一種の言語のようなもの）を決めて、その記法を通常のC++コードに変換するツール（プリプロセッサ）を作ったらどうでしょう。そうだ、いっそ、その記法として「Java」を採用したらよろしいのでは。当然GC等もサポートします。

# 皮肉です。念のため。