アカウント名:
パスワード:
これってC++で言うところのTemplateと同じものと考えてOK? それとも違う?
違います。 C++のテンプレートってのは「型紙」で、パラメータを与えることでコンパイル時にコードを展開(インスタンス化)する。別の型をパラメータに与えて使う場合はその型用のコードがインスタンス化される。基本的には文字列操作(マクロ展開)のようなイメージ。 Javaのgeneric typeは、パラメータ型ごとにインスタンス化されるわけではない。生成されるコードは1つだけ。 生成されるバイトコードで実行時に型チェックをするコードが含められたりするわけではないの
もともとC++のテンプレートはgeneric typeに相当するものを速度を犠牲にすることなく実装しようとして考え出されたものでしょう?generic typeとかtype polymorphismとかの話は関数型言語の世界では古くからあって、C++もそれを取り込みたかったわけ。でも速度は犠牲にしたくなかったから、テンプレートでマクロ展開っていう方向性になって、使い勝手は悪くなった。一方、JavaはSMLなどの関数型言語も十分考慮されて設計されたけれど、取りこぼしもあって、それを今やろうとしているだけだと思う。
だから言
もともとC++のテンプレートはgeneric typeに相当するものを速度を犠牲にすることなく実装しようとして考え出されたものでしょう?
C++にコレクション(コンテナクラス)機能を追加する際に、Smalltalk流にObjectを経由した抽象操作でやる、という選択肢は確かにありました。
これは実際にTools.h++で使われている方式(Smalltalk_likeコレクション) [s34.co.jp]です(オプションですけどね)。 このような方式がC++の標準ライブラリに採用され得なかった理由は、効率のこともあるけど、第一義にはそうするとC++じゃなくなるからです。 上のTools.h++のコンテナにはRWCollectableを継承したオブジェクトしか入れられませんし、かつそれはヒープから確保したものである必要があります(厳密にはそうじゃなくても入れられるけどremoveできなくなる^_^)。つまりスタック上のオブジェクトや静的・大域オブジェクト、あるいは何かの演算の結果得られる一時オブジェクトを実質的に使えないということです。
こんなことでC++と呼べるんでしょうか! GCがあれば、格納できるオブジェクトの記憶クラス制約の問題は解決するでしょうが、それもひとつのもっとC++ではない道です。
ポインタでオブジェクトをハンドルするのではなく、コピーコンストラクタを定義した値オブジェクトを自在に駆使することがC++の真髄です(と「Effective C++」に書いてあるし好き嫌いは別としてそのとおりだと思う)。
つまりC++には値オブジェクトをコンテナに値で格納したい、という強い願いがあるわけです。これにC++が固執しているセントラルドグマ「ユーザ定義クラスをintもdouble などの基本型と同様に扱える」ということと考え合わせると、コンパイル時に展開するしかなくなる。なぜなら値オブジェクトを格納するコンテナへの要素の格納は、intの場合変数の代入(bitwise copy)であるし、キャスト演算が生じるかもしれないし、コピーコンストラクタの呼び出しが起きるかもしれない。 それを実行時に切り分けるわけには効率上いかないのです。(ただ逆にこうしたことで多相性は犠牲になるしスプライシングの問題も生じます。純粋オブジェクト指向信望者にとっては許しがたい悪業ざんまい..。)
まあ追求すると速度の問題じゃん、ということなんだけど、 そこにまで到達する前の段階でC++のアイデンティティの問題に基づく、不可避の必然がある、と。これを抜かしちゃ話にならない。
SML/NJやHaskellを使った上での感想として言えば
JavaはSMLなどの関数型言語も十分考慮されて設計されたけれど、取りこぼしもあって、それを今やろうとしているだけだと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
generic type (スコア:0)
これってC++で言うところのTemplateと同じものと考えてOK?
それとも違う?教えて、エライ人。
Re:generic type (スコア:1, 参考になる)
違います。
C++のテンプレートってのは「型紙」で、パラメータを与えることでコンパイル時にコードを展開(インスタンス化)する。別の型をパラメータに与えて使う場合はその型用のコードがインスタンス化される。基本的には文字列操作(マクロ展開)のようなイメージ。
Javaのgeneric typeは、パラメータ型ごとにインスタンス化されるわけではない。生成されるコードは1つだけ。 生成されるバイトコードで実行時に型チェックをするコードが含められたりするわけではないの
Re:generic type (スコア:0)
もともとC++のテンプレートはgeneric typeに相当するものを速度を犠牲にすることなく実装しようとして考え出されたものでしょう?generic typeとかtype polymorphismとかの話は関数型言語の世界では古くからあって、C++もそれを取り込みたかったわけ。でも速度は犠牲にしたくなかったから、テンプレートでマクロ展開っていう方向性になって、使い勝手は悪くなった。一方、JavaはSMLなどの関数型言語も十分考慮されて設計されたけれど、取りこぼしもあって、それを今やろうとしているだけだと思う。
だから言
Re:generic type (スコア:1)
C++にコレクション(コンテナクラス)機能を追加する際に、Smalltalk流にObjectを経由した抽象操作でやる、という選択肢は確かにありました。
これは実際にTools.h++で使われている方式(Smalltalk_likeコレクション) [s34.co.jp]です(オプションですけどね)。
このような方式がC++の標準ライブラリに採用され得なかった理由は、効率のこともあるけど、第一義にはそうするとC++じゃなくなるからです。 上のTools.h++のコンテナにはRWCollectableを継承したオブジェクトしか入れられませんし、かつそれはヒープから確保したものである必要があります(厳密にはそうじゃなくても入れられるけどremoveできなくなる^_^)。つまりスタック上のオブジェクトや静的・大域オブジェクト、あるいは何かの演算の結果得られる一時オブジェクトを実質的に使えないということです。
こんなことでC++と呼べるんでしょうか!
GCがあれば、格納できるオブジェクトの記憶クラス制約の問題は解決するでしょうが、それもひとつのもっとC++ではない道です。
ポインタでオブジェクトをハンドルするのではなく、コピーコンストラクタを定義した値オブジェクトを自在に駆使することがC++の真髄です(と「Effective C++」に書いてあるし好き嫌いは別としてそのとおりだと思う)。
つまりC++には値オブジェクトをコンテナに値で格納したい、という強い願いがあるわけです。これにC++が固執しているセントラルドグマ「ユーザ定義クラスをintもdouble などの基本型と同様に扱える」ということと考え合わせると、コンパイル時に展開するしかなくなる。なぜなら値オブジェクトを格納するコンテナへの要素の格納は、intの場合変数の代入(bitwise copy)であるし、キャスト演算が生じるかもしれないし、コピーコンストラクタの呼び出しが起きるかもしれない。 それを実行時に切り分けるわけには効率上いかないのです。(ただ逆にこうしたことで多相性は犠牲になるしスプライシングの問題も生じます。純粋オブジェクト指向信望者にとっては許しがたい悪業ざんまい..。)
まあ追求すると速度の問題じゃん、ということなんだけど、 そこにまで到達する前の段階でC++のアイデンティティの問題に基づく、不可避の必然がある、と。これを抜かしちゃ話にならない。
Re:generic type (スコア:1)
>ポインタでオブジェクトをハンドルするのではなく、コピーコンストラクタを定義した値オブジェクトを自在に駆使することがC++の真髄です
(中略)
>純粋オブジェクト指向信望者にとっては許しがたい悪業ざんまい..。)
あはは。ほんとOO信奉者には許し難いです(^^;
OO信者は、同値性と同一性が(プログラマの(笑))任意の時点で自在に使い分けられないと…
つまり同一性をとことん殺さず維持してないと…腹下しちゃいますからねえ。
値Objectなんてな概念には塩まきます。#それが自分の利益を損ねようとも(笑)
ただ、
>C++が固執しているセントラルドグマ「ユーザ定義クラスをintもdouble などの基本型と同様に扱える」
ここでいう「同様」に、やっぱり一抹の疑問を感じるです。
Rubyの短い整数みたいなヤリカタでいいじゃんというか、
intのように「ビット単位で」いじり倒せるってのが本当ならば、なんでVMTポインタをいじらせんのじゃ?とか(藁)、
なんか釈然としない点が一杯。
#問題が問題を呼ぶんで、言語仕様が結局「あの巨大さにならざるを得ない」、ってのは痛い。
そう考えると、少々ヘボくても、モデルがすっきりしてる参照オンリーな言語のほうが、
腹の健康のためには数倍よろしいです。