C++相談室 part155

**デフォルトの名無しさん** · 2021/03/24(水) 12:07:15.39

※前スレ
C++相談室 part154
https://mevius.5ch.net/test/read.cgi/tech/1610096040/

テンプレここまで

**デフォルトの名無しさん** · 2021/04/29(木) 08:34:23.25

>>540
反例を1個あげれば十分
あとは自分でかんがえろってこと

お前は何か役立つ回答をしたか？

**デフォルトの名無しさん** · 2021/04/29(木) 08:51:08.82

質問者がbegin()とend()の定義の必要性を把握しているのに対して
begin()のみではNGだとレスするのがそんなにﾄﾞﾔるほどのことなのかどうか……

**デフォルトの名無しさん** · 2021/04/29(木) 08:55:45.00

>>544
前者ってbeginのことだと思っちゃった？
お前日本人じゃないだろ

**デフォルトの名無しさん** · 2021/04/29(木) 09:04:34.25

>>542
ありがとうございます
v は必ずしも vector<int> ではなく vector<vector<int>> とかで、かついっぱい回るループを想定してるのでできるだけ定数倍を軽くしたいのですが、j を右辺値参照にすればコピーは起きないので相当マシと思って良いですかね

**デフォルトの名無しさん** · 2021/04/29(木) 09:07:08.51

右辺値参照つってもauto&&は左辺値参照も兼ねるぞ

**デフォルトの名無しさん** · 2021/04/29(木) 09:16:30.33

>>545
ちょっじゃあ>>538のレスのどこが反例だったの？？

**デフォルトの名無しさん** · 2021/04/29(木) 09:22:13.70

二個目の条件に反してる

**デフォルトの名無しさん** · 2021/04/29(木) 09:41:24.58

>>549
別に
https://ideone.com/VLjCjO

**デフォルトの名無しさん** · 2021/04/29(木) 10:20:12.63

https://ideone.com/bERbqr

**デフォルトの名無しさん** · 2021/04/29(木) 10:26:57.88

>>547
for()のカッコの中でiをjの参照として定義できたらそれでも良いんですが、そういうことはできるんでしたっけ？

**デフォルトの名無しさん** · 2021/04/29(木) 10:28:45.87

すみません「定義」というよりは、forのスコープの外にiの宣言はあって、for(ここ)でiがjの参照であることにできたら良いってことです

**デフォルトの名無しさん** · 2021/04/29(木) 10:29:35.81

>>551
ちょっそのforまで範囲forに含めるんなら>>535に加えてbegin()やend()が返す型がデリファレンス可能という条件が必要なんじゃ……

**デフォルトの名無しさん** · 2021/04/29(木) 10:35:45.46

は？加えて？
>>535に入ってるだろ
最初からrange-basedの話なのに屁理屈言ってるから突っ込んだだけだよ

**デフォルトの名無しさん** · 2021/04/29(木) 11:07:16.11

>>553
i が j の参照ということは
int& i = j;
という宣言が必要で、
int i;
としてしまったものを後で参照に変更ということはできない

**デフォルトの名無しさん** · 2021/04/29(木) 11:10:24.28

>>556
reference_wrapper って
i = ref(j);
みたいなことできませんっけ？

**デフォルトの名無しさん** · 2021/04/29(木) 11:52:35.69

>>557
無理
実体定義された変数を途中から参照に変更なんて

**デフォルトの名無しさん** · 2021/04/29(木) 12:28:01.48

ポインタと参照の決定的な違いはそこだね

**デフォルトの名無しさん** · 2021/04/29(木) 12:46:42.20

>>541
begin()とend()の型が一致してる必要はない（C++17～）

**デフォルトの名無しさん** · 2021/04/29(木) 13:03:31.68

