アカウント名:
パスワード:
これってC++で言うところのTemplateと同じものと考えてOK? それとも違う?
違います。 C++のテンプレートってのは「型紙」で、パラメータを与えることでコンパイル時にコードを展開(インスタンス化)する。別の型をパラメータに与えて使う場合はその型用のコードがインスタンス化される。基本的には文字列操作(マクロ展開)のようなイメージ。 Javaのgeneric typeは、パラメータ型ごとにインスタンス化されるわけではない。生成されるコードは1つだけ。 生成されるバイトコードで実行時に型チェックをするコードが含められたりするわけではないの
つまり、コンパイラが吐き出す内部コードの違いだけで、使い方としては同じ、 と考えてオーケー?
Javaでは、この意味でのコード共有は、generic typeがお出ましするまでも無く当初から可能でしたしJDKのAPIの一部に入ってました(java.util.Vector,HashTable、コレクションAPIのこと)。
JavaでC++のtemplateのようなものなしになぜこれが可能だったのかというと、Javaの多くのクラスがObjectを根として持つ大きな階層構造をなしているため、Objectを扱えるStackを1つ定義してあれば、Objectのサブクラスの要素すべてを扱えるからです。(C++はクラス階層に統一的な「根」となるクラスが無いし、あとポインタで扱えない・扱いたくない「値オブジェクト」の問題があったからこうはできなかった。このことにはC++にはGCがない、という根が深い問題とも絡んでいます)
しかしJavaのこの方法でも問題があって、いったんObjectを経由するがために、型チェックが動的にしか行えないわけです。配列でたとえると、Stringの配列を使うときには、String[]を使えばいいのにObject[]を使わなければならない、ということです。Object[]だから要素にMyClassの要素を入れることもできちゃうし、それがわかるのは取り出し時のキャスト時です。これは不便な話ですが、generic typeが無い今までは実際にこんなへんなことを強要されていた。これを、コレクションAPI使用時に、配列と同じように、代入時に、しかもコンパイル時にチェックできるようにしようというのがgeneric typeです。 コレクションクラスはもとはSmalltalk由来で、 Smalltalkとかだったら、こんなもんは実行時でOKな話ですが、Javaという静的に型づけする言語にコレクションを持ち込んでしまうと、不自然になるのでそれなりに合わせたとゆうわけです。
templateじゃなくてgeneric typeを使った際の利点はなんでしょうか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家
generic type (スコア:0)
これってC++で言うところのTemplateと同じものと考えてOK?
それとも違う?教えて、エライ人。
Re:generic type (スコア:1, 参考になる)
違います。
C++のテンプレートってのは「型紙」で、パラメータを与えることでコンパイル時にコードを展開(インスタンス化)する。別の型をパラメータに与えて使う場合はその型用のコードがインスタンス化される。基本的には文字列操作(マクロ展開)のようなイメージ。
Javaのgeneric typeは、パラメータ型ごとにインスタンス化されるわけではない。生成されるコードは1つだけ。 生成されるバイトコードで実行時に型チェックをするコードが含められたりするわけではないの
Re:generic type (スコア:0)
と考えてオーケー?
templateじゃなくてgeneric typeを使った際の利点はなんでしょうか?
#スマン、オイラバカなんで。もう少しわかりやすく説明して頂けると・・・。
Re:generic type (スコア:3, 参考になる)
このようなあつかう型の違いをパラメータとして切り出せるようにしたのがtemplate。コード共有の話です。
Javaでは、この意味でのコード共有は、generic typeがお出ましするまでも無く当初から可能でしたしJDKのAPIの一部に入ってました(java.util.Vector,HashTable、コレクションAPIのこと)。
JavaでC++のtemplateのようなものなしになぜこれが可能だったのかというと、Javaの多くのクラスがObjectを根として持つ大きな階層構造をなしているため、Objectを扱えるStackを1つ定義してあれば、Objectのサブクラスの要素すべてを扱えるからです。(C++はクラス階層に統一的な「根」となるクラスが無いし、あとポインタで扱えない・扱いたくない「値オブジェクト」の問題があったからこうはできなかった。このことにはC++にはGCがない、という根が深い問題とも絡んでいます)
しかしJavaのこの方法でも問題があって、いったんObjectを経由するがために、型チェックが動的にしか行えないわけです。配列でたとえると、Stringの配列を使うときには、String[]を使えばいいのにObject[]を使わなければならない、ということです。Object[]だから要素にMyClassの要素を入れることもできちゃうし、それがわかるのは取り出し時のキャスト時です。これは不便な話ですが、generic typeが無い今までは実際にこんなへんなことを強要されていた。これを、コレクションAPI使用時に、配列と同じように、代入時に、しかもコンパイル時にチェックできるようにしようというのがgeneric typeです。
直接比較できないですね。比較するんだったら、templateと「JavaのコレクションAPI+generic type」という構図になるかな? でも、言語が違うからやっぱり直接比較にならない。ただ、templateはC++に合うように、generic typeはJavaに合うようにそれぞれ良く考えられてはいる、とは言えると思われます。コレクションクラスはもとはSmalltalk由来で、 Smalltalkとかだったら、こんなもんは実行時でOKな話ですが、Javaという静的に型づけする言語にコレクションを持ち込んでしまうと、不自然になるのでそれなりに合わせたとゆうわけです。
Re:generic type (スコア:0)