アカウント名:
パスワード:
ぜんぶ作って抱え込めばいいじゃん。
C++ のWebフレームワークやってますって人誰か居ないかね。普通に使えるよー、とかやっぱマゾですわー、とか聞いてみたい。
???「C++、聞こえていたら君の生まれの不幸を呪うがいい」???「君は良い言語だったが、多重継承がいけないのだよ」
よくC++は多重継承が・・・って言う人いますけどJavaのインターフェースは多重継承の一種なんですよね。
継承に関してC++にあって(7以前の)Javaに無いのは実装の多重継承だけで、型の多重継承とでも言うべきインターフェースの多重継承はJavaも許しています。多重継承の欠点として関数名の衝突やダイヤモンド継承がよく挙げられますが、これらはインターフェースを通してJavaでも起こり得ることです。
そこでJavaは実装の継承を一つに限ることで問題を回避しようとしているわけですが、一般に同名関数の意味が一致することは期待できないはずです。例えば、ゲーム内の車両を表すインターフェースが持つrun()とRunnableインターフェースが持つrun()の意味は違うはずだからです。
最近はJava8のインターフェースのデフォルト実装とかRubyのMix-inとか、関数実装の多重継承は許して状態の多重継承を許さないのがトレンドだと思います。なので一概に多重継承は・・・とはもう言えないような気がしています。
# ネタにマジレスごめんなさい## オフトピっぽくなってしまったけどRubyの話も書いたしまぁいっか
よく古い言語はgotoが…って言う人いますけどifやforやwhileはgotoの一種なんですよね。
アホか。
せんせー、関数呼び出しは goto に含まれますか?
束縛が定義されていない箇所にまで突っ込めるのがgotoです
同一名、同一パラメータを定義した別のInterfaceを、同一クラスに導入できましたっけ?Javaはクラス内に同一名、同一パラメータのメソッドを定義するとコンパイルエラーになるので不可能だと思いますが。
http://ideone.com/Bx68wr [ideone.com]関数名の衝突はこういうことでしょ。Bは別のinterfaceにしてCでAを定義でもいいけど。BのAを定義したときにIのinterfaceとしてのAとして定義したわけじゃない。
ダイヤモンド継承の問題はJavaでは無いな。
その例だとメソッドのスコープが違うのでいわゆる多重継承の問題は起きていないんでないかな?多重継承問題は継承した複数の基底クラスに同一メソッドが存在し得て、どの基底クラスのメソッドを呼んでるか一意に決まらない事だから。C.A()を実装してCからA()をコールしたらthis.A()がコールされることが一意に決まる。
ゲーム内の車両を表すインターフェースが持つrunのメソッド名を変えればいいんじゃ(ぼそ
実際上、車両クラスのrunメソッドと、Runnableインタフェースのrunメソッドが混同されることはないよ。インスタンスを受ける変数なりメソッドの引数には型が指定されていて合致しなければ受け入れられない。受け入れられたなら、そのインタフェースで定義された特定のシグネチャを持つメソッドの意味は1つに特定される。つまりインスタンスの受け渡し観点でで認識の齟齬によるインタフェース上の不都合が生じる事はない。もちろんインタフェースの規約に従ってメソッドが実装されていればという前提はあるが、それを否定したらそもそもインタフェースという概念が成り立たなくなる。
多重継承が問題じゃなくて菱型継承が問題だから
C++の多重継承でメンバ関数のオーバーライドなんてコンパイラが検出できるからあまり大した問題ではなくて、メンバ変数を複数持ってしまうことの方が大問題じゃないかな。
メモリが無駄、というのもあるけど親クラスのメンバ関数呼んだときに経路によって違うメンバ変数を操作するからね。一方由来のメンバ関数でメンバ変数書き換えたはずなのにもう一つのクラス由来のメンバ関数で値読み出したら反映されてない、とか普通に起こるし。
# 仮想継承すれば解決。。。とも事実上言い切れないんだよな。# 故にJavaはインタフェース継承のみにしたんだろう。
多重継承もですが、オペレータがオーバーロードできちゃうほうが個人的にはいやですなあ。
現状では言語標準でのスレッドサポートがないとか、文字列の扱いはやっぱり苦手とかあたりが選択しづらい要因。
> 言語標準でのスレッドサポートがないとか、文字列の扱いはやっぱり苦手とか
えっ
おっと11から取り込まれているのかorzといってもVS2010しばりのニッチ業務では恩恵受けられず。
>言語標準でのスレッドサポート
いつの時代だ。普通にあって、gcc/VC/clang全部で使えるよ。https://sites.google.com/site/cpprefjp/reference/thread/thread [google.com]
>オペレータがオーバーロードできちゃうほうが個人的にはいやですなあ。
これも Java 信者の方が口癖のように主張しますけど、オペレータのオーバーロードができる言語もたくさんあるんですよね。それらの言語は全部破綻しているってこと?
私はオペレータのオーバーロードがサポートできないなら、せめて複素数をネイティブでサポートしてよと思う。
オペレータのオーバーロードがなかったら同じ関数テンプレートでintと整数を格納したクラスを扱えなくなる。本質的に同じ処理の記述を型によって変えてしまうのはバグの原因、型の方で適切に対処すべき。
そもそもC++はユーザ定義クラスと組み込み型を区別しないのが原則、クラスはintやfloatと同じ様にメモリ上に配置される。参照カウント以外のGCがないのも、コンパイルが遅いのも、ユーザ定義クラス=組み込み型の原則を守るため。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
男は黙ってC++ (スコア:0)
ぜんぶ作って抱え込めばいいじゃん。
Re: (スコア:0)
C++ のWebフレームワークやってますって人誰か居ないかね。
普通に使えるよー、とかやっぱマゾですわー、とか聞いてみたい。
Re:男は黙ってC++ (スコア:0)
???「C++、聞こえていたら君の生まれの不幸を呪うがいい」
???「君は良い言語だったが、多重継承がいけないのだよ」
Javaは多重継承を許している (スコア:2, すばらしい洞察)
よくC++は多重継承が・・・って言う人いますけど
Javaのインターフェースは多重継承の一種なんですよね。
継承に関してC++にあって(7以前の)Javaに無いのは実装の多重継承だけで、
型の多重継承とでも言うべきインターフェースの多重継承はJavaも許しています。
多重継承の欠点として関数名の衝突やダイヤモンド継承がよく挙げられますが、
これらはインターフェースを通してJavaでも起こり得ることです。
そこでJavaは実装の継承を一つに限ることで問題を回避しようとしているわけですが、
一般に同名関数の意味が一致することは期待できないはずです。
例えば、ゲーム内の車両を表すインターフェースが持つrun()と
Runnableインターフェースが持つrun()の意味は違うはずだからです。
最近はJava8のインターフェースのデフォルト実装とかRubyのMix-inとか、
関数実装の多重継承は許して状態の多重継承を許さないのがトレンドだと思います。
なので一概に多重継承は・・・とはもう言えないような気がしています。
# ネタにマジレスごめんなさい
## オフトピっぽくなってしまったけどRubyの話も書いたしまぁいっか
Re: (スコア:0)
よく古い言語はgotoが…って言う人いますけどifやforやwhileはgotoの一種なんですよね。
アホか。
Re: (スコア:0)
せんせー、関数呼び出しは goto に含まれますか?
Re: (スコア:0)
束縛が定義されていない箇所にまで突っ込めるのがgotoです
Re: (スコア:0)
同一名、同一パラメータを定義した別のInterfaceを、同一クラスに導入できましたっけ?
Javaはクラス内に同一名、同一パラメータのメソッドを定義するとコンパイルエラーになるので不可能だと思いますが。
Re: (スコア:0)
http://ideone.com/Bx68wr [ideone.com]
関数名の衝突はこういうことでしょ。Bは別のinterfaceにしてCでAを定義でもいいけど。
BのAを定義したときにIのinterfaceとしてのAとして定義したわけじゃない。
ダイヤモンド継承の問題はJavaでは無いな。
Re: (スコア:0)
その例だとメソッドのスコープが違うのでいわゆる多重継承の問題は起きていないんでないかな?
多重継承問題は継承した複数の基底クラスに同一メソッドが存在し得て、どの基底クラスのメソッドを呼んでるか一意に決まらない事だから。
C.A()を実装してCからA()をコールしたらthis.A()がコールされることが一意に決まる。
Re: (スコア:0)
ゲーム内の車両を表すインターフェースが持つrunのメソッド名を変えればいいんじゃ(ぼそ
Re: (スコア:0)
実際上、車両クラスのrunメソッドと、Runnableインタフェースのrunメソッドが混同されることはないよ。
インスタンスを受ける変数なりメソッドの引数には型が指定されていて合致しなければ受け入れられない。
受け入れられたなら、そのインタフェースで定義された特定のシグネチャを持つメソッドの意味は1つに特定される。
つまりインスタンスの受け渡し観点でで認識の齟齬によるインタフェース上の不都合が生じる事はない。
もちろんインタフェースの規約に従ってメソッドが実装されていればという前提はあるが、
それを否定したらそもそもインタフェースという概念が成り立たなくなる。
Re: (スコア:0)
多重継承が問題じゃなくて菱型継承が問題だから
Re: (スコア:0)
C++の多重継承でメンバ関数のオーバーライドなんてコンパイラが検出できるから
あまり大した問題ではなくて、メンバ変数を複数持ってしまうことの方が大問題じゃないかな。
メモリが無駄、というのもあるけど親クラスのメンバ関数呼んだときに経路に
よって違うメンバ変数を操作するからね。一方由来のメンバ関数でメンバ変数書き換えたはずなのに
もう一つのクラス由来のメンバ関数で値読み出したら反映されてない、とか普通に起こるし。
# 仮想継承すれば解決。。。とも事実上言い切れないんだよな。
# 故にJavaはインタフェース継承のみにしたんだろう。
Re: (スコア:0)
多重継承もですが、オペレータがオーバーロードできちゃうほうが個人的にはいやですなあ。
現状では言語標準でのスレッドサポートがないとか、文字列の扱いはやっぱり苦手とかあたりが選択しづらい要因。
Re: (スコア:0)
> 言語標準でのスレッドサポートがないとか、文字列の扱いはやっぱり苦手とか
えっ
Re: (スコア:0)
おっと11から取り込まれているのかorz
といってもVS2010しばりのニッチ業務では恩恵受けられず。
Re: (スコア:0)
>言語標準でのスレッドサポート
いつの時代だ。
普通にあって、gcc/VC/clang全部で使えるよ。
https://sites.google.com/site/cpprefjp/reference/thread/thread [google.com]
Re: (スコア:0)
>オペレータがオーバーロードできちゃうほうが個人的にはいやですなあ。
これも Java 信者の方が口癖のように主張しますけど、
オペレータのオーバーロードができる言語もたくさんあるんですよね。
それらの言語は全部破綻しているってこと?
私はオペレータのオーバーロードがサポートできないなら、
せめて複素数をネイティブでサポートしてよと思う。
Re: (スコア:0)
オペレータのオーバーロードがなかったら同じ関数テンプレートでintと整数を格納したクラスを扱えなくなる。
本質的に同じ処理の記述を型によって変えてしまうのはバグの原因、型の方で適切に対処すべき。
そもそもC++はユーザ定義クラスと組み込み型を区別しないのが原則、
クラスはintやfloatと同じ様にメモリ上に配置される。参照カウント以外のGCがないのも、コンパイルが遅いのも、
ユーザ定義クラス=組み込み型の原則を守るため。