WEB+DB PRESS Vol. 51に「バッドシグナル通信」の第2回「相性の問題」という記事を書きました。「相性の問題」のありがちなパターンと対策について考察しています。
]]>
WEB+DB PRESS Vol. 51に「バッドシグナル通信」の第2回「相性の問題」という記事を書きました。「相性の問題」のありがちなパターンと対策について考察しています。
]]>
WEB+DB PRESS Vol. 50から「バッドシグナル通信」という連載を始めました。第1回のテーマは「歴史的理由」です。
]]>
バッドシグナルの紹介を、本文から引用しておきます。
ソフトウェア開発を行っていると、「何かいやな予感がするなー」と直感が働いて、それが的中することがままあります。いやな予感には何かしらの原因があり、そこから発せられる危険信号を人は読み取っているのではないかと思います。
筆者の周りではこの危険信号を、バッドであることが予想されるシグナルという意味で、「バッドシグナル」と呼んでいます。筆者はこの言葉を使い始めてからは、いやな予感がするきは「このバッドシグナルは何だ？」と考えるようになり、いやな予感の原因を特定する習慣がつきました。
ちなみに、前号まで連載していたBK通信は gihyo.jp で読めます。最終回の「文字コードのバッドノウハウ」もしばらくすると掲載されると思います。その前の連載のプログラミングの光景は全記事が掲載されています。
]]>
『マッキントッシュ物語 - 僕らを変えたコンピュータ』を読みました。
]]>
本書は、初代マッキントッシュ誕生とその後の数年の物語を関係者へのインタビューを元に再現したノンフィクションです。スティーブン・レヴィ氏の他の著作と同様に、インタビューは入念、ドラマ性たっぷり、ゴシップは多め、と期待通りの一冊でした。
物語にはスティーブ・ジョブズは当然として、ビル・アトキンソンやアンディ・ハーツフェルド、ジェフ・ラスキンなどの開発者も多数登場します。ジョブズは「現実ゆがみフィールド」を持ったカリスマとして頻繁に登場しますが、奮闘する開発者たちも負けず劣らず重要な役割を果たしています。
第一章は、著者とマックの出会いから始まります。1983年11月、ジャーナリストである著者はアップル本社を訪れ、発表前のマックのデモを目にします。即座に「目の前で改革が起こっている」ことを理解し、マックの記事を書くことを決意します。このときのスティーブ・ジョブズは意気揚々、まさに自信の塊です。
ジョブズとのインタビューが終わると、打って変わって 1945年に発表された風変わりなエッセイ「科学技術の今後の動向」（原題は As We May Think）の話題に移ります。バニーバー・ブッシュ氏によるこのエッセイの中には 1945 年に書かれたとは思えない、コンピュータの革新的な将来像が予言されています。
このエッセイは後に、ダグラス・エンゲルバート氏によるマウスとウィンドウの発明につながり、さらにこのビジョンはゼロックスPARCの研究者たちによって磨きがかけられます。これらの成果をベースとして誕生したのがアップルのリサ、そしてマッキントッシュです。2章から5章にかけて、マッキントッシュに至るまでのこういった過程を源流から丹念に辿っていきます
長い前置きが終わると、いよいよマッキントッシュの開発の物語に入ります。開発は最後の最後までめちゃめちゃ難航して、開発者の多くは完成後に燃え尽きてしまいます。
ともあれ、すったもんだの末にようやく1984年1月に発表。しかし、メモリが少なすぎるため事実上使い物にならず（フロッピーディスクを1枚コピーするのにディスクの交換が50回以上必要だった！）、さらにカーソルキーがないといった問題もあって予想よりぜんぜん売れず、絶望的なムードに落ちていきます。
結局、スティーブ・ジョブズはマック発表の翌年 1985年5月に追い出されるはめになります。その後もいろいろあって、マックは結局これからどうなるんだろう、という 93年の時点で本書は終わります。
マックを使い始めたのは比較的最近ということもあって、マックの歴史への関心はあまりなかったのですが、本書は非常に楽しめました。序盤を読んでいるうちは、著者のマックへの思い入れが強すぎるんじゃないのと感じる部分もありましたが、途中からは自分もすっかり思い入れが強くなってきて、著者と一緒になってマック開発チームを応援するモードになっていました。絶版となっているのが残念な一冊です（熱い復刊要望文があります）。
ところで、同様の開発物語では Windows NT をテーマとした『闘うプログラマー』もかなりおもしろいです。残念ながら、『こちらも絶版になっているようです（こちらの中古は豊富にあるようですが）。次は『レボリューション・イン・ザ・バレー』を読んでみようと思います。
p.s.
最後の章で出てきた「自分のマックが調子悪いので調べたところ、オンロケーションという常駐ソフトが ワード 5.1に付属する『雇用報告書』というファイルと相性が悪いことが判明して、こいつを削除したら解決した」というどうでもいいようなエピソードがつぼに入りました。まさにBKです。
最近になって GNU diff の地味だけど便利な機能を2つ知りました。調べてみると、いずれも昔からある機能でした。
]]>
--side-by-side は2段組で結果を表示するオプションです。変更されていない行を含めて2つのファイルの内容全体と変更点が表示されるのがポイントです。変更された行の前後数行だけでなくファイル全体をまとめて読みたいときに使えます。デフォルトの表示の横幅は130文字です。必要に応じて --width オプションで変更できます。
こういった用途には meld などの GUI の diff ツールを使えばいいのですが、 ssh 端末しかないような状況で重宝します。
--strip-trailing-cr は行末の CR を無視する機能です。改行コードが CRLF と LF で食い違っているけど、中身はほぼ同じ、というファイルを比較するときに使えます。
以上、GNU diff の地味だけど便利な機能でした。
]]>
WEB+DB PRESS Vol. 49に「BK通信」の第6回「文字コードのバッドノウハウ」を書きました。今回がBK通信の最終回です。文字コードは最終回にふさわしい、永遠の BKテーマではないかと思います。
]]>
C++ の string と vector には前もって容量を確保するための reserve() というメンバ関数があります。何気なく使っていた関数ですが最近になって興味深い挙動に気づきました。
]]>
reserve() の基本
string と vector の reserve() は前もって容量 (capacity) を確保しておくためのメンバ関数です。前もって容量を確保 (reserve) しておけば、データの追加時に発生する再割り当て (reallocation) を防ぐことができ、効率的です。
たとえば、何もしないで文字列に 1,000文字追加した場合、（内部的に倍々で容量を増やしていくため）10回程度の再割り当てが発生しますが、 s.reserve(1000) のように容量を確保しておけば 1回の割り当て (allocation) だけで済みます。
以下は Mac OS X 10.5 の gcc version 4.0.1 (Apple Inc. build 5465) での実行結果です。
% cat reserve0.cc
#include <string>
const int N = 1000;
int main() {
std::string s;
for (int i = 0; i < N; ++i) {
s.append("a");
}
return 0;
}
% g++ -g reserve0.cc
% gdb ./a.out
(gdb) start
...
Breakpoint 1, main () at reserve0.cc:5
5 std::string s;
(gdb) b malloc
Breakpoint 2 at 0x954f825b
(gdb) c
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 1回
(gdb) bt
#0 0x954f825b in malloc ()
#1 0x97009598 in operator new ()
#2 0x96ff0fd2 in std::string::_Rep::_S_create ()
#3 0x96ff129a in std::string::_Rep::_M_clone ()
#4 0x96ff2a8f in std::string::reserve ()
#5 0x96ff2d21 in std::string::append ()
#6 0x96ff2da5 in std::string::append ()
#7 0x00001f61 in main () at reserve0.cc:7
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 2回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 3回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 4回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 5回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 6回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 7回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 8回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 9回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 10回
(gdb)
Continuing.
Breakpoint 2, 0x954f825b in malloc () ← 11回
(gdb)
Continuing.
Program exited normally.
(gdb)
たしかに 10回ほどの再割り当てが行われていることが確認できました。再割り当て時には元の領域から新しい領域への文字列のコピーも行われます。
% cat reserve1.cc
#include <string>
const int N = 1000;
int main() {
std::string s;
s.reserve(N);
for (int i = 0; i < N; ++i) {
s.append("a");
}
return 0;
}
% g++ -g reserve1.cc
% gdb ./a.out
(gdb) start
...
Breakpoint 1, main () at reserve1.cc:6
6 s.reserve(N);
(gdb) b malloc
Breakpoint 2 at 0x954f825b
(gdb) c
Continuing.
Breakpoint 2, 0x954f825b in malloc () ←1回
(gdb) bt
#0 0x954f825b in malloc ()
#1 0x97009598 in operator new ()
#2 0x96ff0fd2 in std::string::_Rep::_S_create ()
#3 0x96ff129a in std::string::_Rep::_M_clone ()
#4 0x96ff2a8f in std::string::reserve ()
#5 0x00001f42 in main () at reserve1.cc:6
(gdb) c
Continuing.
Program exited normally.
(gdb)
reserve() すると確かに 1回だけの割り当てで済むことが確認できました。
それでは reserve() を間違って使うとどうなるでしょうか。以下のコードではループの中で、現在のサイズ + 1 を reserve しています。
% cat reserve2.cc
#include <string>
const int N = 1000;
int main() {
std::string s;
for (int i = 0; i < N; ++i) {
s.reserve(s.size() + 1);
s.append("a");
}
return 0;
}
これをさきほどと同じようにデバッガで追いかけると 1,000回もの再割り当てが起きることがわかります。毎回文字列のコピーが行われていることを考えると、これは O(n^2) の計算量になります。実際、 N の数を 100000 くらいに増やすと、プログラムが終了するまでに 7秒もかかりました。
さきほどのプログラムの挙動をもう少し追ってみると、容量の増え方が予想外の動きをしていることがわかりました。以下のコードでは reserve() の直後に容量を表示しています。
% cat reserve3.cc
#include <string>
#include <iostream>
const int N = 1000;
int main() {
std::string s;
for (int i = 0; i < N; ++i) {
s.reserve(s.size() + 1);
std::cout << s.capacity() << " ";
s.append("a");
}
return 0;
}
% g++ -g reserve3.cc
% ./a.out
1 2 4 4 8 6 12 8 16 10 20 12 24 14 28 16 32 ... 1988 996 1992 998 1996 1000
このように、容量が 1 2 4 4 8 6 12 8 16 10 20 12 24 14 28 ... のように増えたり減ったりしていることがわかりました。増えるだけで減ることはないと思っていたので、意外でした。2倍に増えたかと思えばまたすぐに小さくなっています。なぜこんな挙動をするのでしょうか。
謎を調べるため、デバッガで追ってみることにします。 Mac OS X の場合 /usr/lib/libstdc++-static.a にデバッグ情報つきの C++ のライブラリがあるので、これを使います。これを使うには g++ に -lstdc++-static を渡す必要があります。
% g++ -g -lstdc++-static reserve3.cc
% gdb ./a.out
(gdb) start
Breakpoint 1 at 0x3c400: file reserve3.cc, line 6.
...
Breakpoint 1, main () at reserve3.cc:6
6 std::string s;
(gdb) n
7 for (int i = 0; i < N; ++i) {
(gdb) n
8 s.reserve(s.size() + 1);
(gdb) s
std::string::size (this=0xbffff578) at bits/basic_string.h:584
584 bits/basic_string.h: No such file or directory.
in bits/basic_string.h
おっと、ソースコードが見当たらないといって怒られてしまいました。こういうときは dir コマンドでソースコードの場所を教えてあげれば OK です。
(gdb) dir /usr/include/c++/4.0.0/bits
Source directories searched: /usr/include/c++/4.0.0/bits:$cdir:$cwd
(gdb) s
585 { return _M_rep()->_M_length; }
が、デバッガで追いかけるより basic_string.h を直接読んだほうが早そうなので、そうすることにします。ざーっと読んでいくと basic_string.tcc の次のコードにたどり着きます。reserve() から間接的に呼ばれている _S_create() という関数内です。
// The below implements an exponential growth policy, necessary to
// meet amortized linear time requirements of the library: see
// http://gcc.gnu.org/ml/libstdc++/2001-07/msg00085.html.
// It's active for allocations requiring an amount of memory above
// system pagesize. This is consistent with the requirements of the
// standard: http://gcc.gnu.org/ml/libstdc++/2001-07/msg00130.html
if (__capacity > __old_capacity && __capacity < 2 * __old_capacity)
__capacity = 2 * __old_capacity;
コメントには「ここでは償却線形時間要求を満たすために指数的な成長ポリシーを実装する」といった旨のことが書かれています。コードの方を見ると、「指定された新しい容量が現在よりも大きく、かつ、現在より2倍未満の場合は、新しい容量を現在の２倍にする」という処理が行われています。
文字列追加のために「指数的な成長ポリシー」が必要なことはわかりますが、reserve() したときに行わなくてもいいような気がします。
ともあれ、これで、現在の容量に 1しか足していないのに、容量が2倍になる謎が解けました。では減るほうはどうでしょうか。SGI の string のマニュアルを読むと次のように書かれています (C++ の仕様書は確認していません)。
Requests that the string's capacity be changed; the postcondition for this member function is that, after it is called, capacity() >= n. You may request that a string decrease its capacity by calling reserve() with an argument less than the current capacity. (If you call reserve() with an argument less than the string's size, however, the capacity will only be reduced to size(). A string's size can never be greater than its capacity.) reserve() throws length_error if n > max_size().
太字のところに「現在の容量 (capacity) よりも小さい値で reserve() を呼ぶことで、容量を減らすことができる 」と書かれています。つまり、string の reserve() で容量を減らせるのは仕様です。
というわけで、「指数的な成長ポリシー」と「現在の容量より減らせる」の2つが組み合わせると、容量が増えたり減ったりするという挙動が説明できます。
上のような一目で非効率とわかるコードを書くことはないと思いますが、複雑なコードでは reserve() の呼び出しが思わぬところに埋もれている可能性があるので注意が必要です。せっかく前もって適切に reserve() していても、処理の途中で余計な reserve() が入ってしまったら台無しになります。
たとえば、次の関数は、よかれと思って reserve() を行っていますが、余計なお世話になります。前述のとおり、reserve() には容量を縮める効果があるので下手に reserve() するとせっかく前もって確保していた容量が台無しになってしまうためです。
void AppendTwice(const string& stuff, string* output) {
output->reserve(output->size() + stuff.size() * 2);
output->append(stuff);
output->append(stuff);
}
余計なお世話をしないためには次のように書く必要があります。
void AppendTwice(const string& stuff, string* output) {
// 容量が足りていないときだけ reserve する
string::size_type new_size = output->size() + stuff.size() * 2;
if (output->capacity() < new_size) {
output->reserve(new_size);
}
output->append(stuff);
output->append(stuff);
}
処理の最初に前もって reserve() することは効果的ですが、文字列を連結していく途中で reserve() が入ると逆効果になることがあります。下手に reserve() を入れるくらいなら何もしないで「指数的な成長ポリシー」に任せたほうがましです。あるいは Rope のような内部的に非連続な文字列を使う手もあります。
では vector の reserve() の方はどうでしょうか。結論からいうと、 vector の reserve() は容量を減らすことはありません。SGI の vector のマニュアルに次のように書かれています。
If n is less than or equal to capacity(), this call has no effect. Otherwise, it is a request for allocation of additional memory. If the request is successful, then capacity() is greater than or equal to n; otherwise, capacity() is unchanged. In either case, size() is unchanged.
つまり、capacity() より小さい値を reserve() した場合、何も起きない仕様です。string もこの仕様なら、前述のコードで容量が増えたり減ったりするという不思議な挙動に悩まされることはなかったはずです。
また、vector.tcc の reserve() のコードは比較的シンプルで、素直に指定されたサイズで reallocation します。その代わり、「指数的な成長ポリシー」は _M_insert_aux() の中で実装されています。
size_type __len = __old_size != 0 ? 2 * __old_size : 1;
reserve() の中で「指数的な成長ポリシー」を実装している string より、 vector のやり方の方が好ましいように思います。
長くなりましたが、まとめると次のようになります。
なお、この記事で取り上げた string と vector の挙動は GCC 4.0.3 に付属する STL での挙動です。他の STL の実装では挙動が異なると思います。
p.s.
これを書いた後で、Effective STL の「reserve を使って不必要な割り当てを避けよう」のところを確認してみると、string の reserve() が 容量を減らす件について軽く触れていました。以前に読んだのにすっかり忘れていました。
string では size() か n の小さい方の値に容量を「減らすことがある」が、string のサイズは常に変わらない。筆者の経験では、 string から余分な容量を減らすには「swap」技法を使ったほうが成功することが多い。]]>
先日、移動中に読む本を物色しているときに、たまたま目についた『暗号化 - プライバシーを救った反乱者たち』を持って出かけました。
]]>
この本は買ってから長らく放置していました。何の気なしに電車の中で手にとって見ると、「まえがき」の時点でこれがただならぬ本であることが伝わってきました。結局、電車、空港、機内とノンストップで読み続けて、あっという間に読み終えました。
暗号をテーマにした本といえば、サイモン・シンの『暗号解読』という本が有名です（以前に紹介しました）。２冊を比べると、暗号解読がサイエンスライターによって書かれているのに対し、本書はジャーナリストによって書かれているという違いが出ています。数字で感覚的に表すと次のような感じです。
暗号解読 = サイエンス : 歴史 : ドラマ = 4 : 4 : 2
暗号化 = サイエンス : 歴史 : ドラマ = 1 : 4 : 5
大雑把にいえば、『暗号解読』がサイエンス（暗号の仕組みと解読法）と歴史に重点を置いているのに対し、本書は歴史とドラマ、特に人間の泥臭いドラマに力を入れている点が異なります。
ホイットフィールド・ディフィー（Diffie-Hellman鍵交換の発明者の一人）の放浪生活、RSAデータセキュリティ社の初期の窮乏とその後の躍進、暗号アナーキストの会合、クリッパーチップをめぐる攻防、といった出来事が当事者たちのインタビューを元に生々しく再現されており、1970年代から1990年代にかける暗号の世界を一緒に駆け抜けているかのような臨場感があります。
下世話なエピソードがたくさん取り上げられているのもポイントで、『暗号解読』の高尚な雰囲気とは異なり、ゴシップ度が結構高いのも本書の特色です。
『暗号解読』と比べるとやや影の薄い感がありますが、読み物としての完成度は高く、一読に値する本だと思います。最高に面白いノンフィクション本でした。
p.s.
ちなみに、スティーブン・レビー氏の『ハッカーズ』（こちらも以前に紹介しました）も、コンピュータ関連の読み物の中で最高峰にある一冊だと思います。今回の『暗号化』ですっかりスティーブン・レビー氏のファンになったので、未読だった『マッキントッシュ物語』『人工生命 - デジタル生物の創造者たち』『iPodは何を変えたのか?』をまとめ買いしました。楽しみです。
正月休みに何か気楽なものでも、と思い『Best Software Writing』を読みました。
]]>
この本は『Joel on Software』で知られる Joel Spolsky 氏が編纂した、ソフトウエアに関するエッセイ集です。20数名の著者による 30本以上のエッセイがまとめられています。
エッセイの選択は2004年に行われたため、今となっては目新しくないものもありましたが（Python は動的型付けで楽ちん。テストを書けば安心、みたいな）、今読んでも十分におもしろいエッセイが多くありました。なかでも次のエッセイが特におもしろいと思いました。
これらの中でも、長年に渡ってネット・コミュニティを観察し続けてきたクレイ・シャーキー氏による2本のエッセイは、語り口が鮮やかなこともあって、とりわけ興味深く思いました。
エッセイ集ということで、何かすぐに役立つといったことが書かれているわけでもありませんが、気が向いたときに読む読み物としてはなかなかよいのではないかと思います。
WEB+DB PRESS Vol. 48に「BK通信」の第5回「ブラウザのバッドノウハウ コンテンツ編」を書きました。Content-Type と Content-Disposition ヘッダにまつわるBKを取り上げました。あまりにバッドすぎて、通常2ページのところ今回は4ページに膨らんでしまいました。
]]>
今号は田中哲さん、太田一樹さん、森田創さんによるデバッグに関するエッセイや、最新のJavaScript エンジンの技術解説、スクリプト言語のモダンプログラミングなど、読み応えのある記事が満載でした。
個人的には田中哲さんのデバッグ記事に畏敬の念を覚えました。
知人がお勧めしていた『プログラミングの力を生み出す本』を読みました。
]]>
読みはじめてすぐに、この本は異色なプログラミングの入門書であることがわかりました。普通のプログラミングの入門書は「プログラミングとは」という序論が終わったら hello, world 的なものからコードを書き始めるものが多いと思うのですが、本書の導入はまるっきり異なります。1章の目次は以下の通りです（カッコ内は私のコメント）。
2章からは x86 のプログラムをアセンブリ言語で書き始めます。ここでも hello, world 的なものは一切登場しません。ビルドしたプログラムを GDB 上で命令単位でステップ実行して、レジスタの変化を見るというスタイルで解説が続きます。2章の目次は以下の通りです。
2章の序盤では、 GDB を使ってステップ実行する過程が丁寧に解説されています。自分で実行してみなくてよいところが親切です。GDB のチュートリアルとしても役立ちそうです。「スタック」の説では関数呼び出しがどのように行われるか（コーリングコンベンション）について解説されています。
3章はC言語の話、4章はプログラムの例の話です。これらは、すでにある程度 C言語でプログラミングの経験がある人にとってはそれほど興味深い内容ではないと思います。
巻末には付録で x86 の命令表がついています。すべての命令が網羅されているわけではありませんが、 gcc -S -O0 が出力しそうな命令はカバーされているのでリファレンスとして役立ちそうです。
異色のプログラミング入門書でした。説明が駆け足な点も見受けられるので、本当のプログラミング入門者が読むのに適した本かどうかはやや疑問ですが、gcc が出力する x86 用のアセンブリコードを読むためにアセンブリ言語を学びたい、という目的にちょうどいい本なのではないかと思います。
split 関数の挙動が言語ごとに微妙に異なると知人と話題になったので調べてみました。結果はまとめをどうぞ。
]]>
まずはRubyから調べてみます。irb を使って調べました。
% irb
...
まずは普通に分割
>> "a,b,c".split(",")
=> ["a", "b", "c"]
末尾に空要素があると、省略されてしまう
>> "a,,c,,".split(",")
=> ["a", "", "c"]
末尾の空要素を省略しないためには -1 が必要
>> "a,,c,,".split(",", -1)
=> ["a", "", "c", "", ""]
空文字列だと結果も空
>> "".split(",")
=> []
-1 をつけても同様
>> "".split(",", -1)
=> []
分割パターンを指定しない場合も同様
>> "".split()
=> []
分割パターン省略時は空白で分割（厳密には $; の値が影響）
>> "a b\tc\nd".split()
=> ["a", "b", "c", "d"]
分割パターンは文字列で指定できる
>> "a:b;c.d".split(".")
=> ["a:b;c", "d"]
分割パターンは正規表現でも指定できる
>> "a:b;c.d".split(/[:;]/)
=> ["a", "b", "c.d"]
分割パターンが空の文字列だったら？
>> "abc".split("")
=> ["a", "b", "c"]
分割パターンが空の正規表現だったら？
>> "abc".split(//)
=> ["a", "b", "c"]
分割パターンの正規表現が . だったら？
>> "abc".split(/./)
=> []
次は Perl です。Perl -d -e1 でデバッガを起動して調べました。-MData::Dumper はデータの表示用、 -MTerm::ReadLine はコマンドライン編集用のモジュールです。
% perl -MData::Dumper -MTerm::ReadLine -d -e1
...
まずは普通に分割
DB<1> p Dumper(split(",", "a,b,c"))
$VAR1 = 'a';
$VAR2 = 'b';
$VAR3 = 'c';
末尾に空要素があると、省略されてしまう
DB<2> p Dumper(split(",", "a,,c,,"))
$VAR1 = 'a';
$VAR2 = '';
$VAR3 = 'c';
末尾の空要素を省略しないためには -1 が必要
DB<3> p Dumper(split(",", "a,,c,,", -1))
$VAR1 = 'a';
$VAR2 = '';
$VAR3 = 'c';
$VAR4 = '';
$VAR5 = '';
空文字列だと結果も空
DB<4> p Dumper(split(",", ""))
-1 をつけても同様
DB<5> p Dumper(split(",", "", -1))
分割パターンは正規表現で指定できる
DB<6> p Dumper(split(/[:;]/, "a:b;c.d"))
$VAR1 = 'a';
$VAR2 = 'b';
$VAR3 = 'c.d';
分割パターンは文字列では指定できない（正規表現として解釈される）
DB<7> p Dumper(split("[:;]", "a:b;c.d"))
$VAR1 = 'a';
$VAR2 = 'b';
$VAR3 = 'c.d';
分割パターンが空の正規表現だったら？
DB<8> p Dumper(split(//, "abc"))
$VAR1 = 'a';
$VAR2 = 'b';
$VAR3 = 'c';
分割パターンの正規表現が . だったら？
DB<9> p Dumper(split(/./, "abc"))
分割パターンおよび入力文字列を省略時は $_ を空白で分割
DB<10> $_="a b\tc\nd"
DB<11> p Dumper(split)
$VAR1 = 'a';
$VAR2 = 'b';
$VAR3 = 'c';
$VAR4 = 'd';
というわけで、 Perl の挙動は分割パターンが文字列で指定できない（文字列で指定しても正規表現として解釈されてしまう）以外は Ruby と同じです。Ruby が Perl の挙動と揃えたのかもしれません。
次は Python です。python コマンドを使って調べました。
% python
...
まずは普通に分割
>>> "a,b,c".split(",")
['a', 'b', 'c']
末尾の空要素は無視されない
>>> "a,,c,,".split(",")
['a', '', 'c', '', '']
空文字列を分割すると配列に空文字列がひとつ入る
>>> "".split(",")
['']
しかし、分割パターンを指定しないとなぜか空になる！
>>> "".split()
[]
分割パターン省略時は空白で分割
>>> "a b\tc\nd".split()
['a', 'b', 'c', 'd']
分割パターンは文字列で指定できる
>>> "a:b;c.d".split(".")
['a:b;c', 'd']
分割パターンが空の文字列だったら？
>>> "abc".split("")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: empty separator
Python の挙動は Ruby/Perl 組とは異なります。最後の「分割パターンを指定しないとなぜか空になる」は不思議です。分割パターンが空のときにエラーになるのも特徴です。
次は JavaScript です。 js コマンドを使って調べました。
% js
...
まずは普通に分割
js> "a,b,c".split(",").toSource()
["a", "b", "c"]
末尾の空要素は無視されない
js> "a,,c,,".split(",").toSource()
["a", "", "c", "", ""]
空文字列を分割すると配列に空文字列がひとつ入る
js> "".split(",").toSource()
[""]
分割パターンを指定しない場合も空文字列がひとつ入る
js> "".split().toSource()
[""]
分割パターン省略時は分割しない
js> "a b\tc\nd".split()
a b c
d
分割パターンは正規表現で指定できる
js> "a:b;c.d".split(/[:;]/).toSource()
["a", "b", "c.d"]
分割パターンは文字列でも指定できる
js> "a:b;c.d".split(".").toSource()
["a:b;c", "d"]
分割パターンが空の文字列だったら？
js> "abc".split("").toSource()
["a", "b", "c"]
分割パターンが空の正規表現だったら？
js> "abc".split(new RegExp("")).toSource()
["a", "b", "c"]
分割パターンの正規表現が . だったら？
js> "abc".split(/./).toSource()
["", "", "", ""]
正規表現 /./ で分割したときの挙動が Ruby/Perl と異なります。
最後は Emacs です。*scratch* バッファで C-u C-x で式を評価＆表示して調べました。
まずは普通に分割
(split-string "a,b,c" ",") => ("a" "b" "c")
末尾の空要素は無視されない
(split-string "a,,c,," ",") => ("a" "" "c" "" "")
空文字列を分割すると配列に空文字列がひとつ入る
(split-string "" ",") => ("")
しかし、分割文字列を指定しないとなぜか空になる
(split-string "") => nil
分割パターン省略時は空白で分割
(split-string "a b\tc\nd") => ("a" "b" "c" "d")
分割パターンは正規表現で指定できる
(split-string "a:b;c.d" "[:;]") => ("a" "b" "c.d")
分割パターンが空の正規表現だったら？
(split-string "abc" "") => ("" "a" "b" "c" "")
分割パターンの正規表現が . だったら？
(split-string "abc" ".") => ("" "" "" "")
分割パターンが空の正規表現のときの挙動が Ruby, Perl, JavaScript のいずれとも異なります。
結果をまとめて表にしてみました。
| 言語 | 分割パターンの型 | 末尾の空要素 | 分割パターン省略時 | 入力が空文字列かつ 分割パターン指定あり |
入力が空文字列かつ 分割パターン指定なし |
分割パターンが空文字列 | 分割パターンが空正規表現 | 分割パターンが正規表現の . |
|---|---|---|---|---|---|---|---|---|
| Ruby | 文字列または正規表現 | 省略される (-1で抑制) | 空白で分割 | 空の配列 | 空の配列 | 文字ごとに分割 | 文字ごとに分割 | 空の配列 |
| Perl | 正規表現 | 省略される (-1で抑制) | $_ を空白で分割 | 空の配列 | 文字ごとに分割 | 空の配列 | ||
| Python | 文字列 | 省略されない | 空白で分割 | 空文字列入りの配列 | 空の配列 | エラー | ||
| JavaScript | 文字列または正規表現 | 省略されない | 分割しない | 空文字列入りの配列 | 空文字列入りの配列 | 文字ごとに分割 | 文字ごとに分割 | 文字数 + 1 の空文字列 |
| Emacs | 正規表現 | 省略されない | 空白で分割 | 空文字列入りの配列 | 空の配列 | 文字ごとに分割＋前後に空文字列 | 文字数 + 1 の空文字列 |
ここでは、「空白で分割」の「空白」とは「スペース、タブ、改行など」を意味します。個人的に妙だと思った挙動に色をつけておきました。
Ruby, Perl の末尾のから要素がデフォルトで省略されるという挙動は親切というよりは、落とし穴という感じがします。一方、 Python などの入力が空文字のときは空文字列入りの配列が返るという挙動も、これはこれではまりそうです。簡単そうに見える split 関数でも注意して使う必要があるようです。
以上、チマチマした研究でした。
追記: Perl の split は引き数なしで実行すると $_ の内容を空白で分割するとのこと、てきとうなメモさんにご指摘いただきました。
]]>
WEB+DB PRESS Vol. 46に「BK通信」の第3回「C++のバッドノウハウ」を書きました。C++ の雑多なバッドノウハウを取り上げています。
]]>
ちなみに、連載の過去の記事は gihyo.jp の「BK通信」のコーナーでも読めるようになりました。
]]>
発売後すぐに入手したものの長らく積読状態が続いていた『LINUXシステムプログラミング』をようやく読みました。
]]>
本書はその名の通り、Linux のシステムプログラミングについての解説書です。システムプログラミングの定義は明確ではありませんが、システムコールを用いて OS に近いレイヤーで行うプログラミングのことと考えて差し支えないと思います。
UNIX一般のシステムプログラミングについては『詳解UNIXプログラミング』という決定版がありますが、本書は Linux 固有の話題や POSIX の比較的新しい API が載っているところが異なります。
たとえば、前者になく本書にだけ載っている話題としては以下のようなものがあります。知らなかった話も多くて勉強になりました。
前述の『詳解UNIXプログラミング』が個々の話題を徹底的に掘り下げているのと比べると、本書の解説は比較的、簡素な部類に入ります。それから、本書は扱う話題をプロセス、ファイル、シグナル、時間といった基本的な概念に絞っているのも特徴です。
プロセス間通信、スレッド、ネットワークプログラミングといった高度な話題は本書の対象外です。同様に、端末やモデムといった、今となっては重要性が薄れた話題も省かれています。
Linux のシステムプログラミングの基本、および、新しいシステムコールを活用した一歩進んだテクニックが学べる良書です。初心者もベテランもどちらも楽しめる内容だと思います。全体で380ページ程度と比較的コンパクトなので、気負わずに読めるところもポイントです。唯一気になったのは図が少ない点です。
ところで、日本語訳である本書にはたびたび訳注が登場します。原書には登場しない openat システムコールを紹介するなど、ためになる注が入っています（蛇足っぽいものもありますが）。
知人と話していて、シンプルという言葉は手抜きの言い訳として使われることがあまりに多いので、シンプル＝バッドシグナル（バッドな兆候）なのではないか、という話になりました。
]]>
シンプルが言い訳としてよく使われるのは以下のような場面です。
プログラミングにおいてよくあるのが、まじめに実装していないクラスに Simple なんとかという名前をつけるパターンです。自らシンプルと名乗っているものには疑ってかかったほうがいいのかもしれません。
以上、シンプルな考察でした。
]]>
WEB+DB PRESS Vol. 45に「BK通信」の第2回「数値のバッドノウハウ」を書きました。数値の処理ではまった話を取り上げています。
]]>