5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

C++多重継承

1 :♯6411:2001/08/16(木) 19:57
多重継承はCoolなのか、Harmfulなのか?
是非を問うてみたい。非非のオンパレードになりそうだけど。
多態マンセー!

なお、C++BuilderのTObject派生クラスにおいては、
多重継承は許されていません。

2 :いんたーふぇーす:2001/08/16(木) 19:59
 かふか

3 :デフォルトの名無しさん:2001/08/16(木) 20:05
>>1
そもそもC++がCoolじゃない。
そもそもC++がHarmful。

4 :デフォルトの名無しさん:2001/08/16(木) 20:51

満場一致で終了

5 :デフォルトの名無しさん:2001/08/16(木) 22:17
多態と多重継承はかんけーない

6 :♯6411:2001/08/16(木) 22:24
>>5 たしかに直接の関係はないすね。
イテクルヨ

7 :デフォルトの名無しさん:2001/08/16(木) 22:27
MFCは多重継承の使用を考えてないデザインだからウザイ。
OWLが良かったよ〜。

8 :デフォルトの名無しさん:2001/08/16(木) 23:19
>>7
世の中は内容を吟味せずにイメージだけで選んじゃう人が大多数だから・・・
(BC++に関してはボーランドが自分でこけた部分もあるようだけど)

9 :デフォルトの名無しさん:2001/08/16(木) 23:45
>>1
インターフェース継承は cool
実装継承は諸刃の剣で、扱いを間違えると辛いわな

>>8
BC++ はライブラリは良くても、コンパイラとデバッガ、エディタが
ねぇ……。SDK への対応が遅れるのも辛い。

10 :デフォルトの名無しさん:2001/08/17(金) 04:44
BC++はメモリリーク検出ツールが使いやすくて良かった…

11 :デフォルトの名無しさん:2001/08/17(金) 12:33
>BC++に関してはボーランドが自分でこけた部分もあるようだけど

詳細教えて。

12 :Ruby:2001/08/17(金) 12:36
C++なんて問題外

13 :デフォルトの名無しさん:2001/08/17(金) 12:40
RubyはC++で出来てんじゃないの?>12=shige

14 :デフォルトの名無しさん:2001/08/17(金) 12:40
ハァ?

15 :shige:2001/08/17(金) 12:41
ハァ? ちが

16 :デフォルトの名無しさん:2001/08/17(金) 13:09
多重継承って現実の概念で例えればどんなものを表現するのに使いますか?

17 :>16:2001/08/17(金) 13:15
例えばあなたは男性であり地球人であり引きこもりであり2ちゃんねらーであるということです。

18 :デフォルトの名無しさん:2001/08/17(金) 13:28
>>17
それを多重継承で表現すんのか?

19 :デフォルトの名無しさん:2001/08/17(金) 13:31
>17
男性にも 地球人のも 引きこもりにも 2ちゃんねらーにも 人という概念が
ルートにあると思われますが? 大丈夫ですね? あなたの実装は

20 :デフォルトの名無しさん:2001/08/17(金) 13:37
>>19
それは多重継承とはいわない

21 :デフォルトの名無しさん:2001/08/17(金) 13:46
>>20
どうして?
人の属性は全部に含まれると思うけど

22 :デフォルトの名無しさん:2001/08/17(金) 13:54
class pencil{

}
class eraser{

}
class MitubishiPncil:public pencil,public eraser{

}

23 :デフォルトの名無しさん:2001/08/17(金) 14:04
class FFChoroQ: public ChoroQ
{

}

class RRChoroQ: public ChoroQ
{

}

class 4WDChoroQ : public FFChoroQ,RRChoroQ
{

}

で、いいですか?

24 :デフォルトの名無しさん:2001/08/17(金) 14:06
>21
あなたはいったい何の根拠があって
火星人の引きこもり2ちゃんねらーの
存在を否定するのでしょう?

