プログラミング所感 - 前へ 目次 次へ

00/2/9(水)

いつのまにやら、2000年も過ぎた。2ヶ月以上ぶりの更新である。 家でも、1/1 を前に、食料を多めに買ったり、水をペットボトルに溜めたりした。 が、殆ど何も起きなかったね。只、原子力発電所関係で 2000年問題が発生したのには、はっきりいってあきれたね。 いくら関係ない所とはいえ、あれだけ、はっきり 「絶対に大丈夫です」と言い切った手前どうすんだ？ （だいたい、いくら税金使ったんだ？） まあ、何も責任とらないと思うけど。でも責任とって欲しいね。 大丈夫だって言ったんだから。認識甘いというか、往生際が悪いというか。

話がのっけからずれてしまったけど。 今回は、VC で DLL を作っていたときのこと。始めは問題なかったのだが、 突然、「DLLMainが、Mfcs42.lib と MSVCRT.lib の両方で定義されている」と 出てリンクできなくなった。さっぱり分からなかったのだが、 ふと、stdafx.h を使ってないソースにも全部 stdafx.h を書いたら 直った。理由はなんとなく想像できるが、はっきり説明できない。 動きが挙動不審なんだよなあ。 直ったからまあいいか。

ちょっと錯乱気味に、また、話は変わるけど。ニフティのログロックの コンテストを しているサイトがあって、現在、14問出題されている。
で、殆ど私がダントツで Top とってしまったのだが、実は、 アルゴリズムで解かせているからだ。でも、私以外についてきている 人がいないので、他の人は人間が解いているようだ。 プログラム書いて解こうという人はいないのかねえ。 もうちょっといてもいいと思うんだが。大学生とか。
（今回はぐちっぽいな。）

P.S.後から気づいたのだが、件のページには「アルゴリズムで解くな」と警告があった。 始めはなかったと思うのだけど。私のせいでできた警告かもしれない。 まあ、あれだけ瞬時に最短手を解答していたら気づくでしょうね。

00/2/16(水)

真楕式の言い分は「真円のメンバ(中心、半径)に対し、 楕円のメンバ(中心、長径、短径)は増えている」というものである。 しかし、これは間違いである。 第一に、半径は長径でも短径でもない。 つまりメンバは増えたのではなく、増減しているのである。
第二に、真楕式は派生の原則に反している。
派生の原則とは「A が B から派生しているならば、 A is a B の関係が成立しなければいけない」というものである。 数学的事実として、真円は楕円である。(何故なら、 楕円の定義を真円は満たしている。) 従って、原則に沿うためには楕円から真円を派生すべきである。 そうすれば、オブジェクト指向のメリットを受けられる。
例えば、次のような面積を求める関数があったとしよう。

double Ellipse::Area()const { return PI * Radius1() * Radius2(); }

この関数は、真円でもそのまま使用できるため、派生クラスで 再定義する必要がない。それでは、楕真式のインターフェースを見てみよう。

class Ellipse { double rad1; double rad2; Point pt; public: void SetRadius1(double r){rad1 = r;} void SetRadius2(double r){rad2 = r;} virtual double Radius1()const{return rad1;} virtual double Radius2()const{return rad2;} double Area()const; }; class Circle : public Ellipse { public: void SetRadius2(double r){rad1 = r;} virtual double Radius2()const{return rad1;} };

さてさて、真楕式の賛成派は、上で定義した Circle のオブジェクト サイズが無駄に大きくなると、異を唱えるだろう。それを避けるためには、 次のようにすればよい。

class AbsEllipse { public: virtual void SetRadius1(double r); virtual void SetRadius2(double r); virtual double Radius1()const; virtual double Radius2()const; double Area()const; // ここで定義 }; class Ellipse : public AbsEllipse { // .... }; class Circle : public AbsEllipse { // .... };

しかし、この設計でも次の批判は残ってしまう。 しなわち「Circle が Fat Interface である」というものである。 確かに、Circle のインターフェースには無駄がある。 この無駄を取り去るには派生関係をなくすよりしょうがない。 しかし、楕円が利用できるものは(理論的に)真円でも利用できるので、 全くの無関係にすべきものでもない。

結局、次のようにするのがベストであろう。

class Circle {}; class Ellipse { public: Ellipse(); Ellipse(const Circle&); };

こうすれば、Circle のオブジェクトでもキャストすることにより Ellipse のメソッドが使用できる。また、この方法は、仮想関数を 使用しないので効率が良いし、メモリの節約になるかもしれない。
ちなみに、Ellipse(const Circle&) に explicit は付けない方がよいと思われる。 また、Ellipse のコンストラクタを用意する代わりに、 Circle に operator 演算子を用意してもよい。 どちらを選ぶかは好みの問題であろう。

この方法は、生成式と呼ぶことにしよう。
生成式の特徴としては、

• A is a B の関係が成立する。
• A は B に条件(制約)がついたものである。
• A のメンバより B のメンバの方が多い。

00/2/28(月)

第1の問題は、ビットマップボタンにしたかったのだが、OnInitDialog がフレームワークから呼ばれない。 調べるとダイアログバーの場合、メッセージマップで

	ON_MESSAGE(WM_INITDIALOG, HandleInitDialog)

	LRESULT HandleInitDialog(WPARAM,LPARAM);

	((CButton*)GetDlgItem(IDC_BUTTON1))->SetBitmap(bmp);

第3の問題は、最も深刻だった。ボタンが押せないのである。 他の人が作っているところで、できているようなので調べたら次のようにしてできた。 しかし、本人も何故そうしたのか覚えていないとのことだ。解決方法は、 「そのダイアログバーを持っているフレームクラスで、ボタンのハンドラを定義する」である。 このハンドラはダミーなので中は空でよい。
つまり、ダイアログバーの処理は、親フレームで全て処理することが期待されている。 それで、ボタンを押せるかどうかは、親フレームにハンドラを定義しているかどうかで 判断しているようだ。そこで、ダミーで定義すれば押せるようになると思われる。 でも実際に呼ばれるハンドラは、ダイアログバーで定義したハンドラである。 ある意味、フレームワークを騙しているのだから、危険なトリックかもしれない。

00/2/29(火)

サンプルの作成

• 新規に AppWizard(exe) で BitmapTest を作成する。SDI でそのまま OK。
• 新規にビットマップリソースを作成。 コピーして、絵を黒で塗りつぶし、マスク(IDB_BITMAP2)とする。 元絵(IDB_BITMAP1)は、背景を黒くする。
• ClassWizard で CBitmapTestView の WM_LBUTTONDOWN にハンドラを作成。
• CBitmapTestView.cpp を以下のように修正

  CPoint g_pt; void CBitmapTestView::OnDraw(CDC* pDC) { CBitmapTestDoc* pDoc = GetDocument(); CBitmap b1,b2,*p1,*p2; BITMAP bm; b1.LoadBitmap(IDB_BITMAP1); b2.LoadBitmap(IDB_BITMAP2); b1.GetBitmap(&bm); CDC dc1,dc2; dc1.CreateCompatibleDC(pDC); dc2.CreateCompatibleDC(pDC); p1 = dc1.SelectObject(&b1); p2 = dc2.SelectObject(&b2); CBrush br(HS_CROSS,RGB(200,255,200)); CRect r; GetClientRect(&r); pDC->FillRect(&r,&br); pDC->BitBlt(g_pt.x,g_pt.y,bm.bmWidth,bm.bmHeight,&dc2,0,0,SRCAND); pDC->BitBlt(g_pt.x,g_pt.y,bm.bmWidth,bm.bmHeight,&dc1,0,0,SRCPAINT); dc1.SelectObject(p1); dc2.SelectObject(p2); } void CBitmapTestView::OnLButtonDown(UINT nFlags, CPoint point) { g_pt = point; Invalidate(); }

• ビルドして確認。CBitmap の変数は、適当なところにメンバ変数にした方がよいだろう。 ミソは、マスクで書きたいところを消しておいて、書きたいものを OR で書くところであろう。 StretchBlt でもよい。

00/3/10(金)

二日後の今日、営団は護輪軌条の基準見直しを検討している。 （読売の記事では 補助レールと記述しているが、護輪軌条という方がかっこいい。）
護輪軌条とは、電車が脱線しないようにレールの内側につけるもう一つの レールのことである。車輪をサンドイッチにして外れないようにするものだ。 これまで、見たことはあったが、名前も役割も知らなかった。 しかし、このレールがあれば大惨事は防げたかもしれないのだから、 役割は重要である。

この雑記はプログラミング所感であるから、プログラミングの世界での 護輪軌条は何かを考えてみよう。
まず、思いつくのは assert であろうか。しかし、assert は事態がまずくなってから、 いわば、事故が起きたときに検出するものなので、「事故を未然に防ぐ」護輪軌条とは 異なるといっていいだろう。
これというものは、なかなか思いつかないが、適当にあげていってみよう。
データ構造の設計では、護輪軌条のようなものが存在している。 １つは、データの冗長性を排除した設計があるだろう。データの整合性が崩れる （事故が起きる）ことをそもそも不可能にするという点で、護輪軌条と同じといえる。 よく行うものでは、エラーチェックもそうかもしれない。例えれば、電車の前方に 障害物を発見して、ブレーキを踏むようなものであろうか。 （assert は、abort() を呼ぶから自爆するようなものだ。もちろん、 初心者のための提言で書いたように、 どんどん使った方がよいけど。)

