菅野といいます。

宗教論争に発展しそうなので気が乗りませんが・・・

> C の追加の規格で嫌いなものの一つ。めんどくさい時は、#define 
> const とかもやります。
(自分でコードを書く時の話だと捉えて)
constが追加されたのなんていつの話だよ;-(という突っ込みはさて置き
#define const
とやるぐらいであれば、初めから書かないべきでしょう。
ライブラリ等を利用する場合においては問題になることは無いはずですし、
constは付けなくても(ミスさえなければ)結果に変化はないわけですから。

> 大変さをプログラマに押しつけているだけなんじゃないの? 
constは押し付けではないわけですが、それはいいとして、
constをつける大変さよりもconstをつけていない場合の大変さの方がより
大きいというのが一般的かと思います。

典型的な例として
void foo(const char * const a)
{
    ...
    a = b;  // error.
    ...
    a[2] = '\0'  // error.
}
// error.
の部分がコンパイル時にチェックできるものがありますが、
何らかのバグが見つかった時、constがついていない場合は上記の部分まで
慎重に"人が"チェックしなければならないわけです。

＃まあこういった話はよく存じていらっしゃると思いますが。

厳密な型付けを求めるなら正に大変さをプログラマに押しつけることになる
と思います。

> 構造体のメンバにもconstとかを付けることも出来るし、const と 
> * の相互作用とかもあるから、const を導入したことで型の複雑さ
> は2乗になっていると思う。そこまで複雑にして得られるものは安
> 全性ではなく、多少のCPU資源の節約かぁ。

構造体のメンバにconstを付加するのはナンセンスだと思いますが、たしか
に型の複雑さは増していると思います。
CPU資源の節約は最適化時へのヒントとしての副次的な産物であって、あく
までも本来の目的は多少の面倒さと引き換えにバグの混入を予防することに
あると思います。
バグが無い＝安全という見かたもありますが、少しずれている気がします。
constは変更(＝代入)防止でしかなく、実行時の安全性にはあまり関係あり
ませんし。

> volatile も納得できないです。volatile の方は付けるか付けない
> かでコンパイルが通るかどうかではなくて、動作が変わってしまう。
> 型宣言で動作が変わるってのは、或る種の直交性を放棄している感
> じ。volatile ではなくて、明示的にオブジェクトの値を読み出す
> 演算子を用意した方が良いと思う。
演算子だと気持ち悪い気がしますが・・・。
関数だとオーバーヘッドがありますから、当時の、あるいは組み込み等の
プアな環境だと勿体無い気もします。関数の"ようなもの"として言語に組
み込んでおいてコンパイル時に展開すればいい事だとは思いますが。

そもそものCはリッチなアセンブリという性格が強いかったためにこのスタ
イルになったのではないでしょうか。コンパイラ自体も簡潔に、小さくす
るための措置の一つだと考えればvolatileの仕様も上記のような形式にな
っていないのも頷けます。

どちらにせよ、現在のPCのようなリッチな環境で考えればvolatileは負の
遺産と位置付けるのは間違ってはいないかと思います。

以上、あくまでも私の見解では・・・です。

> ちなみに塩山市って良くみるけど、どこにあるの?
山梨

--
菅野