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

99/1/18(月)

    void fc(char&){}
    void fi(int&){}
    int main() {
        signed char   sc;
        unsigned char uc;
        signed int    si;
        unsigned int  ui;
        fc(sc);            // (1)
        fc(uc);            // (2)
        fi(si);            // (3)
        fi(ui);            // (4)
    }

答えは、(3)以外全部である。

char が signed か unsigned かは処理系定義である。int は、signed である。 従って、正しい呼出しは、(3) だけである。 なになに、「(1) か (2) のどちらかは正しい筈だ」って？ 確かに、VC++ では char は signed である。でも、VC++ で fc(sc); はエラーだ。 他の処理系に持っていって始めてエラーになるよりは、予めエラーになっている方が いいに決まっている。

結局、char は 3種類あるが、int は 2種類しかないのだ。 つまり、「signed int」と書く必要は全くない。

ちなみに、上のプログラムで main に return を書かなかったのは わざとである。理由は、件の本の§3.2 を見て欲しい。

99/1/20(水)

• メンバの場合、変数名で参照する。派生の場合は、クラス名か this で参照する。
• ユーザからは派生関係にないが、メンバ関数内では派生関係にある。従って、

  Derived d; Base* p = &d;

  は、メンバ関数内で有効である。（但し、Base は実装を規定したクラス。 Derived は、Baseから私的 or 限定派生したクラス。）
• 私的（限定）派生であっても、上のように部分的とはいえ、派生関係である。 従って、ポリモーフィックに影響を与える。

ケース1
#include <iostream>
using namespace std;

struct Base {
    virtual ~Base(){}
};
struct D1 : private Base {
    virtual ~D1(){}
};
struct D2 {
    virtual ~D2(){}
private:
    Base b;
};

int main()
{
    cout << sizeof(D1) << endl;
    cout << sizeof(D2) << endl;
}

この例では、D2 の方が D1 よりオブジェクトのサイズが、 仮想関数テーブルのポインタ（以下、vfptr）1つ分大きくなる。 これは、D1 が vfptr を１つしか持たないのに、D2 は2つ持つからである。

ケース2 #include <iostream> using namespace std; struct Base { ~Base (){} }; struct BaseV {virtual ~BaseV(){} }; #define TEST_DEF void test(){cout << typeid(*this).name() << endl;} struct Derived : private Base {TEST_DEF}; struct DerivedV : private BaseV {TEST_DEF}; struct MoreDerived : public Derived {}; struct MoreDerivedV : public DerivedV {}; int main() { MoreDerived d; MoreDerivedV dv; Derived* p = &d; DerivedV* pv = &dv; p ->test(); pv->test(); }

この例では、pv->test() は、正しく機能するが、p->test() は機能しない。 何故なら、typeid は仮想関数を持つクラスでないと利用できないからである。

結局、私的（限定）派生であれ、派生に伴う制約を受ける。 例えば、複数の機能を利用する場合、派生で実現しようとすると多重継承になり兼ねない。 従って、派生よりはメンバで実現した方がすっきりするといえる。 私的 or 限定派生を使う必要はないと思う。

参考00/10/23の話

99/3/3(水)

例としては、

struct B { void f(int){} }; struct D : B { void f(char*){} }; int main() { D d; d.f("A"); // OK d.f(1); // NG }

今まで、f(1) は OK と思っていた。

結論 − オーバロードされている関数群の1つでも派生クラスでオーバライドしたら 全てオーバライドし直さなければいけない。(using B::f; などとしてもよい。)

99/5/24(月)

99/6/16(水)

x が x1とx2の間に入るかどうかを調べたいとする。 但し、x1 < x2 かどうかはわからない。方法としては、次のように2つ考えられる。

(x-x1) * (x-x2) <= 0 // (1) (x1 <= x && x <= x2) || (x1 >= x && x >= x2) // (2)

私は、(1)の方が分かり易くて好きだが、VC++でスピードを測ると (2)の方が、30%ぐらい速い。 しょうがない、(2)で書くことにしよう。 細かいことを言えば、(2)では、最大4回比較を行う可能性がある。(x1 == x, x2 < x)

次のように書けば、最大は3回で済む。

!((x < x1 && x < x2) || (x > x1 && x > x2))

最初の ! をとれば、次のように書ける。

(x >= x1 || x >= x2) && (x <= x1 || x <= x2)

これより次の様に書く方が比較回数が減る可能性がある。

x < x1 ? x >= x2 : (x <= x2 || x == x1)

全部計測してみたが、(1)以外はどれもスピードは変わらなかった。

99/6/17(木)

99/6/22(火)

話は変わるけど、自分のプログラミングの癖を見つけた。

99/6/25(金)

• min,max
• __min,__max
• _MIN,_MAX

99/7/19(月)

• 車両の表示
• 障害物として認識

99/7/21(水)

#include <vector>
int main()
{
	std::vector<int>>	i;
}

コンパイルエラーにならない！g++ はなるぞ。

99/7/23(金)

void f(int*){}
int main()
{
    f(false);
}

コンパイルエラーにならない！g++ はなるぞ。

99/9/8(火)

struct CDblPos : public pair<double,double>
{
  CDblPos(const double& a,const double& b)
    : pair<double, double>(a,b), x(first), y(second) {}
  CDblPos(const CDblPos& a)
    : pair<double, double>(a), x(first), y(second) {}
  CDblPos& operator=(const CDblPos& a)
    {x = a.x, y = a.y; return *this;}
  double&  x;
  double&  y;
};

最初、何だこりゃと思ったものの、よくよく見ると正しいし、理にかなっている。 恐らくこれが唯一の参照メンバ変数の正しい使用法だろう。
すなわち、「参照メンバ変数は、自分のメンバ変数のみ参照できる」こと。 この場合、参照メンバ変数は、単に呼び方を変えているにすぎないが、参照とはそういうものだ。
結局、次のように書ければ、C++ の仕様として望ましいと思う。

struct CDblPos : public pair<double,double> { CDblPos(double a,double b){x = a; y = b;} double& x = first; double& y = second; };

こうすれば、代入演算子も定義しなくて良いから、よけいなものを書かなくて済む。 まぁ、今のままの仕様の方がすっきりするけど。
5/15の話参照。

99/9/9(水)

  list<XXX>	i,j;
  i = j; // (1);
  i.clear(); i.swap(j); // (2);

もし、代入後の j の値を使わなければ、(1) でも (2) でもよいはずだ。 違いは、代入ではコピーコンストラクタが呼ばれるのに対し、 swap では、呼ばれないという所だ。だから、swap の方が速いと思われる。 実際に計ってみると、XXX が int では、代入の方が速いようである。 何故だかよくわからない。

今日は、９並びの日だ。そう言えば、一昨年は年号が９だった。

99/9/20(月)

99/11/1(月)

99/11/22(月)

• button.setBounds(...); を、Applet クラスで実行するときと、 別の関数で実行するときで結果が異なる。C++ のプログラムでは考えられない。
• addActionListener(new ActionListener(){public void actionPerformed(ActionEvent e){actionP();}});

  みたいなことが書けてしまう。分かりにくいと思うが、関数呼出しでクラスを定義してしまっているのである。
  さらに、納得いかないことに、actionP() は、CalcApplet のメソッドなのにエラーにならない。 （C++ ならば、actionPerformed が、CalcApplet のメンバでないとエラーになる。）

99/11/24(水)

前へ 目次 次へ