他には、ライブラリやフレームワークやデザインパターン、 あるいは整った開発環境の利用もあげられるかもしれない。
適切なレビューなどはどうだろう。まぁプログラミングに入ってから レビューっていうのは変かな。

ソフトウェア設計では、バグの検出に重点を置いている気もするが、 バグそのものを出さない護輪軌条はもっとないのだろうか。
もっとも、私はいつも次のように思っているのだが。

00/3/13(月)

00/3/14(火)

さて、ここからが本題。

• Java のように、捨てるべき言語機能は捨てるべきだ。
• Java のように洗練された所は、取入れるべきだ。
• STL は、まだ改良の余地がある。
• GC は必要ない。何故なら、私は今現在、GC なしでうまくやっていけている。

また「よい言語が大衆に受入れられるとは限らない」ということもある。 OS もそうだけど。

ちなみに、前に書いた、内部クラスに関する疑問は、 上記の本を読んで理解した。結局、「内部クラスは、外側のクラスの参照を隠れて 持っていて使える」ということだった。
7/14 の話参照。

00/3/27(月)

00/3/28(火)

list<...>	l;
while (...) l.push_back(...);

最初にサイズがわからない場合、list を使いたくなることがあるかもしれない。 しかし、途中に挿入や削除をしないのであれば、vector を使うべきである。 vector の方がメモリの点でも速度の点でも効率的なのは説明するまでもないであろう。 さらに、vector の反復子は ランダムアクセス反復子であるから恩恵もうけられる。 (例えば、stable_sort ができる。list を stable_sort したければ、一旦 index を vector で作り直すなどしないといけない。)

vector で push_back を使う場合でも、最初にサイズがわかっているならば、 reserve を使うべきなのは言うまでもない。

次に、何でもかんでも map を使いたがる人が多いように感じる。 例えば、名前と社員コードがある「社員(Employee)」を作ったとすると

class Employee { string name; // 名前 ... }; map<int,Employee> data;

全体のデータを map で管理したりしていることがある。 これは、次のように直すべきだ。

class Employee { int code; // 社員コード string name; // 名前 ... }; map<int,int> dic; vector<Employee> data;

dic は社員コードから index を変換するために用いる。 後は、index を使って data をアクセスするようにするのだ。 もちろん、アクセスのたびに dic を使っていたら元も子もないので、 極力 index のみ使うようにしなければいけない。

map は便利だが、まず vector が使えるか考えること。 但し、set の代わりにいつでも vector を使うのはやめた方がいいだろう。 おそらくは、よく考えれば set か vector のどちらを選ぶべきかは わかるはずだと思う。

00/3/31(金)