https://negation.hatenadiary.org/entry/20111203/1322876171
↑で、簡単に書けば、
class Book {・・・};
class Novel : public Book{・・・};
class Comic : public Book{・・・};
class Shelf { public: std::vector<Book> list; ・・・ };
Shelf g_shelf;
int main(void) {
Novel n = Novel("Hoshio wo tugumono");
Comic c = Comic("Kimetsu no Yaiba");
Shelf s = Shelf();
g_shelft.list.push_back(n);
g_shelft.list.push_back(c);
}
のようになっているところがあるけど、
vector<Book>って、Bookの実体の動的配列で、
Book a[100];
とにら様なものだと思うんだけど、NovelやComicのクラスのバイトサイズが
Bookを越えたら、入りきれないと思うんだけど、これで合ってる？
合ってるとしたら、どういう仕組み？
もしかして、vector<Book>って、
Book *p[100];
みたいな配列なの？

**デフォルトの名無しさん** · 2021/04/29(木) 13:05:10.26

>>561
すまん。間違った。正しくはこう :
int main(void) {
Novel n = Novel("Hoshio wo tugumono");
Comic c = Comic("Kimetsu no Yaiba");
Shelf s = Shelf();
s.list.push_back(n);
s.list.push_back(c);
}

**デフォルトの名無しさん** · 2021/04/29(木) 13:10:29.61

>>561
s.list.push_back(n);のところはn(Novel)のBook部分を首チョンパしてコピーしたオブジェクトがpush_backされる
スライシングというよく知られたホラー現象

**デフォルトの名無しさん** · 2021/04/29(木) 13:10:34.24

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>());

**デフォルトの名無しさん** · 2021/04/29(木) 13:16:01.96

>>564
その認識で合ってる
561のShelfにはNovelやComicじゃなくて、そいつらから刈り取った生首が並んでる
絶対やったらいかんやつ

**デフォルトの名無しさん** · 2021/04/29(木) 13:19:09.72

>>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);
}

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/29(木) 18:07:20.75

パブリック継承している型のオブジェクトが基底クラスへ暗黙に型変換されるのは抑止する方法がないんだよな。

**デフォルトの名無しさん** · 2021/04/30(金) 01:30:09.20

>>567
Dog d;
の時に func( Animal &a )に対して、
func(d);
がエラーにならないということ？

**デフォルトの名無しさん** · 2021/04/30(金) 08:17:30.86

それは別に問題ない
func(Animal a)だとやばい

**デフォルトの名無しさん** · 2021/04/30(金) 09:32:28.19

funcがAnimalの情報しか使わないんなら別にいいんだけどね
単にポリモーフィズムにはポインタか参照が必要ってだけ

**デフォルトの名無しさん** · 2021/04/30(金) 09:52:57.56

shared_ptr<T>もいけるでしょ
スタックを使った60バイト近いメモリーコピーが発生するから最適ではないけど

**デフォルトの名無しさん** · 2021/04/30(金) 10:40:50.56

>>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;
}

**デフォルトの名無しさん** · 2021/04/30(金) 11:02:34.65

>>572
スライシングが発生してるのは g_list.push_back(a) であって、 func( Animal &a ) は関係ないでしょ。

**デフォルトの名無しさん** · 2021/04/30(金) 11:21:35.01

なんで範囲for文ってBOOST_FOREACHを完全に置き換えれるようにしなかったの？
>>537,542はそれで解決するし、逆順のループとかもできるのに

**デフォルトの名無しさん** · 2021/04/30(金) 11:34:29.27

ポリモーフィズム前提の時は、コピーコンストラクタはdeleteするのが良いのかね

**デフォルトの名無しさん** · 2021/04/30(金) 11:43:26.05

あー範囲forが使える条件とBOOST_FOREACH使える条件って違うのか
後者は自作クラスじゃ使えない？
あるいは使える条件が>>535と違う？

**デフォルトの名無しさん** · 2021/04/30(金) 11:48:46.39

>>573
この場合、スライシングが発生しても問題ない、という観点もあるかも。

