アカウント名:
パスワード:
これってC++で言うところのTemplateと同じものと考えてOK? それとも違う?
違います。 C++のテンプレートってのは「型紙」で、パラメータを与えることでコンパイル時にコードを展開(インスタンス化)する。別の型をパラメータに与えて使う場合はその型用のコードがインスタンス化される。基本的には文字列操作(マクロ展開)のようなイメージ。 Javaのgeneric typeは、パラメータ型ごとにインスタンス化されるわけではない。生成されるコードは1つだけ。 生成されるバイトコードで実行時に型チェックをするコードが含められたりするわけではないの
もともとC++のテンプレートはgeneric typeに相当するものを速度を犠牲にすることなく実装しようとして考え出されたものでしょう?generic typeとかtype polymorphismとかの話は関数型言語の世界では古くからあって、C++もそれを取り込みたかったわけ。でも速度は犠牲にしたくなかったから、テンプレートでマクロ展開っていう方向性になって、使い勝手は悪くなった。一方、JavaはSMLなどの関数型言語も十分考慮されて設計されたけれど、取りこぼしもあって、それを今やろうとしているだけだと思う。
だから言語の使用者から見て、表面上の使い勝手(もしくはデバッグが完了したあとのソースコード)はほぼ同じ(テンプレートの方が「これはテンプレートだよ」って特別な宣言をしなきゃいけないだけちょっとだけ複雑になるかな)。ただし、デバッグのことを考えると、SML/NJやHaskellを使った上での感想として言えば、(テンプレートのようにマクロ展開のような変な形じゃなくて)ネイティブにサポートされるJavaのgeneric typeの方がずっと楽だし素直だと思う。結局テンプレートは表面上なんとか似たものを作ろうとしてるだけだからね。
「実行時エラー検査がコンパイル時に移っただけ」という表現が元コメントにあるけれど、それにこそ強い型付け存在意義があるわけで、「だけ」というのはかなり語弊があると思う。
もともと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)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
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などの関数型言語も十分考慮されて設計されたけれど、取りこぼしもあって、それを今やろうとしているだけだと思う。
だから言語の使用者から見て、表面上の使い勝手(もしくはデバッグが完了したあとのソースコード)はほぼ同じ(テンプレートの方が「これはテンプレートだよ」って特別な宣言をしなきゃいけないだけちょっとだけ複雑になるかな)。ただし、デバッグのことを考えると、SML/NJやHaskellを使った上での感想として言えば、(テンプレートのようにマクロ展開のような変な形じゃなくて)ネイティブにサポートされるJavaのgeneric typeの方がずっと楽だし素直だと思う。結局テンプレートは表面上なんとか似たものを作ろうとしてるだけだからね。
「実行時エラー検査がコンパイル時に移っただけ」という表現が元コメントにあるけれど、それにこそ強い型付け存在意義があるわけで、「だけ」というのはかなり語弊があると思う。
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ポインタをいじらせんのじゃ?とか(藁)、
なんか釈然としない点が一杯。
#問題が問題を呼ぶんで、言語仕様が結局「あの巨大さにならざるを得ない」、ってのは痛い。
そう考えると、少々ヘボくても、モデルがすっきりしてる参照オンリーな言語のほうが、
腹の健康のためには数倍よろしいです。
Re:generic type (スコア:0)
Tigerはいままで「総称性」が「制約付き総称性」になった という話です。
generic typeという名は不適切でSunが悪いんです。 「リフレクション」もそうだし。
Re:generic type (スコア:0)
Re:generic type (スコア:0)
Re:generic type (スコア:1)
「だけ」という限定は、限定しているだけで、価値判断をふくんでません。ここで例題です。
この文章から、岡野工業株式会社を軽く見ていたり、価値がないとか、作れても作れなくても大差ないとか、そんなことが読み取れますでしょうか。
あと、SmallTalkじゃなくて、Smalltalkね。ありがちなミスだけどね。
Re:generic type (スコア:1)
私が(ってACだったのだが) という言い方をしたのは、もと記事の投稿者も、あと他の人も 「C++のテンプレートがJavaに入るの?うげー覚えるの大変、言語が汚くなるー困るー拡大はんたいーはんたいー」というような雰囲気だったから、そうじゃないのだぞと。型制約に基づくコンパイルチェックという(Javaでは)普通のことが普通にできるようになった、ただそれだけのことなんだよ、むしろ今までがおかしかったんだ、とまあそういうことを言いたかったのです。それがうまく伝わらなかったのはぼくにも責任の一端があるってことではありますが。
「型制約があろうがなかろうが、大差ない。そんなのは重要な差ではない」なんていう主張をするつもりは毛頭ありません。私も型制約のある言語の方が好きです(特に業務で使う場合には・特に他人に書かせる場合には、と血の涙を流しながらnot AC)。