  System.out.println(...)

と書く。実は、こういう書き方が、私は好きである。 最初に、こういう書き方に出会ったのは、14年程前、CLU という言語である。 はっきり言ってマイナーな言語であり、私も殆ど覚えてないのだが、 Java と同じような書き方になっていた。もっとも、Java の out はオブジェクトだが、 CLU では(C++風に言えば) static な関数だったと思う。

基本的には、私はタイピングが少ない方が好きである。 しかし、C ならば、printf で済むところを、2,3 倍のタイピングを要するものを 何故、好むのか？
それは、わかりやすいからである。物事を分類しているからだ。

printf は、グローバルな空間にボンと置いてある。System.out.println で、 グローバルなのは System だけである。
タイピング量は、あまり問題ではない。というより「わかりやすさ」の方が 問題なのだ。実際、CLU 使用時は、自作エディタの自動展開機能を利用していたので 3,4 文字打つだけで入力できていた。(vi でもできるし、VC++6 なんかでも 途中まで打てばいいようになっているのもある。）
通常だと、文字数がすくない方がわかりやすいといえる。しかし、 この場合は、逆に文字数が多い方がわかりやすくなっているのだ。 最も、out の立場を尊重して、printf との比較ではなく、 fprintf(stdout,...) との比較ならば、文字数はそれほど変わらなくなる。 (さらに言えば、printf と fprintf(stdout,...) の比較では単純に文字数の多い fprintf の方がわかりにくい。)

これらは、つまるところ、名前空間(namespace そのものではなくもっと一般的な意味)の 導入にある。私の好きなのは、それが、標準ライブラリでも一貫して使用されている というところである。

00/4/5(水)

同じような話に、「カンマ演算子の使用」がある。カンマ演算子を使用すると プログラムを短く書くことが可能である。しかし、たいていの場合、カンマ演算子を 使うとわかりにくい。 (C++ ではカンマ演算子をオーバライドできるのでさらにわけわからなくすることもできる。)
結論から言えば、カンマ演算子は原則として使わない方がいいだろう。私は、１つの例外を除いて めったに使わない。例外は、

for (k=0, it=a,begin();it!=a.end();++it, ++k)

のような for の中である。ここでは、２つカンマ演算子を使っている。 １つめの k=0 を書いている理由は ++k を同じところで書いているので、 対比させるためである。２つめの ++k を書いている理由は、別のところに書くと わかりにくくなることがあるからである。また、この場合は、スペースの入れ方にも ちゃんと意味がある。カンマ演算子のところにスペースを入れることにより、 通常とは異なる記述方法を目立たせているのだ。
カンマ演算子は、バグの原因にもなりやすい。 例えば、ある人のバグで次のようなのがあった。

if (func(a,b),0) {

書いた本人は、func(a,b,0) のつもりだったのだが、 第 3 引数がなくてもよかった(デフォルト引数 or オーバロード)ため、 コンパイルでは何のエラーにもならなかったのだ。

ところで、次のような表記は欲しくなったりもする。関数が複数の返り値を持てて、代入もできるというもの。

a,b = func();

但し、上の例は、コンパイルできる可能性があるが、もちろん意図した通りにはならない。 これ以上、C++ を複雑にしてどうするというのもあるけど。

00/4/7(金)

   struct Some {
     list<int>           l;
     list<int>::iterator i;
     void Save(ostream& o);
     void Load(istream& i);
   };

i は、l の中のどこかを指しているとする。（すなわち、Java のシリアライズみたいに 反復子の指している先を自動的に生成することは考えない。） どういう実現方法がいいのかよくわからないが、取りあえず、こんなのを書いてみた。

#define forall(C,I) for (I=C.begin();I!=C.end();++I) namespace iterserial { template <typename T,typename C,typename I> void write(T& t,C& c,I i) { I it; int v = 0; forall(c,it) if (it == i) break; else ++v; t << v << " "; } template <typename T,typename C,typename I> void read(T& t,C& c,I& i) { int v; t >> v; i = c.begin(); while (--v >= 0) ++i; } } void Some::Save(ostream& os) { list<int>::iterator it; os << l.size(); forall(l,it) os << *it << " "; iterserial::write(os,l,i); } void Some::Load(istream& is) { list<int>::iterator it; int v; is >> v; l.resize(v); forall(l,it) is >> *it; iterserial::read(is,l,i); }

こんなのでも役に立つかな。
CArchive を使うときはデリミタをとらないといけない。また、ランダムアクセス反復子用に テンプレートの特別バージョンを書いた方がいいだろう。(I ではなくて I* を用意する。) あるいは、STL の distance を使えばいいかもしれない。distance には 特別バージョンが存在しているので。

00/5/9(火)

00/5/10(水)

struct Any {
    void foo(int i,int j);
    void foo(int i=9){foo(i,i);}
};

最初、2引数の関数だけを用意したのだが、便利かと思って1引数のも追加した。 さらに、0引数も追加しようかと思ったのだが、1引数のデフォルト引数にした。 こうすると、

• foo(1); -> foo(1,1);
• foo(); -> foo(9,9);

struct Any {
    void foo(int i=9,int j=9);
};

ちなみに、私はあまりデフォルト引数を使うのは好きでない。 プログラムが固定してしまったら、使うのはやぶさかでないが、 引数を変更する可能性があるときは、デフォルト引数があると 混乱しやすい。
引数を増やすときに、「既に書いてしまった 関数呼出しを修正しなくてよいから」という理由で デフォルト引数を追加する人もいるが、私はわざと避けるようにしている。 理由は、やはり思わぬバグの原因になりやすいからだ。

00/5/11(木)

話は変わるが、記録しとけば良かったと思うのは、本である。 理由は、本屋で買いたいと思った本を既に読んだことがあるかどうか 分からないからだ。子供には「自分が読んだ本を記録する」習慣を教えるようにしよう。 私には、既に買ってある本のデータベースを作る気力はない。 というか挫折した。たぶん、単行本だけで2,3千冊あるだろう。

また話は変わるが、初心者に GUI アプリケーションの講習をする時に、 題材として何がいいだろう。VC++ チュートリアルでは、 お絵かきソフトを作らせている。あれは、いい題材だと思う。 簡単に高機能なものができたので感動した覚えがある。
他には、エディタなどどうだろう。VC++ で AppWizard なら楽々できるだろう。 WebBrowserコントロールで単語をWebで検索なんかもできるだろう。 後は、Exploler みたいなファイラーもいいかもしれない。 機能的には、「ツリービューで複数フォルダの選択すると、 全部フラットに見える」とか「サブフォルダ以下もフラットに見える」 というのが欲しいな。

00/5/15(月)

• 参照メンバは自クラスのメンバの別名となるべき

• 参照メンバがあると、デフォルト代入演算子ができない

では、参照メンバに関する鉄則を決めよう。

• 参照メンバは自クラスのメンバの別名にする
• コンストラクタ、コピーコンストラクタは、適切に定義すること
• 代入演算子を宣言すること

struct Test {
  enum {Size = 3};
  int data[Size];
  int& height;
  int& width;
  int& id;
};

という具合。data[0],data[1],data[2] が height,width,id に相当する。
以前は、「参照メンバなど殆ど不要」と思っていたが、 なかなか使い所があるかもしれない。

00/5/22(月)

00/5/23(火)

  bool operator<(const Any& a)const{
    return i1 < a.i1 || (i1 == a.i1 &&
           i2 < a.i2 || (i2 == a.i2 &&
           i3 < a.i3));}

この関数は間違っているが、どこがおかしいか判るだろうか？

答えは、次の通り。

bool operator<(const Any& a)const{ return i1 < a.i1 || (i1 == a.i1 && (i2 < a.i2 || (i2 == a.i2 && i3 < a.i3)));}

何ともお粗末でした。

00/5/24(水)

  list<Data>            m_data;
  list<Data>::iterator  m_cur;

として、リストと現在のデータを指す反復子で管理できるだろう。 あとは Undo したい操作の直前で現在のデータを複製(MakeClone)するようにする。 実際に Undo するときは、m_cur をデクリメントするだけでよい。 また、Redo も簡単に実装できるだろう。

さて、MakeClone の実装だが、始め次のようにしていた。（細かい所は省略）

m_data.push_back(*m_cur++);

もちろん、これでも問題なく作ることはできる。しかし、MakeClone するとデータのメモリアドレスが 変わってしまう。結果として、外部にデータを指す反復子を持っていると、更新しないといけない。 そして、更新忘れからバグが生じやすくなっていた。で、ちょっと考えれば次のようにすればよかった。

m_data.insert(m_cur,*m_cur);

こうすれば、Undo がないときと同じように書いても問題ない。実に簡単。

00/5/26(金)

#include <cstdio>
#include <utility>
using namespace std;

template<typename T>
T f(const T& t){return t;}

int main()
{
  pair<int,int>  p(1,2);
  pair<int,int>& r = f(p);  // (1)
  int&           i = f(1);  // (2)
  return 0;
}

(2)はエラーになるのに、(1)はエラーにならない。 gcc ならばもちろん(1),(2) ともエラーになる。

よくある間違いで、オリジナルを設定しているつもりで、コピーされた一時変数を 設定していることがある。つまり、参照(&)の付け忘れだ。 ところが、ちゃんと参照を付けているのに、変更されないことがあった。 で、調べてみると、VC++ のバグであった。一時オブジェクトの const でない参照が 取れてしまうのだ。これは、是非ともすぐに直して欲しいなぁ。

00/6/13(火)

00/6/22(木)

  Any a;
  set<Any> s;
  set<Any>::iterator it;
  it = find(s.begin(),s.end(),a);
  if (it == s.end())
    s.insert(a);

このようなときに、insert が失敗することがある。 （insert の返値はチェックしといた方がいいかもしれない。）

set のメンバ関数 insert には3種類ある。ちょっと勘違いしやすいのが、 iterator insert(iterator it, const value_type& x);(1) である。 これは、pair<iterator, bool> insert(const value_type& x);(2) と ほぼ同じである。違いは、insert される x が it の直後にあるときに速くなることだけである。 従って、通常は (1) と find を対で使うべきであろう。

00/6/23(金)

00/6/29(木)

話は変わって、VC++ の新顔のキーワードをいくつか。
mutable は、今まで殆ど使ったことがない。 mutable の第一候補はキャッシュであろうか。 基本的に、mutable 的なものを変更するのであれば、非const にして ユーザに意識させた方がいいのではないかと思っていたからだ。 といいつつも、この前、mutable を使った。対象はテンポラリ変数である。 ユーザは mutable だと意識して使えるようになっている。

次に、explicit だが、これは良く使う。基本的にユーザコンストラクタ （デフォルトコンストラクタ、コピーコンストラクタ以外のコンストラクタ。たった今命名） では付けるように考慮すべきだろう。
あと、typename というのもある。これは、template<typename T> みたいな ものしか使ったことがない。STL 関係ではよく見かけるけど。

全然関係ないが、オープンソースで簡易 Visual SLAM みたいなものを作るかな。

00/7/6(木)

#include <cstdio>
int main()
{
  double d;
  sscanf("1","%lf",&d);
  return 0;
}

上のプログラムが、VC++6 で実行時エラーになってしまう。 原因は「浮動小数点ライブラリがリンクされていない」からであった。 例えば、sscanf の前に、d=0; とか入れておくと大丈夫となる。

00/7/12(水)

00/7/14(金)

Java で「全てのクラス変数が ポインタ であって GC が装備されている」 ことは大失敗ではないかと思っている。
ちょっと乱暴だが、例えてみれば「Java のメモリ管理は UNIX のハードリンクに似ている」 また「C++ のメモリ管理は UNIX のシンボリックリンクに似ている」
ハードリンクはリンクされているものが全て同列になる。

% touch aaa % ln aaa bbb % ln aaa ccc

このようにすると、3つファイルができるが実態は１つである。すなわち、aaa を修正すれば、 bbb,ccc も修正される。しかし、3つのファイルは同列である。aaa を消しても bbb,ccc のファイルは残り、中味も残る。そして、bbb,ccc も消すと、実態も消える。 これは、Java の世界と同じである。

% touch aaa % ln -s aaa bbb % ln -s aaa ccc

このようにしても、3つファイルができ実態は1つである。しかし、実態は aaa そのものである。 従って、aaa を消してしまうと、bbb,ccc のリンク自体は残るが参照先がないので、 bbb,ccc の中味を見ることはできなくなる。
UNIX の世界では、シンボリックリンクの方がハードリンクより使いやすいのは常識である。 理由は、「所有」か「参照」かがはっきりしているからだ。これと同じ理由で、 Java プログラマは「所有」と「参照」の区別がつかなくなる可能性がある。 これは悲劇である。

メモリ管理に悩まされたことがあるプログラマは、GC が必要と感じるだろう。 私も、メモリ管理でわけわからなくなってプログラムを捨てざるを得なくなったことがある。 しかし、繰返すが GC は必要ない。必要ならば自分で作ればいい。 それに STL を使うと、new や delete を書かずにプログラムを書くことができる。 （なおかつ、多様性も使うこともできる）大事なのは、「所有」か「参照」かを はっきり区別することである。 コンテナに何を入れるかが 非常に参考になるだろう。（今日はまだできていないけど）
3/14 の話参照。

00/7/19(水)

• ダイアログもしくはフレームで、DragAcceptFiles()を呼ぶ。
• 同じクラスに WM_DROPFILES のハンドラ OnDropFiles(HDROP hDropInfo) を定義する。

  // m_val にファイル名を表示する例 void CWTestDlg::OnDropFiles(HDROP hDropInfo) { int i,n; char buf[MAX_PATH+1],*p; n = ::DragQueryFile(hDropInfo,0xffffffff,buf,sizeof(buf)-1); CString s; for (i=0;i<n;i++) { ::DragQueryFile(hDropInfo,i,buf,sizeof(buf)-1); if (i) s += "\r\n"; p = strrchr(buf,'\\'); s += p ? p+1 : buf; } ::DragFinish(hDropInfo); m_val = s; UpdateData(FALSE); }

• そのコントロールの DragAcceptFiles()を呼ぶ。 ダイアログもしくはフレームでもできるが、カーソルが変化する範囲が画面全体になる。
• コントロールのプロパティの拡張スタイルで「ドラッグドロップを許可」をON。
• コントロールの派生クラスを作成し、WM_DROPFILES のハンドラ OnDropFiles(HDROP hDropInfo) を定義する。
• ClassWizard でそのコントロールに作成した派生クラスの変数を作成する。

00/7/21(金)

このままだと不便なので、CString* m_pEdit[N]; とメンバを追加して、 ダイアログのコンストラクタで、m_pEdit[0] = &m_edit1; ... などとして 配列で使えるようにするのだが、結構、面倒である。
どうも直接、配列変数をコントロールに結びつけた方がよさそうである。 この方法では、ClassWizard は使わない（使えない）。やり方は、 メンバ変数、CString m_edit[N]; を宣言し、 DoDataExchange() で DDX_Text(pDX, IDC_EDIT1, m_edit[0]); というように書くだけである。 （ClassWizard で使うわけでないので、//{{AFX_DATA_MAP(...) の外に書くこと。）
できれば、ClassWizard が対応して欲しいものだ。

00/7/24(月)

圧縮は、メニュー一発でできているので、コマンドラインからもできるはずである。 しかし、WinZip のオプションがわからない。 試行錯誤を繰返すこと以下の通り。

• WinZip のヘルプを調べる。
• 適当なオプションをいろいろ付けて起動してみる
• WinZip32.exe のバイナリ自体を vi で開いて、オプションらしきものを探す。
• レジストリでそれらしいものがないか探す。
• Windows のプロセスビューワーで調べる。
• Cygwin32 の ps で調べる。

00/7/27(木)

00/7/28(金)

さらに、プロファイルをとってみると、vector の insert で時間がかかっていたが、 insert は使っていない。これは、push_back の中で呼ばれているものだった。 私は、vector でサイズが分からない時、push_back をよく使っている。 今回は、サイズが予め分かっていたのだが、reserve しておいてから、 push_back していた。この部分を、reserve を resize に直し、push_back を 使うのを止めたところ、さらに時間を約25%減らすことができた。 push_back に時間がかかるのは意外であった。g++ だとまた違うかもしれない。
（ちなみに、reserve + push_back の部分を push_back だけに直してみても、 時間は殆ど変わらなかった。これは、非常に不思議であった。）

ここまで来て、最初に修正した「O(N^2) から O(N)」の部分をもう一度修正してみた。 すると今度は、時間が約7%減となった。 一般に、高速化を行う場合プロファイリングした結果を使って行うのが妥当とされている。 しかしここで感じたのは、「例え重要でない所でも、オーダが変わるような変更は 行った方が後々よいことがあるかもしれない」ということである。

また、vector で operator[] を使用している所を反復子に変えてみたりもしたが、 殆ど変わらなかった。他にもいくつか変更を試みたが、時間の変わりがない所は 表現の簡単な方を採用した。今回、久しぶりにプロファイラを使ってみたが、 なかなか興味深かった。新人にも研修でやらせてみるかな。

00/07/30(日)

また、よく誤解されている「vector は 組込み配列より遅い」という ことについても充分な実験結果を通して、説得力のある反論を展開している。 （fj.comp.lang.c++ の参加者もみんな読んで欲しいものだ。）

この中で興味を引いたのが、inline の使い方である。 効果的な方法がいくつも紹介されている。
これまた、よく誤解されることだが、「inline 関数は、依存性を悪くするので使わないほうが良い」 ということがある。確かに、開発時に inline 関数を修正すると多数のファイルが再コンパイルされ 開発効率が悪くなる。だからといって inline 関数を使うべきでないというのは、ナンセンスである。 開発が終了したら、プロファイラを見ながら inline 化していけばいいのだ。
これをサポートするための方法も紹介されているが、難点がある。

• 拡張子が inl というファイルを扱っている。
• 1つのクラスに関連するファイルが *.h, *.cpp, *.inl の３つになる。

XXX.h: #ifndef HEADER_XXX_H #define HEADER_XXX_H クラス宣言 #ifdef INLINE_IND #include "XXX.cpp" #endif // INLINE_IND #endif // HEADER_XXX_H XXX.cpp #ifndef HEADER_XXX_H #include "XXX.h" #ifdef INLINE_IND #undef INLINE_IND #else // INLINE_IND #define INLINE_IND #endif // INLINE_IND 非 inline 関数の定義 #endif // HEADER_XXX_H #ifdef INLINE_IND inline 関数の定義（頭に INLINE_IND を付けること） #endif // INLINE_IND

inline 関数を無効にしたい時は、何も定義しない。 有効にした時は、INLINE_IND=inline を定義する。 （VC++6 では、INLINE_IND を INLINE にするとおかしくなるので注意）

もっとも、このテクニックは、単純な Make しか使えない環境では、 避けたほうが懸命であろう。しかし、VC++6 では、効果がある。 すなわち、非 inline 指定時に XXX.cpp を修正しても、コンパイルし直すのは XXX.cpp だけである。これは、VC++ が #if ディレクティブ を 理解ながらコンパイルすべきファイルを決定しているからである。 （プリコンパイル済みヘッダを使用していても問題なく使える。） しかし、inline 指定時は、コンパイルするファイルが増えてくるので、 inline 関数をヘッダに移した方がいいかもしれない。

00/07/31(月)

• 所有と参照をはっきりさせる。
• コンテナは STL ベースのものを利用しよう。
• 反復子のシリアライズは、基本的に以前紹介した方法でよい。 注意すべきは、反復子の前にコンテナ本体をシリアライズする所である。

00/08/01(火)

STL の中でも vector は最も効率がよい。但し、メンバ関数 at は 使わない方がよい。STL から外した方がいいだろう。 理由は、非効率的だからである。添え字の範囲チェックは必要なものだが、 常に必要なものではない。同じコードでスイッチできる方がいい。 ということで、私は、ライブラリのヘッダ <vector> を以下のように修正している。

const_reference operator[](size_type _P) const { #ifdef ASSERT ASSERT(_P >= 0 && _P < size()); #endif eturn (*(begin() + _P)); } reference operator[](size_type _P) { #ifdef ASSERT ASSERT(_P >= 0 && _P < size()); #endif return (*(begin() + _P)); }

MFC を使用していれば、ASSERT は定義済みである。MFC を使用していなければ、 自前で定義すればいいだろう。(#define ASSERT assert または、ASSERT=assert)

00/08/08(火)

• CXXXView に以下のメンバ、メンバ関数を追加。

  void (CXXXView::*m_handler)(UINT nFlags, CPoint point); void OnMouseClick(UINT nFlags, CPoint point); bool CheckMove(UINT& nFlags,CPoint& point);

• CXXXView のコンストラクタに以下を追加。

  m_handler = &CXXXView::OnMouseClick;

• CXXXView に WM_LBUTTONDOWN のハンドラを作成し、以下を追加。

  if (m_handler && !GetCapture()) { SetCapture(); (this->*m_handler)(nFlags,point); ReleaseCapture(); }

• 以下を追加。

  bool CXXXView::CheckMove(UINT& nFlags,CPoint& point) { MSG msg; while (::GetMessage(&msg,0,0,0) >= 0) { if (msg.message == WM_MOUSEMOVE || msg.message == WM_LBUTTONUP) { nFlags = msg.wParam; point = CPoint((DWORD)msg.lParam); return msg.message == WM_MOUSEMOVE; } ::TranslateMessage(&msg); ::DispatchMessage(&msg); } return false; }

• OnMouseClick を作成する。以下、例。

  void CXXXView::OnMouseClick(UINT nFlags, CPoint point) { int i; UINT flg; CPoint pt; i = point 位置でのオブジェクトのID if (i が無効な値) { if (作成モード) { point 位置にオブジェクト追加 Invalidate(); return; } else { // ドラッグ中に四角を描く CRect r(point,CSize(0,0)); CClientDC dc(this); int pr = dc.SetROP2(R2_NOT); DrawRect(&dc,r); while (CheckMove(flg,pt)) { DrawRect(&dc,r); r.BottomRight() = pt; DrawRect(&dc,r); } DrawRect(&dc,r); dc.SetROP2(pr); return; } } while (CheckMove(flg,pt)) { ID == i のオブジェクトを pt に移動 Invalidate(); } }

状態に応じて、処理を切替えるには、Java の MouseListener 相当の クラスを作ることもできる。もっと、簡単に enum か int のフラグで 処理することもできるだろう。どちらがいいだろうか？クラスを作った方が 柔軟ではある。結局は、どちらも一長一短があるので、便利な方を使えばいいだろう。 組合わせてもいいだろう。
とはいえ、クラス管理した方がわかりやすいケースというのは、 モードがいっぱいあるようなGUIと想像できる。使いにくそうな気がする。 ということで、上記の例ではクラスを使っていない。

00/08/09(水)

00/08/18(金)

私と言えば、かなり適当である。要求仕様書からいきなりコーディングしてしまうぐらいである。 設計といってもメモ書き程度のことが多い。
また、プログラミング能力の個人差が非常に大きいことが気になっている。 もっと工学的にやれないものだろうかと常々思っていた。 そこで、SEI（カーネギーメロン大学のソフトウェア工学研究所）のハンフリー教授の 「ソフトウェアは真の工学になりえるか？」というセミナーを聞いて、 PSP（パーソナルソフトウェアプロセス）技法 を勉強することにした。今、5章を終わった所だが、結構きつい。人にも勧めているのだが、 かなりのやる気を必要とするだろう。
ここで強調したいのは、「やる気が大切」なのではないか？ということである。
去年、入社以来 最も大規模な運用システム開発を行った。結果的には、成功したと思っているが、 工学的な手法は何ら用いていない。常に気にしていたのは「プロジェクトを成功させよう」ということだけである。
思うに、「インスペクションをやれば上手くいくだろう」ではだめだろう。 「上手くやりたい。そのためにインスペクションを利用しよう」という気構えが必要だろう。 「インスペクションなど本当に効果があるのかな？面倒だな」なんてのは、やる前から失敗とわかる。 工程は大事であるが、その前に、行う本人が完全に納得し効果を確信するように持っていくべきである。
そのためにはどうすればよいか？まず、簡単であること。（単純作業はコンピュータを利用して減らすべきである） 次に、効果がわかること。さらに、組織がフォローしていること。言うは易し、行うは...というところか。

00/08/21(月)

00/09/01(金)

00/09/13(水)

  int  i = 1;  // (1)
  int  i(1);   // (2)

このように初期化の方法には、2通りの方法がある。 この場合は処理は全く同じになる。私は、(1) のように書くことが多いが、 (2) のように書く人も増えている。(2) は C では書けなかったため、私は (1) のように書く習慣がついてしまっているのだ。

A a = 1; // (3) A a(1); // (4)

組込み型でない場合でも、(3) と (4) は共に初期化処理となり同じである。 （(3)は代入ではない。） しかし、見た目以外に 2つの点で (3) と (4) は異なる。 1つは、引数を2つ以上に変更する場合である。

A a = A(1,2); // (5) A a(1,2); // (6)

このように、(3) から (5) に変更するのは面倒である。 このときは、(6) のように書く方がいいと思う。
もう1つの違いは、A のコンストラクタに explicit がついている場合である。 このときは、(4) の書き方は許されるが、(3) は許されない。
メンバイニシャライザでの書き方も、括弧を使い、「=」は使用できない。 いろいろな書き方が混じるよりは統一すべきであろう。であれば、以上のようなこと を考えると、初期化は括弧を使用すべきと思われる。
しかし、私はこの書き方にまだ慣れない。

00/09/14(木)

反復子に 0 を代入している時に呼ばれているのは、反復子のコンストラクタである。 （vector は除く）従って、代入だけでなく、0 と比較することも可能である。
また、呼ばれているコンストラクタで合致しているのは、実装依存の内部クラスの ポインタを引数にしているコンストラクタである。（vector は除く） これは、まずいであろう。これらのコンストラクタは、explicit を付けるべきである。
バグの原因となりやすいので、早いとこ直した方がいいと思う。 VC++ なら自分で開発環境のヘッダ list や xtree を直せばいい。 以下のプログラムは、通常ならばエラーは出ないが、直せば10箇所でエラーとなる。

#pragma warning (disable : 4786) #include <list> #include <map> #include <set> using namespace std; int main() { list<int>::iterator i0; map<int,int>::iterator i1; set<int>::iterator i2; multimap<int,int>::iterator i3; multiset<int>::iterator i4; list<int>::const_iterator i5; map<int,int>::const_iterator i6; set<int>::const_iterator i7; multimap<int,int>::const_iterator i8; multiset<int>::const_iterator i9; i0 = 0; i1 = 0; i2 = 0; i3 = 0; i4 = 0; i5 = 0; i6 = 0; i7 = 0; i8 = 0; i9 = 0; return 0; }

直した所(該当行のみ)

<list> explicit const_iterator::const_iterator(_Nodeptr _P) explicit iterator::iterator(_Nodeptr _P) <xtree> explicit const_iterator::const_iterator(_Nodeptr _P) explicit iterator::iterator(_Nodeptr _P)

00/09/18(月)

  int* f();
  int* p(f());

上の様に書くと、VC++6 ではシンタックスエラーになる。「=」を使えば OK となる。 変数が、組込み型で、かつ引数が定数でないときに括弧を使うとエラーになるようだ。 g++ では、エラーにならないので、VC++ のバグだと思う。
あと、デフォルト引数の指定でも、「=」は OK だが、括弧は使えない。 これは仕様である。はっきりしているのは、初期化ではどちらか一方だけ使っては 書けないということである。しょうがない。使い分けるようにしよう。 通常は、組込み型は「=」とし、ユーザ型は括弧にするかな。

00/09/19(火)

00/09/20(水)

結局、レビューでは、コンパイル工程は、コーディング工程に含めることになった。

00/09/21(木)

C++ とは関係なかったな。

00/09/22(金)

定義
「過去使用したコードを再び使用すること。再利用のための情報は更新管理ができなければいけない。」

更新管理ができないもの（例：標準ライブラリ、商用ライブラリ）は、 いわゆるライブラリでありここでは再利用とは言わない。

再利用情報は、手を加えずにそのまま利用できれば、最も利用しやすい。 フレームワークなどは、追加修正することが前提となる。
再利用される情報は、保守性が高くなっているべきである。

再利用方法 ＼ 領域	部品 ボトムアップ	全体(フレームワーク) トップダウン
派生 (パターン)	コントロールなど	MFC のドキュメント・ビューなど
テンプレート	STL, ATL など	あまりない
その他 そのまま使う	非常に多い	使いやすいものは少ない

使用する領域は、部品か全体かに分かれる。基本的には部品の方が多い。全体を再利用することは 非常に困難である。全体の再利用には、VC++ の CustumWizard が便利である。 部品としてのコントロールの再利用にはコンポーネントギャラリが便利である。
再利用方法には、大きく分けると派生、テンプレート、その他に分けられる。 派生とテンプレートは独立の関係であるから、両方の方法を利用しているケースもあるだろう。 しかし、派生による再利用とテンプレートによる再利用は思想が異なっており、 一般には両方用いられることは少ない。そのまま利用できるものは、その他としているが これが最も多いであろう。しかし、そのまま利用するものは、柔軟性に欠けることが多い。
利用形態としては、サンプル集などのデータベース形式のものや、ウィザード形式のものがある。 何れにしろシステムとなっていないと、再利用の効果は半減する。

再利用データ

再利用データの更新 ←――――――――― ―――――――――→ 再利用

設計者 ユーザ

• 保守性は全ての工程で考慮しなければいけない。
• 再利用は次期プロジェクトの設計で考慮される。

最初から再利用可能に作成することは、非常に困難である。 可能なのは保守性を高くすること（修正が容易になるように作ること）だけである。 再利用するために、どのように設計しなければいけないかは、 再利用が必要になった段階でようやく分かるものである。

00/09/25(月)

さて、C++ の話でもするか。C しか知らない人に C＋＋ の参照を説明するのに、 どのようにしたらいいだろうか？
基本的にポインタに似た概念である。ポインタと比較しながら 違いを説明しようか。大きな違いは、初期化が必ず必要であり、 参照先を変更することができないというところであろうか。 派生クラスから基底クラスへの変換や、非const から const に変換できる ところは、ポインタと同じである。簡単に言えば「参照とは別名である」。

ところで、（たしか）Ruby では、変数のスコープを表すのに変数名の前に記号を つけることになっている。私も g_、s_、m_みたいなものを付けている。 これは、非常によい仕様だと思う。ついでに、参照も何か記号をつけると良かったかもしれない。 よくバグの原因になるのが、参照のつもりなのに & を付け忘れてコピーしてしまっていることがあるからだ。

00/09/26(火)

テキストファイルに限った話をすると、コメントが書けるというメリットがある。 （バイナリで書いても問題はないがあまり使うことはないだろう。そうともいえないかな。） これが、結構重要に感じられる。ファイルのデータを使用するにつれ、 変更することがあるだろう。通常では、単に変更するだけである。 構成管理をきちんとしていれば変更情報も別に記録していることもあるだろう。 しかし、記録するのに最も適しているのは、そのデータそのものである。
1次データから2次データをファイルに作成しているケースで、 2次データを変更したとする。後で、1次データと比較して変更されている のは分かったが、なぜ変更されているのか分からないことがあった。 このとき、データそのものに変更履歴や変更理由が欲しいと思った。
プログラムにも変更履歴などを書く習慣（ルール）があるところも多いであろう。 私は、基本的にプログラムはシンプルなものを好むので、コメントは極力書かない。 しかし、後で見たときに理由がわからなくなりそうなところには、やはりコメントを残すようにしている。

コメントは本来の動作に不必要なものであるが、データファイルやプログラムソースに限らず、 付けるようにしておくべきであろう。

00/09/27(水)

あと、初期化の話で、「組込み型かユーザ定義型か」でわけていた。 他の方法として、コピーコンストラクタを呼ぶ場合は「=」を使い、 それ以外のコンストラクタでは括弧を使う、というのでもいいかもしれない。 ふと、思っただけでそんなに根拠はない。

00/09/28(木)

00/09/29(金)

00/10/02(月)

• 有向か無向かのフラグを持たせる。コンストラクタで設定。
• add_arc では、そのフラグを見て、有向なら1本、無向なら2本入れる。
• 無向グラフは、i系とo系が同じになる。（冗長だけどまぁいいか？）

00/10/10(火)

さて、最初の納得いかないところ

• オーバライドする関数は仮想にすべき(項目37)

しかし、これは Effective C++ の原則に反している。Effective C++ の原則は、非常に すっきりしており説得力もある。さて、では何がいけないのだろう。 理由を考えていると、ようやく分かってきた。そもそも、関数オブジェクトを派生している ところがまずいようだ。基底クラスでは共通部分をくくり出していたのだが、 よくよく考えてみると、基底クラスは派生クラスで実装として使っているようだ。 つまり、is-a の関係でないようだ。ここを派生にしているから原則に合わなくなっているようだ。 逆に言えば、基底クラスをユーザに提供しない（公開したくない）場合は、 実装を提供することになるので、派生関係にすべきでないということだろうか。 結局、原則は正しいという結論になった。（私の負け）
言い訳がましいかもしれないが、件のクラスは後輩が作ったやつである。（その後輩はもういないけど。）

実装としての私的派生についての私の考えは、またの機会に書こう。

00/10/11(水)

• 公開派生は is-a であること(項目35)

「長方形クラスから正方形クラスを派生」させても何の問題もない。 （但し、普通は派生関係にしない方がよい）
では、例題のどこがおかしいのだろうか？それは、 「正方形は横幅だけ自由に変えられる長方形であるから、...」といっているところだ。 ここでもう is-a 関係が崩れている。長方形クラスに makeBigger を使用できるといっているのは、 「横幅だけ自由に変えられる長方形」といっているのと同じことである。 さて、お分かりだろうか？例題では、もともと is-a 関係にないものを公開派生にしているからおかしいのだ。

もう１つ、例題を出してみよう。 中学生は人間である。よって、中学生クラスを人間クラスから派生させてみよう。但し、 人間クラスは自由に年齢の設定ができるものとしよう。また、中学生クラスの 年齢は 13歳から 15歳までとしよう。（現実には正しくないが便宜上）
そうすると、やはりおかしなことになってしまう。これも同じく、 「年齢制限のある中学生」が「年齢の自由に設定できる人間」ではないのに、 派生させているからである。私の言いたいことは次の通り。

• 公開派生は is-a であること。また、is-a 関係は公開派生であらわすことができる。 （但し、派生がベストかどうかは定かでない）

00/10/12(木)

• 派生クラスでデフォルトパラメータを変更してはいけない(項目38)

struct A {
  virtual void f(int i = 0);
};

なんて書くよりは、

struct A { virtual void f(){f(0);} virtual void f(int i); };

こう書いた方がいいんではということである。 ふと、思っただけでいつもこうしているわけではない。

もう１つ。
デフォルト引数を持つ関数ポインタなどを使うときは引数を忘れないようにしないといけない。 デフォルト引数とは、引数を省略した時にコンパイラが補完してくれる機能であり、 関数ポインタを通すと機能しない。

void f(int = 0){} int main() { void(*pf)(int) = &f; (*pf)(); // NG }

このときは、bind などが有効かもしれない。

00/10/13(金)

• #define は使わないようにしよう(項目1)

今回は、私の良く使う例を１つあげてみる。 20ぐらいの項目毎にソートする機能を持つ GUI アプリケーションを考えてみよう。 ソートはメニューから呼び出すようにしよう。つまり、メニュー項目が 20 あるとしよう。 実際にソートする関数は、DoSort(int type) を使えるものとしよう。 私は、このハンドラを書くときいつも次のようにしている。

#define VIEW_SORT(i) void CXXXView::OnViewSort##i() {DoSort(i-1);} VIEW_SORT(1) VIEW_SORT(2) VIEW_SORT(3) ...

ハンドラのプロトタイプは決まっているから、DoSort を直接呼ぶわけにはいかない。 従って、20個の関数を書かなくてはいけないが、中味はほぼ同じである。 かといってテンプレートも使えない。こういうときは、マクロが便利である。

話は変わるが、EC++ の項目1 に以下のような記述をできないコンパイラは古いと書いてあるが、 本当なのだろうか？VC++6 はまだできないけど。

struct A { static const int i = 0; };

g++ ができるのは知っているが、 てっきり g++ の拡張機能だと思っていたのだが。

00/10/16(月)

• iostream を使おう(項目2)

この問題は、個人で開発しているときは「好き嫌い」で済むが、 チームで開発しているときは統一しないといけない。 現在のところ、私は cstdio を使うことで統一したいと表明している。 いずれは iostream に移っていくだろうが、まだまだ先のような気もする。

00/10/17(火)

• 基底クラスのデストラクタは仮想にしよう(項目14)

00/10/18(水)

• 公開メンバはやめよう(項目20)

簡潔に言えば以下の通りである。

• なるべく簡潔に書こう
• 再設計を怖れるな

00/10/19(木)

• 使えるときは必ず const を使おう(項目21)

• const を積極的に使う
• const を積極的に使わない

00/10/20(金)

• ダウンキャストはやめよう(項目39)

00/10/23(月)

• 私的派生はよく考えて使おう(項目42)

次に、仮想関数を上書きしたい場合も派生せざるをえない。しかし、これも同じである。 私的派生はすべきでないのである。公開派生してそれをメンバに持てばいいのである。 いずれにしろ私的派生は必要ない。（ちょっと過激に言えば、C++ の言語仕様から 取り除くべきだろう）

重要なことは、「実現できるからクラスを作るのではなく、 どういう役割を期待してクラスを作るかである。」

ちなみに、私は限定メンバの使用には反対である。限定メンバ関数なら問題ない。 理由は friend と同じく、クラスに穴を開けるからである。 （公開メンバは許容しているんだけどね）

00/10/24(火)

  class String
    def size
      1
    end
  end
  print "test".size

プログラムを動的に作成したいときは、かなり便利かもしれない。
あとは Ruby本が判りにくい。でも、Perl よりは好きになれそうである。 Perl には美しさを感じない。Ruby は全てとは言わないが、美しさがある。 でも、今後も流行るのは Perl なんだろうね。

00/10/25(水)

• Prolog
• PostScript
• C++

3つ目の C++ が難しい言語であることは、言語仕様書のページ数からも言える。 この続きは、また後にするか。

00/10/26(木)

Lisp はトップダウン開発に向いている。 C++ はどちらかと言えば、ボトムアップ向きだろうか。 （とはいえ、デザインパターンやフレームワークの支援を 受ければ、C++ でもトップダウン開発しやすい。） これらの向き不向きは、変数の型の制約がゆるいかきついかによってくる。 しかし、大規模プログラムには型制限のきつい方がいいと思う。
私がどちらかと言うと重視しているのは、実行スピードである。 そうでなければ、アセンブラをやったりはしなかっただろう。 Lisp をやめて C に移行したのもスピードのせいである。 同じ機能のプログラムで、Lisp は C より 2 桁は遅いであろう。
これと同じ理由で、私は Java を使う気になれない。 「Java は十分速くなった」という主張をよく見かけるが、 あるアルゴリズムを C++ から Java2 に移植したが、スピードは 1/7 になったことがある。 プログラム自体はほぼ対応しているので、アルゴリズムが変わったわけではない。
C++ のプログラムを Java に移植する時に感じたのは、 テンプレート機能が使えないことの不便さであった。 しかし、今、Ruby を使っていてテンプレート機能を欲しいとは思わない。 なくても、なんでもできるからだ。変数にどんな構造でも入れられるし、 型なぞ気にすることなく、メソッドが呼べる。 そういう意味では、Java は中途半端である。 コードに不自由さが現れてしまう。
スクリプト言語の氾濫や C# が出たことで、プログラミング言語が これからどうなっていくのかよくわからない。 C/C++ はこれからもメジャーであり続けるのか？
本音を言えば、 「日本語でプログラミングできるようになって欲しい」 そしたら、プログラマは要らなくなるか。

00/10/27(金)

今まで、Ruby で作ったのは、離散系シミュレータと 会議室予約システム のCGI。どちらも大したものではない。 ここまでの感想は、やはり「リファレンス欲しい」である。 新しい本が出たようだし、また買ってみるか。
今のところ、「どっか書いてなかったかな」と 本や Web を探しすのだが、見つからない。 結局、methods や instance_methods を 見たり、ライブラリやサンプルを眺めたりして探している。
UNIX 使ってたころは、awk の小さいスクリプトをたくさん 作っていたが、Windows になってからは command.com は 使えないし、さっぱり作ってない。 フリーの Windows 用 awk とかはあるけど、awk だけが 便利なのではなく UNIX 全体として便利だったので、 どうも Windows で awk とか使う気にはならなかった。 Perl5 も本買って読んだものの、「何だこりゃ」と思って使ってない。 Ruby の感想は高級おもちゃってところかな。 ちょっとしたものなら、Ruby が便利そうである。 （前に、C++ で作った、XXX.zip を XXX1027.zip のように ファイルに日付を追加する奴とか）
C++ による OOP と Ruby による OOP は雰囲気が変わってくる。 Ruby の方が OO らしいのだろう。そこには、型は気にされない。 メソッドだけが気にされる。メソッドがなければ、例外が飛んでくる。

00/10/30(月)

「C++ プログラミング所感」の読者の方からメールを貰った。 私的派生を使った方がよいという例だ。 （以下のプログラムでは、メールから引用させてもらっている）

template <class T, int N> class MyArray { T data[N]; public: MyArray() {} // (1) };

このような固定長の配列のクラスがあるとしよう。 （このクラスは例なので、ここまでは「クラスがありき」とする。）
問題は、T 型の配列 data を T が組込み型の場合に 0 クリアしたい。 ということである。(1) のコンストラクタでやってしまうと T がユーザ型ではまずい。T のコンストラクタの処理の前に する必要がある。
貰ったメールでの解答は

class ZeroCleared { public: ZeroCleared(char* begin, char* end) {for ( char* p = begin; p < end; *p++ = 0) ;} }; template <class T, int N> class MyArray2 : private ZeroCleared { T data[N]; public: //ベースクラスのコンストラクタは派生クラスのデータメンバの //構築に先立って実行される。 MyArray2() : ZeroCleared((char*)data, (char*)(data + N)) {} };

このようにすれば、

• data のメモリ確保
• data の 0 クリア
• data のコンストラクタ呼び出し

template <class T, int N>
class MyArray3 {
    ZeroCleared zero;
    T data[N];
public:
    MyArray3() : zero((char*)data, (char*)(data + N)) {}
};

このときの違いは、MyArray3 では、MyArray2 より、メンバ zero の分だけ サイズが大きくなってしまうことである。 ZeroCleared のサイズは 1 だけどパディングのせいで 4 とか 8 バイト無駄にするかもしれない。 確かにこのときは私的派生の方がよい。（一本取られた。）

他にいい方法はないだろうか。

template <class T, int N> class MyArray4 { T data[N]; public: MyArray4() {} MyArray4(const T& t) // data を t で初期化 };

初期化させるというのであれば、このようにして、2種類の コンストラクタを用意することもできるだろう。 （自分で呼ばないといけないけど）
また、組込み型用にはテンプレートの特別バージョンを作って対応するというのもあるかもしれない。 (たくさん、作る必要があると面倒だけど)

00/10/31(火)

namespace  private_built_in_check_space {     //ヘルパ
    class POD_checker{};
    template <class T> inline
    POD_checker*& operator,(POD_checker*& pE, T&){return pE;}
};

//Plain Old Data型の引数だけをゼロクリアするテンプレート関数
template <class T>
void POD_ZeroInitialize(T& arg)
{
    using namespace private_built_in_check_space;
    POD_checker* pE = 0;
    (pE, arg) = 0;    //コンマ演算子オーバーロード！
};

さてさて、私はこのプログラムを実際に VC++6.0 と g++2.95.2 で 動かして、POD_ZeroInitialize が組込み型だけ 0 クリアしていることは 確認できた。しかし、原理は分からなかった。 考えても分からないので、原理も教えてもらった。簡単に言えば、 テンプレート引数が組込み型の時に、カンマ演算子などの2項演算子は エラーにならずに無視されるということであった。
例えば、int operator+(int,int) は定義できない。 これと同じく、T operator+(T,T) は T が int のときには、マッチしない。 （テンプレートは奥が深い）

結論：組込み型とユーザ型を区別することはできる

00/11/01(水)

• 大容量
• たいていの PC で使える
• 信頼性が高い
• 繰返し使え(CD-RW の場合)、コストパフォーマンスがよい
• 嵩張らない

小さなシステムであれば FD(フロッピーディスク)でよいが、 最近では 1.4Mb で収まらないことが多い。 （CD-R は一応 650Mb といっているが、620Mb ぐらいに見ていた方がいい。）
次に重要なのは、どこでも使えるということであろう。 この理由から MO よりは CD-R を選ぶことが多い。
次に信頼性が高いことも重要である。 FD で納品していたときは、万一のためにいつも同じものを 2つ用意していた。 FD だと数年で読めなくなる確率も高い。 （但し、CD-ROM は半永久的に持ちそうな気もするのだが、実際の耐用年数は 保管場所にもよるが 20年ぐらいだと聞いたことがある。）

次のコストパフォーマンスもかなりいい。最近、10枚 580円で買ったのだが、 1Mb が 0.1 円以下である。
次に嵩張らない。これ故、雑誌の付録になっているくらいである。
以前の納品では、1/4 inch カートリッジが主流であった。そのときのメディアは 今でも残しているが、場所を取っている。

納品だけでなく最近ではバックアップにも用いている。 まさに CD-ROM は大氾濫している。私は、CD-ROM がこんなにメジャーに なるとは思わなかった。MO の方がもっとメジャーになると予想していた。 （書き込みできるから）
しかし、この予想は完全に間違っていた。

00/11/02(木)

• 1/4 inch カートリッジをデバイスに入れる
• % make tape と打つ

00/11/06(月)

00/11/07(火)

ちなみにエラーメッセージは次のようになっていた。

./sim.rb:17:in `<=>': undefined method `<=>' for #<Proc:0x457fb40> (NameError)
        from ./sim.rb:17:in `<=>'
        from ./sim.rb:17:in `sort!'
        from ./sim.rb:17:in `sched'
        from mm1.rb:44:in `Create'
        from mm1.rb:44:in `Create'
        from mm1.rb:44:in `call'
        from ./sim.rb:23:in `start'
        from mm1.rb:56

    @stack.sort!

    @stack.sort!{|i,j| i[0] <=> j[0]}

00/11/08(水)

bool f1(int c)
{
  return c >= 0x81 && c <= 0x9F || c >= 0xE0 && c <= 0xFC;
}

bool f2(int c)
{
  return c >= 0x81 && (c <= 0x9F || (c >= 0xE0 && c <= 0xFC));
}

 case f1                         case f2
00401000   mov   eax,       |   00401000   mov   eax,
        dword ptr [esp+4]   |           dword ptr [esp+4]
00401004   cmp   eax,81h    |   00401004   cmp   eax,81h
00401009   jl    00401012   |   00401009   jl    00401026
0040100B   cmp   eax,9Fh    |   0040100B   cmp   eax,9Fh
00401010   jle   00401020   |   00401010   jle   00401020
00401012   cmp   eax,0E0h   |   00401012   cmp   eax,0E0h
00401017   jl    00401026   |   00401017   jl    00401026
00401019   cmp   eax,0FCh   |   00401019   cmp   eax,0FCh
0040101E   jg    00401026   |   0040101E   jg    00401026
00401020   mov   eax,1      |   00401020   mov   eax,1
00401025   ret              |   00401025   ret
00401026   xor   eax,eax    |   00401026   xor   eax,eax
00401028   ret              |   00401028   ret

00/11/09(木)

• stdafx.h で 「MFCの拡張部分」の下に「#include <afxdisp.h> // MFC のオートメーション クラス」
• CXXXApp::InitInstance の一番最初に「AfxEnableControlContainer();」

00/11/10(金)

えらくまわりくどいが、私はこの内容に賛成である。 では、年頭の原発の2000年問題への怒りの原因は何であろうか。 それは、「口にしたことへの責任感のなさ」である。
できないことは、きちんとできない（またはしない）と言って欲しいものだ。 （とはいえ、自分にも当てはまるのだろう）

00/11/13(月)

この Karmarkar 法はその後、アルゴリズム特許で世間に知られるようになった。 ついでに次節も挙げよう。

60Kbyte って何行だろう。覚えてない。1000行ぐらいかな。 もっと書いたような気もするけど。 機能的には、入力ファイルとして当時標準だった Lindo のフォーマットを 扱えるようになっている。また、計算部分も疎行列を fill-in（ゼロ要素が非ゼロ要素になること）が少なくなるように 扱っており、出力もラスターファイルや PostScript で結果を出力できるようになっている。 （出力された図をそのまま Latex に組入れられる） 計算部分のパラメータ数 20 より、実行プログラムのオプション数 23 の方が多い。 自分で言うのもなんだが、結構、多機能である。 計算実験でもスピード、精度ともに、前述の OB1 と互角であった。 （ちなみに、当時 OB1 は AT&T から億単位の値段で売られていたと思う。）
このプログラム YODA も今はどっかいってしまってない。ちなみに、OB1 とか YODA は 映画 STAR WARS から来ている。

C で書くと何百行になる内点法のプログラムも、Mathematica で書くと わずか 20行ほどである。当時、C プログラムの検証に Mathematica を使っていた。 このように、スクリプト言語はアルゴリズムの本質を記述するのに便利である。 （Mathematica はスクリプト言語ではないけど） Mathematica の場合、行列演算が数式そのままに書けたのが便利であった。
現在、良く使われているスクリプト言語は、文字列処理、特に正規表現が便利であり、 １つの特徴になっている。おそらく、今後も進化しより使われるのではないだろうか。

00/11/14(火)

• プログラム a.cpp を書いて F7 を押す。
• a.cpp が保存される。
• a.cpp がコンパイルされ a.obj ができる。 但し、1秒以内なので a.cpp と a.obj の時刻が同じ。

00/11/15(水)

s = 0
100.times do
  i = 0
  d = 0
  loop do
    i += 1
    d = rand
    break if d == 0
  end
  s += i
end
p s / 100

上のようなプログラムで確認したところ、平均3万2千回ぐらいで、 0 が発生している。約半分のところで出るとすると、1/2^16 の確率だ。 元が short（2バイト）なのだろうか。 どうりで、10万単位時間も流すと同じ時刻が発生するわけだ。 ううむ、どうにかして欲しいなぁ。このままだと、大規模な シミュレーションには Ruby 使えませんねえ。

00/11/16(木)

00/11/17(金)

さて、最近ツリー形式のエディタを使うようになったのだが、 結構便利である。 で、思ったのが、ツリー構造っていろいろな所で使えるということである。
一般的にはネットワーク構造なのかもしれないが、 現実的には、ツリーとして捉えられるものが多いと思う。 （ツリーはグラフでサイクルがない構造。 とはいえ、関連しているものを紐付けしたいことは、 よくあるので、ハイパーリンクは欲しいところである。）
例えば、プログラムソースもツリーと見て取れる。 （実際に書いてみたりもしたが、「}」の位置に違和感が残る。） （goto いっぱいのスパゲッティはツリーじゃないかもしれないけど、それは論外）
XML もそうかなぁ。まだ、よく知らないんだけど。 ドキュメント類は、ツリーが多いと思う。

C++ の汎用テンプレートツリークラスでも作るかな。時間ないけど。

00/11/20(月)

それはさておき。サーバにメールがあるかどうか確認する プログラムを作りたいと思っていた。フリーでも転がっているけど、 自分で書いてみたかったのだが、よくわからなくて調べる暇もないので ほっておいていた。
たまたま、雑誌に Ruby の記事があったので、それを参考に Ruby で自分でも作ってみた。 実に簡単である。メールがあったら、メーラが起動するようにしておいた ところ頻繁に ML が来るのですぐ起動してしまう。 それで、その ML だけ無視するように直した。 こんなのも簡単に書けてしまうから便利である。プログラムは次の通り、

require 'net/pop' pop = Net::POP3::new('mail') loop do loop do n = 0 pop.start('tsutomu','XXXX'.unpack('m')[0]) do pop.mails.each do |i| n += 1 if /ruby-list/o !~ i.header end end break if n > 0 sleep 300 end system('C:\\Progra~1\\EUDORA\\Eudora.exe') end

ちなみに、頻繁に来る ML は 上を見て分かるように Ruby の ML である。
とりあえず、パスワードは一瞬見てもわからないように、pack しているが、危険と言えば危険。

00/11/27(月)

VC++ で SIS の OCX を使っていると「デバッグサブシステムの初期化エラー」とか 出たりすることがある。原因はよくわからないが、一度、直接 exe を起動すると直ったりする。

前へ 目次 次へ