**デフォルトの名無しさん** · 2021/04/30(金) 12:01:43.38

>>575
そしたら派生クラス同士でコピー出来んやろ、コピー禁止にしたいのでなければ書くべき(で派生のコピーコンストラクタで基底のコピーコンストラクタを初期化リストから呼ぶ

必ず派生させて使うのが前提ならコンストラクタをprotectedにするとかその辺のテクニックは大昔から色々出てる

**デフォルトの名無しさん** · 2021/04/30(金) 12:18:33.85

スライシングが起きるとき、基本クラス部分だけをコピーすることになるが、
その際、仮想テーブルへのポインタが継承クラス用のままだと、コピー後の
操作が危険になる可能性があるが、もし、仮想テーブルへのポインタを
基本クラス用に変えてしてしまえば、コピー後の動作は完全に基本クラス的に
なってしまうけれど、その反面、メンバー関数を呼び出しても特にメモリーの
破壊などは起きないはず。
そのようにしてしまえばスライシングが起きても問題ないような気が。

**デフォルトの名無しさん** · 2021/04/30(金) 12:31:22.41

>>578て書いたけど実際ポリモーフィズム目的の継承ツリーだとコピー禁止にしてること多いな・・
どうせポインタ(orスマポ)で管理するから確かにコピー禁止のが無難かもね

**デフォルトの名無しさん** · 2021/04/30(金) 12:38:12.34

>>570
それぞれのコピコンをプログラマが自由に記述できる以上、例えAnimalの情報しか参照しないとしても問題が起こることはあるんじゃね？
例えば、DogのコピコンはAnimal::cuterThanCat変数を強制的にtrueに書き換えてるかもしれない

**デフォルトの名無しさん** · 2021/04/30(金) 12:51:39.69

>>581
戦争勃発するぞ

まぁスライシングが常に危険とは限らないと言いたかっただけ

**デフォルトの名無しさん** · 2021/04/30(金) 14:49:19.98

誰かBOOST_FOREACHを自作クラスに使う条件教えてください

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/30(金) 16:01:39.38

>>583
https://www.boost.org/doc/libs/1_76_0/doc/html/foreach/extensibility.html

**デフォルトの名無しさん** · 2021/04/30(金) 20:24:33.87

>>579
>スライシングが起きるとき、基本クラス部分だけをコピーすることになるが、
>その際、仮想テーブルへのポインタが継承クラス用のままだと、コピー後の
>操作が危険
そんな恐ろしいことが！
と思って試したが、少なくともデフォルトのコピコンは仮想関数テーブルへのポインタを
コピー先の型に合わせて付け替えてくれるらしい

↓そうでなけれはfunc_with_ref(Animal a)の中でa2.get()がDogの値でなくAnimalの値を返す説明がつかない
https://ideone.com/eJMsYG

規格でどうなっているかは知らん

**デフォルトの名無しさん** · 2021/04/30(金) 20:25:50.19

訂正orz、
誤：そうでなけれはfunc_with_ref(Animal a)の中で
正：そうでなけれはfunc_with_copy(Animal a)の中で

**デフォルトの名無しさん** · 2021/05/01(土) 07:00:40.64

ていうかよく考えたらAnimalのコピコンは
Animalのコンストラクタでもあるのだから>>585の挙動は当然かorz

**デフォルトの名無しさん** · 2021/05/01(土) 09:21:42.94

コピコン

**デフォルトの名無しさん** · 2021/05/01(土) 09:28:33.15

コピコン
たまに見る
頭悪そう

**デフォルトの名無しさん** · 2021/05/01(土) 10:19:04.33

でもコピーコンストラクターって長いよね

**デフォルトの名無しさん** · 2021/05/01(土) 10:26:47.50

コンストラクタはコンストラ
コピーコンストラクタはコピコン
デストラクタはデストラ
アルゴリズムはアルゴ
と略すのが効率的

**デフォルトの名無しさん** · 2021/05/01(土) 10:31:05.38

取引先がそんな言葉を使ってきたら
今後の契約を考え直すかも
少なくとも評価はマイナス

取引先とそんな細かい内容を話す打合せも無いだろうけど

**デフォルトの名無しさん** · 2021/05/01(土) 11:21:44.35

>>591
気持ち悪い略語だな

**デフォルトの名無しさん** · 2021/05/01(土) 12:04:39.12

デストラｗ

**デフォルトの名無しさん** · 2021/05/01(土) 12:14:30.82

ctor,dtorは一般的な略語？

**デフォルトの名無しさん** · 2021/05/01(土) 12:14:41.90

機能を引き継ぐために継承して、インスタンス化して使うために移譲もしたい

継承も移譲もするのってありですか？

**デフォルトの名無しさん** · 2021/05/01(土) 12:45:03.96

わかんねえ
継承が相応しくない場合が山程あるのはわかった
継承が相応しくないが一部機能を引き継ぎたいときは、コードのコピペをするべきなのか？

**デフォルトの名無しさん** · 2021/05/01(土) 12:53:12.87

独立させる

**デフォルトの名無しさん** · 2021/05/01(土) 13:13:50.17

>>598
より小さいクラスか構造体として切り出すということ？

**デフォルトの名無しさん** · 2021/05/01(土) 13:18:13.99

private継承じゃダメなの？

**デフォルトの名無しさん** · 2021/05/01(土) 13:52:11.96

>>600
ダメってことはもちろんなくて、そう実装することにすればそう実装するだけだが、継承である以上は依存関係が生じるし、相応しくない場合もあるなあと思うだけ

**デフォルトの名無しさん** · 2021/05/01(土) 13:54:03.05

intをとるかcharを取るかで振る舞いを変えるオーバーロード関数って作れるんですか？
その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか？

**デフォルトの名無しさん** · 2021/05/01(土) 14:19:20.97

オーバーロードという単語を知っておきながら、何故できないと思ったんだ

**デフォルトの名無しさん** · 2021/05/01(土) 16:00:09.42

>>602
関数シグネチャってもんがあるわけよ。
リンカは関数名ではなくこのシグネチャでリンクする。
引数の型が変わるとこのシグネチャが変わるので、
プログラムというかコンパイラはそれを間違えることはない。

**デフォルトの名無しさん** · 2021/05/01(土) 16:28:04.60

intとcharは使う側が間違いやすいから
間違えたら問題がある場合は名前を変えよう

**デフォルトの名無しさん** · 2021/05/01(土) 16:37:35.74

>>604
厳密に言えばリンカは関数名しか見ない。
C++はオーバーロードのためにシグネチャの違いを関数名に埋め込むマングリングを行う。

**デフォルトの名無しさん** · 2021/05/01(土) 17:09:26.40

>>602
C++で関数呼び出しを書いた場合、どの関数が呼び出されるかは
Best Matching Algorithm で選ばれているので実引数が charの場合は、
同じ場所の仮引数がcharである関数を優先的に選ぼうとする。
もし、同じ場所の仮引数がcharであるものが見つからなければ、
同じ場所の仮引数が int であるものを探して、見つかればそれを選択する。
このとき、実引数と仮引数の型の「距離」のような概念があり、
距離が近いものが選ばれる。複数の引数が有る場合で、二つの引数で
距離が近い関数がどっちもどっちになる場合には、「曖昧」であると、
され、エラーになる。

>その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか？
ここであなたの言っている「見分ける」という意味が分かりにくいが、
オーバーロードされた関数は、C++レベルでは同じ名前に見えていてもが
アセンブラレベルでは別の関数名になっていて、別の関数として扱われていて、
別の関数が呼び出されているから「見分ける」以前問題になっている。

◆QZaw55cn4c · 2021/05/01(土) 17:16:10.99

>>591
コピコン以外は使わないです‥‥

**デフォルトの名無しさん** · 2021/05/01(土) 17:24:45.49

>>606
「リンカは関数名しか見ない」はおかしい。
リンカが見るのは、関数名を含むシグネチャをマングリングした結果のシンボル名。

**デフォルトの名無しさん** · 2021/05/01(土) 17:29:02.27

>>605
それは、実際そうだと思う。
char idx = xxx;
func( 'a' + idx );
と書いた場合、func(int)とfunc(char)のどちらが呼び出されるのかを
事前に予想するのは非常に難しい。
なぜなら、伝統的にCでは、char + char は、それぞれが int に昇格
されてから、int + int になって、結果も int になるとされていたから。

**デフォルトの名無しさん** · 2021/05/01(土) 18:00:18.46

ファイル出力で、1バイト出力と4バイト出力の違いは、単に人間が見るための
stdout出力とは訳が違って、後からファイルを入力する時にその部分のバイト数の違い
が大きな意味を持つので、オーバーロードの仕組みだけでコンパイラに自動振り分け
させるのは、分かりにくいバグを入れてしまう可能性がある。
なので、やはり、出力するのは1バイトなのか4バイトなのかを、明確に関数名で
区別できるようにした方が望ましいと思われる。

**デフォルトの名無しさん** · 2021/05/01(土) 18:45:41.91

>>609
そのマングリングした名前で関数を呼び出すことができるわけだし、関数名以外の何物でもないと思うが。
そもそもリンカはマングリングされているのかされていないのかも関知しないし。

**デフォルトの名無しさん** · 2021/05/01(土) 18:55:40.94

> 589 名前：デフォルトの名無しさん[sage] 投稿日：2021/05/01(土) 09:28:33.15 ID:18idEqJd [1/2]
> コピコン
> たまに見る
> 頭悪そう

>>595に何も言えねえ
頭悪そうｗ

**デフォルトの名無しさん** · 2021/05/01(土) 19:59:37.32

マングリング、ってなんかイヤらしいよね

**デフォルトの名無しさん** · 2021/05/01(土) 20:50:21.52

>>612
?h@@YAXH@Z みたいなのを関数名って言うのは違和感しかないわ

> そもそもリンカはマングリングされているのかされていないのかも関知しないし。
それを言うならリンカは関数かどうかすら関知してない

**デフォルトの名無しさん** · 2021/05/01(土) 21:00:22.23

>>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. ...

**デフォルトの名無しさん** · 2021/05/01(土) 21:25:44.91

私は「関数名」派
C++のコンパイラは元々はC++からCに翻訳してたわけだし

**デフォルトの名無しさん** · 2021/05/01(土) 21:27:05.03

まあどっちでもいいけど

**デフォルトの名無しさん** · 2021/05/02(日) 00:16:29.81

>>616
だなあ。
C++のコードにおいて、関数名と呼ぶ場合、それはマングリング込みとかのシグネチャではなく
あくまでもソースコード上にある関数の名前だからなあ。

>>618
これはあんまりどっちでも良くない。
つか、>>612の言い分を認めるとオーバーロード/オーバーライドってもんがなんだか分からなくなるｗ
同じ関数名で関数の実装を選べるってのがオーバーロード/オーバーライドだから。

**デフォルトの名無しさん** · 2021/05/02(日) 01:13:49.22

オーバーライドの意味も知らない子は無理して回答しなくていいよ

**デフォルトの名無しさん** · 2021/05/02(日) 01:21:37.53

C++初心者はクラス継承の学習にこだわりテンプレートの学習が後回しになるので、テンプレートが最適解になることが多いと悟るのが遅くなる

**デフォルトの名無しさん** · 2021/05/02(日) 01:23:19.71

オーバルライトは新しいからね。

**デフォルトの名無しさん** · 2021/05/02(日) 01:39:37.43

>>619
Cに翻訳された段階だと変数名まで含んだ名前が関数名
当然リンカの段階ではC++の関数名は残って無い
C++以外のドメインでどれが関数名かを議論すること自体意味がない

**デフォルトの名無しさん** · 2021/05/02(日) 01:40:39.79

>>610
されていたって...
今もそうだよ

**デフォルトの名無しさん** · 2021/05/02(日) 06:37:18.08

>>619
overrideキーワードは派生クラスで仮想関数を上書きするときに使う
overloadキーワードはcfront 1.0世代のC++で関数を多重定義する予告として使われていた

**デフォルトの名無しさん** · 2021/05/02(日) 08:57:49.73

基底クラス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対応は崩れるのだから
　関数名≠関数のシンボル
を示す例としてオーバーライドはオーバーロードと同じく妥当であることは変わりが無い

、と思うが知らん

**デフォルトの名無しさん** · 2021/05/02(日) 09:20:39.13

>>621
継承とテンプレートが対立するかのように考えてる時点で
テンプレートどころかクラスや継承もまともに理解できてないやつの発言にしか見えない

**デフォルトの名無しさん** · 2021/05/02(日) 10:53:26.72

>>626
丁寧な御説明ありがとう。
それで正しいですよ。

**デフォルトの名無しさん** · 2021/05/02(日) 12:10:24.45

このクソ議論見ても関数オーバーロードの仕様は失敗してるってのがよくわかる。

**デフォルトの名無しさん** · 2021/05/02(日) 12:12:19.26

…などと意味不明の供述をしており、

**デフォルトの名無しさん** · 2021/05/02(日) 12:47:09.45

悪い子: この仕様はクソだ！
普通の子: この仕様は〇〇だから良くないね
良い子: この仕様は〇〇だから良くないね、△△とすれば良いのに

**デフォルトの名無しさん** · 2021/05/02(日) 13:06:19.55

>>626
それは単に別のクラスで同じ名前のメンバ関数はシンボルが違うってだけの話だろ
オーバーライドは全く関係ない
そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない
オーバーロードと並べて語る意味が全くわからない

**デフォルトの名無しさん** · 2021/05/02(日) 13:16:03.71

ダンバインよりビルバインのほうが好き

**デフォルトの名無しさん** · 2021/05/02(日) 13:18:20.36

（話に付いてこれてない香具師が居るな

**デフォルトの名無しさん** · 2021/05/02(日) 13:20:32.85

>そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない
では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ

ちな1つのクラスのメソッドの定義が必ずしも同一の翻訳単位内とは限らないから、
相対インデックス指定の出番は無い＝コンパイル時解決は不可能

**デフォルトの名無しさん** · 2021/05/02(日) 13:26:01.49

＞では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ
実行時に実行バイナリが決めるに決まってるだろ
リンカがリンク時に静的に決めるとでも思ってるの？すげえなそのリンカ

**デフォルトの名無しさん** · 2021/05/02(日) 13:27:21.13

>>633
それはオーラロード

**デフォルトの名無しさん** · 2021/05/02(日) 13:46:56.51

よく知らんけど、多くの場合vtblを作るのはコンパイル時であって、リンク時でも実行時でもないのでは？

**デフォルトの名無しさん** · 2021/05/02(日) 13:50:36.00

>>635
vtbl内のアドレスを最終的に決めるのはリンカなんだろうけど、それは
「オーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない」と両立するので
反論ぽく挙げてる意味がわからない。

**デフォルトの名無しさん** · 2021/05/02(日) 13:51:49.77

ビルバインはもっと禍々しいデザインになる予定だったが、競合アニメだったマクロス・シリーズの影響で変形ギミックが追加され色も派手になった

**デフォルトの名無しさん** · 2021/05/02(日) 13:53:08.50

>>637
分かってくれてありがとうw

**デフォルトの名無しさん** · 2021/05/02(日) 13:53:56.96

おまいら中身のある会話しろよ
ひまなの？