1 名前:デフォルトの名無しさん mailto:sage [2021/03/24(水) 12:07:15.39 ID:R+oM8cup.net] ※前スレ C++相談室 part154 https://mevius.5ch.net/test/read.cgi/tech/1610096040/ テンプレここまで
575 名前:黷スホラー現象 [] [ここ壊れてます]
576 名前:デフォルトの名無しさん mailto:sage [2021/04/29(木) 13:10:34.24 ID:K/HFYMcp.net] https://stackoverflow.com/questions/16126578/vectors-and-polymorphism-in-c ↑によれば、やっぱり、>>561 や >>562 のようなやり方は間違いで、 std::vector<T> の T は、Bookではなく、shared_ptr<Book> のようなものを入れるべきで、 以下の様になっている。だから、>>561 や >>562 は間違いだよね? class Instruction {・・・}; class Add: public Instruction{・・・}; typedef shared_ptr<Instruction> PInstruction; vector<PInstruction> v; v.emplace_back(make_shared<Add>());
577 名前:デフォルトの名無しさん mailto:sage [2021/04/29(木) 13:16:01.96 ID:yUiVUiFp.net] >>564 その認識で合ってる 561のShelfにはNovelやComicじゃなくて、そいつらから刈り取った生首が並んでる 絶対やったらいかんやつ
578 名前:デフォルトの名無しさん mailto:sage [2021/04/29(木) 13:19:09.72 ID:K/HFYMcp.net] >>563 なるほど、では、正しい書き方としては、たとえば、こうかな: class Book {・・・}; class Novel : public Book{・・・}; class Comic : public Book{・・・}; typedef shared_ptr<Book> PBOOK; class Shelf : public std::vector<PBOOK> {・・・}; Shelf g_shelf; int main(void) { std::shared_ptr<Novel> n = make_shared<Novel>("Hoshio wo tugumono"); std::shared_ptr<Comic> c = make_shared<Comic>("Kimetsu no Yaiba"); g_shelf.push_back(n); g_shelf.push_back(c); }
579 名前:はちみつ餃子 mailto:sage [2021/04/29(木) 18:07:20.75 ID:x0Vd7BP9.net] パブリック継承している型のオブジェクトが基底クラスへ暗黙に型変換されるのは抑止する方法がないんだよな。
580 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 01:30:09.20 ID:7VhEvZ/Q.net] >>567 Dog d; の時に func( Animal &a )に対して、 func(d); がエラーにならないということ?
581 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 08:17:30.86 ID:tsrXe0Ut.net] それは別に問題ない func(Animal a)だとやばい
582 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 09:32:28.19 ID:W8up1rh0.net] funcがAnimalの情報しか使わないんなら別にいいんだけどね 単にポリモーフィズムにはポインタか参照が必要ってだけ
583 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 09:52:57.56 ID:dyTEtgxA.net] shared_ptr<T>もいけるでしょ スタックを使った60バイト近いメモリーコピーが発生するから最適ではないけど
584 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 10:40:50.56 ID:7VhEvZ/Q.net] >>569 class Animal {・・・}; class Dog : publoic Animal {・・・}; std::vector<Animal> g_list; void func( Animal &a ) { g_list.push_back(a); } int main() { Dog d; func(d); // コンパイルエラーにはならないのに、スライシングが発生。駄目な例。 return 0; }
585 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 11:02:34.65 ID:Qm/DlA0m.net] >>572 スライシングが発生してるのは g_list.push_back(a) であって、 func( Animal &a ) は関係ないでしょ。
586 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 11:21:35.01 ID:qs5VuYRE.net] なんで範囲for文ってBOOST_FOREACHを完全に置き換えれるようにしなかったの? >>537 ,542はそれで解決するし、逆順のループとかもできるのに
587 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 11:34:29.27 ID:vL4rFdIy.net] ポリモーフィズム前提の時は、コピーコンストラクタはdeleteするのが良いのかね
588 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 11:43:26.05 ID:qs5VuYRE.net] あー範囲forが使える条件とBOOST_FOREACH使える条件って違うのか 後者は自作クラスじゃ使えない? あるいは使える条件が>>535 と違う?
589 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 11:48:46.39 ID:7VhEvZ/Q.net] >>573 この場合、スライシングが発生しても問題ない、という観点もあるかも。
590 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 12:01:43.38 ID:W8up1rh0.net] >>575 そしたら派生クラス同士でコピー出来んやろ、コピー禁止にしたいのでなければ書くべき(で派生のコピーコンストラクタで基底のコピーコンストラクタを初期化リストから呼ぶ 必ず派生させて使うのが前提ならコンストラクタをprotectedにするとかその辺のテクニックは大昔から色々出てる
591 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 12:18:33.85 ID:7VhEvZ/Q.net] スライシングが起きるとき、基本クラス部分だけをコピーすることになるが、 その際、仮想テーブルへのポインタが継承クラス用のままだと、コピー後の 操作が危険になる可能性があるが、もし、仮想テーブルへのポインタを 基本クラス用に変えてしてしまえば、コピー後の動作は完全に基本クラス的に なってしまうけれど、その反面、メンバー関数を呼び出しても特にメモリーの 破壊などは起きないはず。 そのようにしてしまえばスライシングが起きても問題ないような気が。
592 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 12:31:22.41 ID:W8up1rh0.net] >>578 て書いたけど実際ポリモーフィズム目的の継承ツリーだとコピー禁止にしてること多いな・・ どうせポインタ(orスマポ)で管理するから確かにコピー禁止のが無難かもね
593 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 12:38:12.34 ID:5yvxXz0O.net] >>570 それぞれのコピコンをプログラマが自由に記述できる以上、例えAnimalの情報しか参照しないとしても問題が起こることはあるんじゃね? 例えば、DogのコピコンはAnimal::cuterThanCat変数を強制的にtrueに書き換えてるかもしれない
594 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 12:51:39.69 ID:W8up1rh0.net] >>581 戦争勃発するぞ まぁスライシングが常に危険とは限らないと言いたかっただけ
595 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 14:49:19.98 ID:qs5VuYRE.net] 誰かBOOST_FOREACHを自作クラスに使う条件教えてください
596 名前:はちみつ餃子 mailto:sage [2021/04/30(金) 16:01:39.38 ID:Efpw+/b3.net] >>583 https://www.boost.org/doc/libs/1_76_0/doc/html/foreach/extensibility.html
597 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 20:24:33.87 ID:QZYh0z4M.net] >>579 >スライシングが起きるとき、基本クラス部分だけをコピーすることになるが、 >その際、仮想テーブルへのポインタが継承クラス用のままだと、コピー後の >操作が危険 そんな恐ろしいことが! と思って試したが、少なくともデフォルトのコピコンは仮想関数テーブルへのポインタを コピー先の型に合わせて付け替えてくれるらしい ↓そうでなけれはfunc_with_ref(Animal a)の中でa2.get()がDogの値でなくAnimalの値を返す説明がつかない https://ideone.com/eJMsYG 規格でどうなっているかは知らん
598 名前:デフォルトの名無しさん mailto:sage [2021/04/30(金) 20:25:50.19 ID:QZYh0z4M.net] 訂正orz、 誤: そうでなけれはfunc_with_ref(Animal a)の中で 正: そうでなけれはfunc_with_copy(Animal a)の中で
599 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 07:00:40.64 ID:2eVlBBCY.net] ていうかよく考えたらAnimalのコピコンは Animalのコンストラクタでもあるのだから>>585 の挙動は当然かorz
600 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 09:21:42.94 ID:C4kuj/yW.net] コピコン
601 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 09:28:33.15 ID:18idEqJd.net] コピコン たまに見る 頭悪そう
602 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 10:19:04.33 ID:tHuso9oJ.net] でもコピーコンストラクターって長いよね
603 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 10:26:47.50 ID:2eVlBBCY.net] コンストラクタはコンストラ コピーコンストラクタはコピコン デストラクタはデストラ アルゴリズムはアルゴ と略すのが効率的
604 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 10:31:05.38 ID:Jen9oEOj.net] 取引先がそんな言葉を使ってきたら 今後の契約を考え直すかも 少なくとも評価はマイナス 取引先とそんな細かい内容を話す打合せも無いだろうけど
605 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 11:21:44.35 ID:fSkONWKY.net] >>591 気持ち悪い略語だな
606 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 12:04:39.12 ID:zZz/KCNF.net] デストラw
607 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 12:14:30.82 ID:yzll/vyD.net] ctor,dtorは一般的な略語?
608 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 12:14:41.90 ID:toT74GP1.net] 機能を引き継ぐために継承して、インスタンス化して使うために移譲もしたい 継承も移譲もするのってありですか?
609 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 12:45:03.96 ID:toT74GP1.net] わかんねえ 継承が相応しくない場合が山程あるのはわかった 継承が相応しくないが一部機能を引き継ぎたいときは、コードのコピペをするべきなのか?
610 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 12:53:12.87 ID:C4kuj/yW.net] 独立させる
611 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 13:13:50.17 ID:toT74GP1.net] >>598 より小さいクラスか構造体として切り出すということ?
612 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 13:18:13.99 ID:T/ErWrJ0.net] private継承じゃダメなの?
613 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 13:52:11.96 ID:toT74GP1.net] >>600 ダメってことはもちろんなくて、そう実装することにすればそう実装するだけだが、継承である以上は依存関係が生じるし、相応しくない場合もあるなあと思うだけ
614 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 13:54:03.05 ID:TBkH44Fh.net] intをとるかcharを取るかで振る舞いを変えるオーバーロード関数って作れるんですか? その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか?
615 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 14:19:20.97 ID:I2agxka5.net] オーバーロードという単語を知っておきながら、何故できないと思ったんだ
616 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 16:00:09.42 ID:qPtffzbe.net] >>602 関数シグネチャってもんがあるわけよ。 リンカは関数名ではなくこのシグネチャでリンクする。 引数の型が変わるとこのシグネチャが変わるので、 プログラムというかコンパイラはそれを間違えることはない。
617 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 16:28:04.60 ID:18idEqJd.net] intとcharは使う側が間違いやすいから 間違えたら問題がある場合は名前を変えよう
618 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 16:37:35.74 ID:JkRHvcmQ.net] >>604 厳密に言えばリンカは関数名しか見ない。 C++はオーバーロードのためにシグネチャの違いを関数名に埋め込むマングリングを行う。
619 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 17:09:26.40 ID:1WejqaZh.net] >>602 C++で関数呼び出しを書いた場合、どの関数が呼び出されるかは Best Matching Algorithm で選ばれているので実引数が charの場合は、 同じ場所の仮引数がcharである関数を優先的に選ぼうとする。 もし、同じ場所の仮引数がcharであるものが見つからなければ、 同じ場所の仮引数が int であるものを探して、見つかればそれを選択する。 このとき、実引数と仮引数の型の「距離」のような概念があり、 距離が近いものが選ばれる。複数の引数が有る場合で、二つの引数で 距離が近い関数がどっちもどっちになる場合には、「曖昧」であると、 され、エラーになる。 >その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか? ここであなたの言っている「見分ける」という意味が分かりにくいが、 オーバーロードされた関数は、C++レベルでは同じ名前に見えていてもが アセンブラレベルでは別の関数名になっていて、別の関数として扱われていて、 別の関数が呼び出されているから「見分ける」以前問題になっている。
620 名前: mailto:sage [2021/05/01(土) 17:16:10.99 ID:m+tkSw04.net] >>591 コピコン以外は使わないです‥‥
621 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 17:24:45.49 ID:CnJDnM0a.net] >>606 「リンカは関数名しか見ない」はおかしい。 リンカが見るのは、関数名を含むシグネチャをマングリングした結果のシンボル名。
622 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 17:29:02.27 ID:1WejqaZh.net] >>605 それは、実際そうだと思う。 char idx = xxx; func( 'a' + idx ); と書いた場合、func(int)とfunc(char)のどちらが呼び出されるのかを 事前に予想するのは非常に難しい。 なぜなら、伝統的にCでは、char + char は、それぞれが int に昇格 されてから、int + int になって、結果も int になるとされていたから。
623 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 18:00:18.46 ID:1WejqaZh.net] ファイル出力で、1バイト出力と4バイト出力の違いは、単に人間が見るための stdout出力とは訳が違って、後からファイルを入力する時にその部分のバイト数の違い が大きな意味を持つので、オーバーロードの仕組みだけでコンパイラに自動振り分け させるのは、分かりにくいバグを入れてしまう可能性がある。 なので、やはり、出力するのは1バイトなのか4バイトなのかを、明確に関数名で 区別できるようにした方が望ましいと思われる。
624 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 18:45:41.91 ID:JkRHvcmQ.net] >>609 そのマングリングした名前で関数を呼び出すことができるわけだし、関数名以外の何物でもないと思うが。 そもそもリンカはマングリングされているのかされていないのかも関知しないし。
625 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 18:55:40.94 ID:u3yKRN8V.net] > 589 名前:デフォルトの名無しさん[sage] 投稿日:2021/05/01(土) 09:28:33.15 ID:18idEqJd [1/2] > コピコン > たまに見る > 頭悪そう >>595 に何も言えねえ 頭悪そうw
626 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 19:59:37.32 ID:tHuso9oJ.net] マングリング、ってなんかイヤらしいよね
627 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 20:50:21.52 ID:TTMGRbh+.net] >>612 ?h@@YAXH@Z みたいなのを関数名って言うのは違和感しかないわ > そもそもリンカはマングリングされているのかされていないのかも関知しないし。 それを言うならリンカは関数かどうかすら関知してない
628 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 21:00:22.23 ID:CnJDnM0a.net] >>612 むちゃくちゃだなぁ。わざわざ用語をごっちゃにして何がうれしいの? シンボルが関数を指すのか変数その他を指すのかもリンカは関知しないんじゃないの? たとえば ld のマニュアルに function name なんて一度も出てこないし。 https://linux.die.net/man/1/ld > ld combines a number of object and archive files, relocates their data and ties up symbol references. ...
629 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 21:25:44.91 ID:18idEqJd.net] 私は「関数名」派 C++のコンパイラは元々はC++からCに翻訳してたわけだし
630 名前:デフォルトの名無しさん mailto:sage [2021/05/01(土) 21:27:05.03 ID:18idEqJd.net] まあどっちでもいいけど
631 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 00:16:29.81 ID:r2Ed4Ypi.net] >>616 だなあ。 C++のコードにおいて、関数名と呼ぶ場合、それはマングリング込みとかのシグネチャではなく あくまでもソースコード上にある関数の名前だからなあ。 >>618 これはあんまりどっちでも良くない。 つか、>>612 の言い分を認めるとオーバーロード/オーバーライドってもんがなんだか分からなくなるw 同じ関数名で関数の実装を選べるってのがオーバーロード/オーバーライドだから。
632 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 01:13:49.22 ID:hoeVnODB.net] オーバーライドの意味も知らない子は無理して回答しなくていいよ
633 名前:デフォルトの名無しさん [2021/05/02(日) 01:21:37.53 ID:AyQRjFej.net] C++初心者はクラス継承の学習にこだわりテンプレートの学習が後回しになるので、テンプレートが最適解になることが多いと悟るのが遅くなる
634 名前:デフォルトの名無しさん [2021/05/02(日) 01:23:19.71 ID:liMkj8Q9.net] オーバルライトは新しいからね。
635 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 01:39:37.43 ID:uIjrwEP9.net] >>619 Cに翻訳された段階だと変数名まで含んだ名前が関数名 当然リンカの段階ではC++の関数名は残って無い C++以外のドメインでどれが関数名かを議論すること自体意味がない
636 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 01:40:39.79 ID:uIjrwEP9.net] >>610 されていたって... 今もそうだよ
637 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 06:37:18.08 ID:pZrwNqHn.net] >>619 overrideキーワードは派生クラスで仮想関数を上書きするときに使う overloadキーワードはcfront 1.0世代のC++で関数を多重定義する予告として使われていた
638 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 08:57:49.73 ID:rpBXKN7W.net] 基底クラスBで定義された int foo(double x) が派生クラスD1、D2でオーバーライドされた場合、 同じ「foo」という関数名に対して Bのクラス名が入ったマングルされたシンボル _$F_B__foo_INT_1_DBL D1のクラス名が入ったマングルされたシンボル _$F_D1_foo_INT_1_DBL D2のクラス名が入ったマングルされたシンボル _$F_D2__foo_INT_1_DBL みたいな3種類のシンボルがリンカに渡されることになり(マングリング規則は適当 、{ オーバーライドされた関数名 }と{ オーバーライドされたシンボル }の 1対1対応は崩れるのだから 関数名≠関数のシンボル を示す例としてオーバーライドはオーバーロードと同じく妥当であることは変わりが無い 、と思うが知らん
639 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 09:20:39.13 ID:aspEWHUD.net] >>621 継承とテンプレートが対立するかのように考えてる時点で テンプレートどころかクラスや継承もまともに理解できてないやつの発言にしか見えない
640 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 10:53:26.72 ID:r2Ed4Ypi.net] >>626 丁寧な御説明ありがとう。 それで正しいですよ。
641 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 12:10:24.45 ID:tUw9C2ed.net] このクソ議論見ても関数オーバーロードの仕様は失敗してるってのがよくわかる。
642 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 12:12:19.26 ID:KNEFHTDE.net] …などと意味不明の供述をしており、
643 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 12:47:09.45 ID:72ULtZJb.net] 悪い子: この仕様はクソだ! 普通の子: この仕様は〇〇だから良くないね 良い子: この仕様は〇〇だから良くないね、△△とすれば良いのに
644 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:06:19.55 ID:hoeVnODB.net] >>626 それは単に別のクラスで同じ名前のメンバ関数はシンボルが違うってだけの話だろ オーバーライドは全く関係ない そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない オーバーロードと並べて語る意味が全くわからない
645 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:16:03.71 ID:B3yuABqk.net] ダンバインよりビルバインのほうが好き
646 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:18:20.36 ID:rpBXKN7W.net] (話に付いてこれてない香具師が居るな
647 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:20:32.85 ID:rpBXKN7W.net] >そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ ちな1つのクラスのメソッドの定義が必ずしも同一の翻訳単位内とは限らないから、 相対インデックス指定の出番は無い=コンパイル時解決は不可能
648 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:26:01.49 ID:hoeVnODB.net] >では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ 実行時に実行バイナリが決めるに決まってるだろ リンカがリンク時に静的に決めるとでも思ってるの?すげえなそのリンカ
649 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:27:21.13 ID:anCj3LhS.net] >>633 それはオーラロード
650 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:46:56.51 ID:KNEFHTDE.net] よく知らんけど、多くの場合vtblを作るのはコンパイル時であって、リンク時でも実行時でもないのでは?
651 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:50:36.00 ID:h6as2k/z.net] >>635 vtbl内のアドレスを最終的に決めるのはリンカなんだろうけど、それは 「オーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない」と両立するので 反論ぽく挙げてる意味がわからない。
652 名前:デフォルトの名無しさん [2021/05/02(日) 13:51:49.77 ID:AyQRjFej.net] ビルバインはもっと禍々しいデザインになる予定だったが、競合アニメだったマクロス・シリーズの影響で変形ギミックが追加され色も派手になった
653 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:53:08.50 ID:B3yuABqk.net] >>637 分かってくれてありがとうw
654 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 13:53:56.96 ID:01FRJ74M.net] おまいら中身のある会話しろよ ひまなの?
655 名前:はちみつ餃子 mailto:sage [2021/05/02(日) 15:30:38.46 ID:VAfyzxcR.net] せやで。
656 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 18:29:19.65 ID:r2Ed4Ypi.net] >>627 実際にプログラムを改修したりする場面では継承とテンプレートどちらでやるか 悩むってのはよくある話。 テンプレートだと元のクラスをいじらなくちゃならないからためらいがち。 その点継承だと元のコードいじらなくて(あるいは最小限の修正で)済むからな。 継承してテンプレートってのもなしじゃないがw継承するくらいなら、テンプレートまで やんないw
657 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 18:44:15.42 ID:01FRJ74M.net] 継承とテンプレートって全然違うけど 悩む場面が想定出来ない
658 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 19:07:17.74 ID:ZwmHpnzp.net] もう継承はしなければしないだけ偉いっていう気持ちになって久しい つーかOOPに飽きてるというか見限ってる C++を使ってるのは単に自由度が高くてパフォーマンスが良いから
659 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 19:55:42.70 ID:BSsO48AF.net] OOPに飽きてる俺すげー ってかw
660 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 20:02:15.30 ID:aspEWHUD.net] 普段どの程度の規模のどういうコード書いててその結論に至ったかで評価が変わるな
661 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 20:06:12.37 ID:aspEWHUD.net] >>644 改修にテンプレートがどう役立つのか想像つきにくいけど そのコードが前提としてる特定の型以外でも受け入れられるようにするとか? (それで継承とテンプレートどっちが優れてるという話にはならない気がするが
662 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 22:27:50.57 ID:r2Ed4Ypi.net] >>649 > そのコードが前提としてる特定の型以外でも受け入れられるようにするとか? まあ、一番単純なパターンだとそれだね。 まあ、自分は>>621 ではないので、 > (それで継承とテンプレートどっちが優れてるという話にはならない気がするが その真意はわからんけど、自分の経験でも対処療法的に継承でやっつけちゃうより やっぱりテンプレート化しときゃ良かった、と思ったときは多々あったw (「神は細部に宿る」んだわ、ほんとw)
663 名前:デフォルトの名無しさん mailto:sage [2021/05/02(日) 22:42:08.00 ID:Uu9e0iPh.net] 低レイヤーコードの置き換えを前提にモデル化できるってのがオブジェクト指向の一つの売りだが まああんまりそこの置き換えってしないわけだわな。 言うほど有効な場面は多くないってのはそれはそう。 素直に関数かけやって場面のが圧倒的に多い。
664 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 03:06:36.21 ID:cgOLnSCp.net] >>651 オブジェクト指向や継承の概念を使いまくっても、メンバ関数の形で 関数は書きまくるよ。
665 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 03:09:53.91 ID:cgOLnSCp.net] >>651 >低レイヤーコードの置き換えを前提にモデル化できるってのがオブジェクト指向の一つの売りだが >まああんまりそこの置き換えってしないわけだわな。 >言うほど有効な場面は多くないってのはそれはそう。 めちゃくちゃ低レイヤーな部分の書き換えは余り起こらないけれど、 クラスは階層的に継承して行くから、中間的な部分は結構修正が入る。 また、やはり仮想関数(ポリモーフィズム)の作法は便利。
666 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 03:15:32.93 ID:cgOLnSCp.net] >>653 というか、基本クラスの Animal 的なクラスの修正はそんなに頻繁には入らなくて、 Dog, Cat, Lion, Bird, Fish みたいな部分の修正がプログラミングの主戦場になる。 例えばゲーム作りの場合、Animalクラスの中にwalk(), eat(), battle(), sleep(), jump(), set_velocity(), set_position() などを仮想関数で用意しておいて、 Animalを継承したDog, Cat, Lion, Bird, fishみたいなクラスがそれぞれ どのように歩いて、どのように食べて、どのように戦って、どのように寝て、 どのようにジャンプするかをプログラムするというのはとても便利。 クラスや継承、仮想関数の概念が無ければその様に便利にプログラムする ことは簡単にはいかない。
667 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 03:37:22.90 ID:ndSqMpB2.net] シンプルにポリモをやるための継承はいいんだけど それ以外をやるための道具として流用し始めると途端におかしくなるって経験上思ってる
668 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 06:47:59.32 ID:J4qyGfu1.net] >>654 そういうゲームみたいなシチュエーションがそんなにあるわけじゃないって話だよ。 よっぽどプログラマ間で共有できる抽象概念がない限り逆にわかりにくくなることのが多い。
669 名前:デフォルトの名無しさん [2021/05/03(月) 06:56:42.03 ID:O7+GYvY4.net] 派生関係がなくても関数名を一致(つまりオーバーロード)させるだけで動いてくれるテンプレートのほうが楽なことが多い。 実際、最近C++に追加されている機能は大部分が派生関係のないテンプレートクラス。 一方、派生して使うiostream系クラスは機能追加される気配がまるでない。
670 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 09:29:12.51 ID:1Xubdwf1.net] というか、単に間違ったクラス化や間違った継承してた奴が多かったんじゃないの >>657 クラステンプレートでも結構継承使ってるぞ
671 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 10:18:11.42 ID:/gB1psu8.net] 皆様おはようございます ちょっと質問させてください テンプレートクラスを宣言定義する時に、ヘッダーに定義を書かないとエラーを吐いてしまいます テンプレートクラスのヘッダーファイルを、他のヘッダーファイルにインクルードして使う場合、なるべくテンプレートクラスのヘッダーに必要なファイルをインクルードをしたくないので、テンプレートクラスをヘッダーソースに分けて記述できれば嬉しいのですが…… //テンプレートのヘッダー template<class T> class Hoge{ public: Hoge(); }; //テンプレートのソース template<class T> Hoge<class T>::Hoge(){ cout<<“hego !”<<endl; } //テンプレートを使うクラス(別なヘッダーファイル) class UseHoge{ public: UseHoge(){ Hoge hoge; } }; これをメインで記述すると未解決の外部エラーになってしまいます テンプレートをUseHogeのヘッダーソースに分けて記述すればエラーは出ないのですが出来るなら独立させたいです…… 何かいい方法がありますでしょうか?
672 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 10:27:08.26 ID:jyja/vBX.net] Hogeを使う型で具体化する話?
673 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 10:32:39.67 ID:1Xubdwf1.net] 基本的にテンプレートの実装をソースに書くことは出来ないよ 与える型を決め打ち(明示的実体化)すれば出来るけど、当然汎用性は大幅に下がる
674 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 11:41:17.40 ID:/gB1psu8.net] Hogeをvectorやunique_ptrの様に、インクルードすればどこでも使えるようなテンプレートクラスにしたいのですが、そういう場合はHogeの定義もヘッダーに記述して、そのヘッダーを適宜インクルードするような形になるんでしょうか?
675 名前:デフォルトの名無しさん mailto:sage [2021/05/03(月) 11:46:53.45 ID:ndSqMpB2.net] それを出来るようにするためのexportという機能が昔の標準規格に定義されてたんだが 難しすぎてほとんどのコンパイラが実装できなかったので消えた