25 :デフォルトの名無しさん:2001/08/17(金) 14:14
どうして誰も>>21の事をバカだと言ってあげないのだろう?
もしかして、実は誰も多重継承がなにか理解していないとか(藁

26 :デフォルトの名無しさん:2001/08/17(金) 16:22
25みたいな奴が多いなこのスレ。
1から25まで、みんな逝ってよし。

27 :デフォルトの名無しさん:2001/08/17(金) 16:45
>>23
クラス4WDChoroQは基底クラスChoroQのメンバを
重複して持っているので逝ってよし!

28 :デフォルトの名無しさん:2001/08/17(金) 16:56
>>26=21

29 :デフォルトの名無しさん:2001/08/17(金) 17:21
火星"人"なのに人の属性含まないの?

30 :デフォルトの名無しさん:2001/08/17(金) 17:50
限りなく名スレの予感…。

31 :デフォルトの名無しさん:2001/08/17(金) 18:59
>>27
しまった!
RRとFFが派生じゃなく基底ならいいんだよね?(^^;

32 :♯6411:2001/08/17(金) 19:01
>>31 ChoroQが仮想基底クラスだと丸く収まるかな?

33 :デフォルトの名無しさん:2001/08/17(金) 21:15
多重継承する時はVirtual継承にしておくと、後々助かるよ!(・∀・)

34 :デフォルトの名無しさん:2001/08/17(金) 21:31
なるほど、勉強になります。
でも、多重継承が必要な局面に遭遇したことがない(^^;

35 :デフォルトの名無しさん:2001/08/17(金) 21:35
メジャーな処理系で多重継承サポートしてるのはC++だけだからね
JavaもC#もRubyも多重継承なんぞ必要としていないのさ

36 :デフォルトの名無しさん:2001/08/18(土) 01:53
多重継承って大規模システム開発とかでも使われてるのか??

37 :デフォルトの名無しさん:2001/08/18(土) 01:58
>>36
大規模なら事前/事後にチェックが入るから、
使ったとしても、チェック機構があるゆえ、マトモに動く。

大規模でないのに採用する理由があるか、という話なら興味があるね。

38 :デフォルトの名無しさん:2001/08/18(土) 01:59
Mix-inって昔は多重継承使って実装するもんだったけど
今は違うのかな...
class Mixin<A> extends A
なんてできる言語もあったが。

39 :デフォルトの名無しさん:2001/08/18(土) 02:59
>>38
C++ なら、template でクラス階層に挟み込める。

40 :デフォルトの名無しさん:2001/08/18(土) 03:23
>>39
その名もずばり
「insert class Bar before Foo;」
という構文を使えるマイナー言語を、使ったことがある。
結構愉快だった。
beforeってのは、FooとFooのsuperclassとの間(直前?)に
Barを挟むことが出来るという意味で。

41 :デフォルトの名無しさん:2001/08/18(土) 03:24
多重継承不要で盛り上がってるところ悪いけど
ものすごく便利だ 多重継承マンセー
単継承のみなんて面倒臭くて・・
まあ 好き好きだと思いますが

42 :デフォルトの名無しさん:2001/08/18(土) 03:43
多重継承という場合、広義には実装継承とインターフェース継承、そし
て Mixin も含まれると思うんだが、何について話しているのか明確に
しないと混乱しないか?

>>35
Java にはクラスの多重継承はないが、インターフェースの多重継承は
ある。Ruby も Mixin はできるよね。

43 ::2001/08/18(土) 10:27
多重継承ってつかったことないんだけど、どういった局面で使うのかな?
多重継承でなければダメって場合もあるのだろうか。

44 :ジェームズ:2001/08/18(土) 10:38
ジェラールとレオンから多重継承しましたが何か?

45 :デフォルトの名無しさん:2001/08/18(土) 10:55
>>43
その議論は、死ぬほど行われている。webなどで検索しろ。
下手にここで振ると厨房であふれるからやめろ。

46 :>42:2001/08/18(土) 11:42
ここはC++多重継承スレ

47 :デフォルトの名無しさん:2001/08/18(土) 11:46
胆汁継承

48 :デフォルトの名無しさん:2001/08/18(土) 12:57
重軽傷

49 :デフォルトの名無しさん:2001/08/18(土) 15:57
>>44
それを多重継承というならJavaは多重継承しまくりの言語ということになるが。

50 :教えて君:2001/08/18(土) 19:58
Mixin ってなに?、継承と何が違うの?。解説をキボーン。

51 :デフォルトの名無しさん:2001/08/18(土) 20:00
多重継承使いは、問答無用で逝ってよし!

52 :デフォルトの名無しさん:2001/08/18(土) 20:19
多重継承を便利だと言ってはばからないのは、継承ツリーを行き当たりばったり
で作ってますって告白してるのとおんなじでかなり恥ずかしい行為だぞ。
せめて「工数と相談して止むを得ず採用することも有る」ぐらいにしとけ。

53 :デフォルトの名無しさん:2001/08/18(土) 20:30
>>46
いや、C++ だからこそ明確にしておこうと言ってる。

Ruby や Java ではインターフェース継承、Mixin は実装継承と言語
レベルで区別されてる(実装継承は禁止されている)けど、C++ の場
合は区別されてないから。

>>50
Mixin は多重継承のルール。

まずインスタンスを持たず、Mixin 以外のスーパークラスを持たないク
ラスを Mixin と定義する。次に多重継承する場合、Mixin はいくつ継
承しても構わないが、それ以外のクラスは一つのみに限定する。

こうするとクラス階層が単純な木構造になるので、多重継承した場合に
生じるざまざまな問題を回避しつつ、多重継承のおいしい部分は利用で
きる。

54 :デフォルトの名無しさん:2001/08/18(土) 20:39
>>52
ATL/WTL は多重継承前提のライブラリだが、決して継承ツリーを行き
当たりばったりで拡張したわけではない。むしろ、設計は良いと思う
んだが、どうよ?

55 :デフォルトの名無しさん:2001/08/18(土) 20:54
>>54
> ATL/WTL は・・・んだが、どうよ?

って、誰も使ってないでしょ。

56 :デフォルトの名無しさん:2001/08/18(土) 21:14
>>55
>って、誰も使ってないでしょ。
今、仕事でATLを使っているから、誰も使っていないわけではない。
                     ~~~~~

57 :52:2001/08/18(土) 21:19
>>53
コーディング規約に毛の生えたようなMixinで可読性を下げるよりComposit
した方が潔いと思われ。

>>55
んだんだ。

58 :デフォルトの名無しさん:2001/08/18(土) 21:25
ATLは使わんわけにはいかんでしょ

59 :デフォルトの名無しさん:2001/08/18(土) 21:27
>>57
Mixin が可読性を下げるというのは、初めて聞いたな。なにか事例は
あります?

60 :52:2001/08/18(土) 21:38
だからCompositと比較してくれ。
違いが気にならないなら放置でいいよ。

61 :デフォルトの名無しさん:2001/08/18(土) 21:38
>59
単に言語が直接サポートしない概念を無理やり実装しても
一般性を欠き結果的に読みづらいコードになるってことでしょ。
別にmixinの有用性を否定しているわけではないと思う。

62 :52:2001/08/18(土) 21:41
>>61
援護してもらって申し訳ないが、半分ぐらい否定してる。

63 :デフォルトの名無しさん:2001/08/18(土) 22:18
多重継承なんて使った事ないよ〜。

64 :デフォルトの名無しさん:2001/08/18(土) 22:36
>>63
精進しなされ。

65 :デフォルトの名無しさん:2001/08/19(日) 05:38
>>52
多重継承しなければコーディングできない例っていうのが実はある。
よく知らないと思われるね。
迂回するためにクラスが爆発的に増えるのが単継承の欠点。

66 :デフォルトの名無しさん:2001/08/19(日) 06:52
Javaが採用しないものが正しいわけないだろ!!>65
多重継承する奴バカ、大バカ!!
てめーらみたいな低俗低脳がいるから世の中が腐るんだ
氏んで詫びろ!!

67 :デフォルトの名無しさん:2001/08/19(日) 07:18
 再帰しなければコーディングできない例っていうのが実はある。
 よく知らないと思われるね。

と似てる雰囲気の発言かもな

68 :デフォルトの名無しさん:2001/08/19(日) 07:32
C++の多重継承はホントに多重だと継承出来ない

 それぞれが独立でなければ継承出来ないなら入れ子にしてインターフェースで外見を整え
るCのレベルで出来る戦略を通した方が100倍マシかと

69 :デフォルトの名無しさん:2001/08/19(日) 09:38
ATLを見ていると多重継承ってべんりだなと思う今日この頃。

ディスパッチインタフェースをもったウインドウを実装するのに
CWindowImplとIDispatchImplのふたつの基底クラスを継承するというのは
すごく素直な表現だとおもう。

さらにCOMインタフェースを追加するなら、その分多重継承すればいいし。
ポインタ変換はキャストすればいいだけ。

これに対してMFCのCOMインタフェースは包含によって実装するが
ベースクラスへのポインタを求めるためにおかしなポインタ計算
(結局はコンパイラがやっている多重継承クラスのキャストを自前でやっている)
しなければならない。

70 :デフォルトの名無しさん:2001/08/19(日) 09:57
プログラミングは条件との戦いでもあるから

多重継承出来る時は多重継承で解決すればいい
あっても移植性を考えて使わないというならそれでいい

無ければクソとかいう発言にはあまり意味がない。

71 :デフォルトの名無しさん:2001/08/20(月) 00:19
>>70
正論すぎ

72 :デフォルトの名無しさん:2001/08/20(月) 18:55
誰でも簡単に手に入れられそうな例題ってiostreamじゃない?
いい例題と言えるかどうかはしらん。

class ios
class istream :public virtual ios
class ostream :public virtual ios
class iostream:public istream, public ostream

最近のはちょっと違うけど。

73 :l:2001/08/20(月) 19:08
無謀な多重継承によって後の開発に重軽傷を負った。

74 :デフォルトの名無しさん:2001/08/21(火) 00:48
Javaのような、インターフェースとしての利用に徹した多重継承ならどうよ?
インターフェースなしでやるとえらい大変なメになるってんなら、これくらいはアリかと思うんだけど。

75 :デフォルトの名無しさん:2001/08/21(火) 00:54
インターフェースも多重継承にはいるの?

76 :デフォルトの名無しさん:2001/08/21(火) 00:58
入らないような、でも結局「ソレ」として参照できる時点で
ある種の問題を抱えているような。
まあそれは包含しても集約しても同じか。

77 :デフォルトの名無しさん:2001/08/21(火) 01:09
> ある種の問題を抱えているような。
何?

78 :デフォルトの名無しさん:2001/08/21(火) 02:07
>>73
バカに刃物を握らせてはいけない
切れる刃ほど怪我をする

79 :デフォルトの名無しさん:2001/08/21(火) 04:08
>>73
クラス階層の設計が甘いと後々苦しむのは、多重継承に限らないと思われ。単一継
承でも十分に痛いし。

>>76
何が問題なの?

80 : :2001/08/21(火) 10:22
>>75
多重継承はデータとメソッドを継承する。
インターフェースはメソッド名のみ継承する。
 多重継承の一部を切り取った概念だと理解してるんだけど、、違う?

81 :デフォルトの名無しさん:2001/08/21(火) 22:13
>>80
インターフェースstaticなデータは継承できるでしょ

82 :デフォルトの名無しさん:2001/08/21(火) 23:19
>>80
interface 継承は実体がないので、多重に継承してもあまり害はない。実装が
一つだけなら vtbl のエントリが複数あっても同じメソッドへのポインタで埋
まるだけだし。

83 :デフォルトの名無しさん:2001/08/25(土) 23:52
Eiffelの多重継承は便利だと思う。

class A feature
  x: INTEGER
  y: INTEGER
end

class B inherit A end ;  class C inherit A end

class D inherit B rename y as y1
           end
         C rename y as y2
           select y2
           end
end

とすると x が仮想継承になって y が非仮想継承になる。
select y2 はC++ふうに書くと
A* a ;
D* d = new D ;
a = d ;
a.y のとき y1とy2 どっちか指定する。

84 :デフォルトの名無しさん:2001/08/26(日) 00:49
多重継承されていることを、そのクラスと関連する他のクラスが
意識する必要があるかどうか、がポイントのような気がするなあ。

18 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)