C++相談室 part161

**デフォルトの名無しさん** · 2022/05/21(土) 21:23:29.59

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

**デフォルトの名無しさん** · 2022/09/29(木) 14:30:55.43

>>803 何の前提も無ければ自分がソース持ってないところでオーバーライドされてる可能性もあるので、
いろいろ前提を絞らないと無理かと。
override （「演算子」じゃなくて「キーワード」）があったとしても、付け忘れてる可能性もあるし。

**デフォルトの名無しさん** · 2022/09/29(木) 15:19:58.87

>>804
失礼、修飾子でした。
やっぱそうですよね。
継承が３階層あって、その中間階層クラスのメンバ関数なので調べにくいのですが、
地道に１つずつチェックしようと思います。

**デフォルトの名無しさん** · 2022/09/29(木) 15:27:09.76

ヘッダに実装が書かれててもエディタでショートカット1個押して折りたたむだけでインターフェースすぐわかるくね？

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

まっとうならバイナリなりだけ開発環境でインポートすれば、
綺麗にインターフェイスが見える。

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/29(木) 17:12:42.79

共有オブジェクト (ダイナミックリンクライブラリ) の段階にまでなってしまうと型は別のところから与える必要があって、
基本的にはビルドの時に型情報を表すなんらかのファイルも生成できるけど、めんどいのは言語をまたぐときなんよね。
Windows API はいろんな言語から使えるような (バインディングの生成元に出来るような) メタデータを提供するという形で
対処しているのでこのへんは Windows API に限らず使いやすいように規格化や環境整備が進むことを期待している。

**803** · 2022/09/29(木) 17:14:04.54

今はLinuxでgcc+vimを使っています。
どういう環境なら見えますか？

**デフォルトの名無しさん** · 2022/09/29(木) 18:21:37.90

gtagsとか?

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/29(木) 21:13:35.71

>>809
近頃は vim も LSP に対応してるはずだから clangd と合わせて使えばいいんでないの。
わいは vim についてはよう知らんけど VSCode では出来ているから原理的には出来るはず。

**デフォルトの名無しさん** · 2022/09/29(木) 21:39:32.67

>>810,811
似たようなツールでdoxygenを使ったら簡単に見つけれるようになりました～
ありがとうございます！

**デフォルトの名無しさん** · 2022/09/29(木) 21:44:06.62

似てねーw

**デフォルトの名無しさん** · 2022/09/29(木) 21:59:47.36

ええ…

**デフォルトの名無しさん** · 2022/10/03(月) 10:37:30.67

>>795
obj と lib と h (hpp) だけじゃ不十分
バージョン管理も必要
これ重要

**デフォルトの名無しさん** · 2022/10/03(月) 10:40:19.01

>>790
template ですね判ります

**デフォルトの名無しさん** · 2022/10/05(水) 11:46:44.33

サイズが可変な自作クラスXのvectorを持ちたいとします。
このとき、Xの実体をいくつかvectorに入れて不用意に各要素のサイズを変更すると、メモリの割り当てがおかしくなりますよね？
実体ではなくポインタを持つ以外のワークアラウンドはありますか。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/05(水) 11:58:22.13

>>817
メモリの割り当てがおかしくなると思う事例をコードで説明して。

**デフォルトの名無しさん** · 2022/10/05(水) 12:31:37.02

>>817
「サイズが可変なクラス」の簡単な具体例を教えてくれないかしらん？

**デフォルトの名無しさん** · 2022/10/05(水) 12:38:22.59

>>817
出来ます
Xの参照(ポインタ等)のベクターを持ちます
Xのサイズが可変でバラバラでも構いません

もしXのサイズに上限値があるならば
別の方法としてその上限値サイズのベクターを用意する方法もあります

**デフォルトの名無しさん** · 2022/10/05(水) 12:52:15.30

>>819
boost::multi_array の resize

**デフォルトの名無しさん** · 2022/10/05(水) 12:53:20.63

>>820
？
それは>>817の最終行の冒頭と何が違いますか

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/05(水) 13:05:31.97

sizeof の結果は常に定数なんだよね……。
https://timsong-cpp.github.io/cppwp/n3337/expr.sizeof#6
(C では VLA まわりで定数にならない場合もあってその挙動を拡張として取り入れている C++ 処理系もある。)
そういう意味ではサイズが可変なクラスは存在しない。

>>821
boost::multi_array もそれ自体の大きさは一定。
内部的にはポインタで保持してる。

**デフォルトの名無しさん** · 2022/10/06(木) 11:24:20.53

やっぱり817が思ってる「おかしくなりますよね？」の最小コード提示してもらわないと
実はそれおかしくならないって結論になりそうなんだが？

**デフォルトの名無しさん** · 2022/10/06(木) 14:37:24.06

つまりおかしくなる理由が分からない人が相談に答えようとしているわけだな。

**デフォルトの名無しさん** · 2022/10/06(木) 15:08:29.15

>>819,821,823の流れで解決してると思うのだが
>>817が返答も何もしないので>>824のようなのが出てくる

**デフォルトの名無しさん** · 2022/10/06(木) 18:12:29.65

「サイズ(sizeof)が可変なクラス」なんて存在しないから817が何かを勘違いしてるのは確かだが
何をどう勘違いしてるのか分からんからお前さんの信念でコード書いてみなって話だろ
別におかしくない

**デフォルトの名無しさん** · 2022/10/06(木) 21:12:38.87

>>821で>>817の考えていることは明らか
>>823以上は蛇足だよ

**デフォルトの名無しさん** · 2022/10/07(金) 02:21:50.23

>827
単にお前の読解力の話でしかなかったのか。
「サイズが可変な」はvectorに掛かってると考えるだろうふつう。理由は
> 「サイズ(sizeof)が可変なクラス」なんて存在しないから
と自分で指摘してるとおり。

**デフォルトの名無しさん** · 2022/10/07(金) 06:51:34.90

「サイズが可変な」はクラスに掛かってると考えるだろうふつう。vectorは当然サイズ可変なんだから

**デフォルトの名無しさん** · 2022/10/07(金) 07:35:25.67

sizeof(std::vector<T>)なんて気にせんだろふつー

**デフォルトの名無しさん** · 2022/10/07(金) 07:47:52.68

まあクラスのサイズが変わるようなイメージだったよね

**デフォルトの名無しさん** · 2022/10/07(金) 08:23:09.11

コード見せろ、この日本語が分からない奴に
このスレは無理

**デフォルトの名無しさん** · 2022/10/07(金) 08:23:45.29

質問者です
皆さんのおかげで解決しました
ありがとうございます

**デフォルトの名無しさん** · 2022/10/07(金) 08:24:03.77

もうこの話は終了でよろしくお願いします

**デフォルトの名無しさん** · 2022/10/07(金) 11:13:53.12

817の類似
https://ideone.com/81vcNn
e1, e2 と list の要素は別物だけど　(2) の操作で list も同じく反映するようにするには
list を vector<X*> として　ポインタ渡す他に何か手段あるのかな

**デフォルトの名無しさん** · 2022/10/07(金) 11:34:57.30

std::vectorもboost::multi_arrayも要素数の変更ができるけど、その可変可能個数要素を格納する領域はクラスのインスタンスとは別のヒープ領域に確保されるようになっていて、クラスのインスタンにはそのヒープ領域へのポインタが格納される
したがって要素数を変更してもクラスのインスタンのサイズは変わらない
だよね？

**デフォルトの名無しさん** · 2022/10/07(金) 11:35:56.48

インスタンじゃなくてインスタンス…

**デフォルトの名無しさん** · 2022/10/07(金) 11:42:47.63

>>837
なぜ上で書かれてるのと同じことを書きたくなったの？

**デフォルトの名無しさん** · 2022/10/07(金) 12:34:55.78

>>836
listに手を入れるとか手段はあるだろうけどそもそも
> list を vector<X*> として　ポインタ渡す
で何が問題なのかを書いた方が良いかと

**デフォルトの名無しさん** · 2022/10/07(金) 12:43:53.29

>>840
自分で質問しといてなんだけど、たいした問題点でもなかったりするんだよな…

vector<X*> list; だと要素をアクセスする際に記述が煩雑になるところ
　list[i]->size(); ←おけ
　list[i]->push_back(hoge); ←おけ
　(*list[i])[j]; ←きもい

**デフォルトの名無しさん** · 2022/10/07(金) 12:54:10.56

実体のポインタを list に詰まず new したものを詰んだ場合
お漏らしやタングリングポインタになるかもしれんってのもあるかな
これだと問題点が前提とは別のところになりそうではある

**デフォルトの名無しさん** · 2022/10/07(金) 13:55:22.13

>>841
ラッパー書きゃよろしいがな

template <typename T>
class Vector: private vector<T>
{
using Base_ = vector<T>;
public:
using Base_::push_back;
using Base_::size;
const typename remove_pointer <T>::type &operator [] (size_t i) const {return *Base_::operator[] (i);}
typename remove_pointer <T>::type &operator [] (size_t i) {return *Base_::operator[] (i);}
};

Vector<X*> list;
list[i]->size();
list[i]->push_back(hoge);
list[i][j];

**デフォルトの名無しさん** · 2022/10/07(金) 14:39:47.78

>>841
> 　(*list[i])[j]; ←きもい
list[i]->operator [](j) ← う～ん、もっときもいかw

>>842
まあ今時生ポインタは使わんわな
shared_ptr とかを入れれば多少安全かと

**ハノン** ◆QZaw55cn4c · 2022/10/07(金) 19:06:21.61

>>827
http://www.kouno.jp/home/c_faq/c2.html#6
のことでしょ？
これはもう C89 の昔から言われ続けており、太古の C99 でも
http://seclan.dll.jp/c99d/c99d04.htm#dt19990726
のとおり導入されたわけですし

今更なんですけれどね

**デフォルトの名無しさん** · 2022/10/07(金) 19:21:05.99

>>834
どう解決したのかコメントを求む
まだ憶測他で引っ張ってるし

**デフォルトの名無しさん** · 2022/10/07(金) 19:57:27.07

>>845
それはただのポインタトリックであってsizeof(info_t)が可変になる訳じゃない
というかそのページでもsizeofのこと説明してんじゃん
相変わらずの無能っすね

**デフォルトの名無しさん** · 2022/10/07(金) 20:10:14.06

>>847
元の質問>>817はサイズが可変としか言っていない
つまりsizeofが固定であり可変でないという話こそどうでもよい話
本件は>>845氏の指摘する可変なサイズの構造体を作れる話が適切に該当していると思う

**デフォルトの名無しさん** · 2022/10/07(金) 21:32:58.03

>>819と聞いて本人は>>821と答えてるのに
何でそんな解釈を無理やりしてるのかサッパリ分からん

**デフォルトの名無しさん** · 2022/10/08(土) 01:45:23.92

>>841
思い出したけど boost::ptr_vector なるものもある

**デフォルトの名無しさん** · 2022/10/08(土) 03:10:20.17

クラスメンバBの初期化が終わる前に、メンバAのコンストラクタにBのアドレスを渡すのって合法ですか？

**デフォルトの名無しさん** · 2022/10/08(土) 08:08:39.60

マルチアレーで思い出したけど、多次元配列クラスのSTL入ってどうなった？
boostとか自作クラスで対応せよってのは暴論だぜ
前者はパフォーマンス微妙だし管理されてない、後者はそれ言うなら何でもそうじゃん

**デフォルトの名無しさん** · 2022/10/08(土) 10:25:38.57

>>851
アドレス渡すだけなら合法
中身触ったら違法

**デフォルトの名無しさん** · 2022/10/08(土) 13:47:19.43

>>852
template <typename T, size_t N0, size_t N1>
using multi_array = array <array <T, N0>, N1>;

**デフォルトの名無しさん** · 2022/10/08(土) 14:59:34.51

>>854
センスね～～～

**デフォルトの名無しさん** · 2022/10/08(土) 15:04:31.64

>>855
ではセンスある解を!

**デフォルトの名無しさん** · 2022/10/08(土) 15:08:15.47

>>852
std::mdarrayのことなら揉めに揉めて伸びに伸びて今は一応C++26の予定
でもまだグチグチ揉めまくって収拾がつかなそうだからもう無理じゃないかな
代わりにstd::mdspanっていう配列に被せるガワが入りそう

**デフォルトの名無しさん** · 2022/10/08(土) 15:56:11.12

各次元の長さが可変で、全添字の走査が速くて、メモリの並びがFortran流かC流か選べるだけで良いのに何を揉める必要があるのか

**デフォルトの名無しさん** · 2022/10/08(土) 16:31:31.20

その程度なら自前で直ぐに作っちまいそうだが
標準に入ってることが意味あるんだろうな

**デフォルトの名無しさん** · 2022/10/08(土) 18:03:00.23

そりゃそうじゃね
「std::vectorよりも自作の配列クラスの方が優れてる」という主張が本当だったことがない

**ハノン** ◆QZaw55cn4c · 2022/10/08(土) 19:46:47.28

>>849
無能君はひっこんでなさい

>>848
ですよね！

**849** · 2022/10/08(土) 20:25:53.87

すいませんでしたw

**デフォルトの名無しさん** · 2022/10/08(土) 21:43:59.65

>>862
こちらこそ申し訳ございませんでしたｗ

**デフォルトの名無しさん** · 2022/10/09(日) 00:52:23.28

SIMD まで自分ではやりたくないのでnumpyを呼ぶのほうが早い

**デフォルトの名無しさん** · 2022/10/09(日) 17:16:44.85

>>864
じゃあ全部Pythonでよくねーか？

**デフォルトの名無しさん** · 2022/10/09(日) 20:20:03.73

>>865
実際自分にとってはそんな感じですね。C++でpython とcudaとかopenmpを糊付けしている感覚があります

**デフォルトの名無しさん** · 2022/10/14(金) 14:32:13.11

set, mapというデータ構造があります。
mapはキーと値のペアをハッシュテーブルや2分探索木に格納しているのでしょうか？

**デフォルトの名無しさん** · 2022/10/14(金) 15:00:32.18

平衡二分探索木です
ハッシュテーブル版はunordered_*です

**デフォルトの名無しさん** · 2022/10/14(金) 15:09:19.24

ハッシュテーブルの方が大抵の場面で速いと思ってええんか？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/14(金) 15:26:57.00

>>869
データの性質や使い方によるのでなんとも言いにくいが基本的にはハッシュテーブルが速いことは多い。
差し替えるのは簡単だろうし、やりたいことをとりあえずやってみて測定すればいいんでね？

**デフォルトの名無しさん** · 2022/10/14(金) 15:33:11.96

>>869
実際にベンチマーク取らないとわからない。
基本的には種類が少ない場合は計算の軽い探索木が、多い場合は定数オーダーのハッシュが有利。

**デフォルトの名無しさん** · 2022/10/14(金) 19:23:56.82

>>871
ハッシュテーブルのサイズ、という地雷的制約は好まないのですけれどもね

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/15(土) 03:19:05.65

std::map::operator[] は O(long(N)) のオーダーなんだが、
std::unorderd_map::operator[] のオーダーは平均で O(1) 、最悪で O(N) ということになってんよね。
意図的に最悪を引き当てる、つまり攻撃に晒されるような状況では unorderd_map のほうが不利になる可能性もある。

**デフォルトの名無しさん** · 2022/10/15(土) 18:57:25.60

C++の例外処理は、class SomeClass {}; と中身の無いクラスであっても、
throw SomeClass{}; をcatch(SomeClass) {・・・}
で受け取ることが出来るらあしいけど、
どういう仕組みでcatchは、例外の種類を識別してる？
"SomeClass"のようなclass名の文字列のポインタでも一緒に渡している
のだろうか？
typeid(x)は、RTTI(実行時型情報)が必要で、仮想関数が定義されて無いクラス
に対しては上手く働かないのではなかったっけ？

**デフォルトの名無しさん** · 2022/10/15(土) 21:57:03.29

まず基本を禿の本でも規格票でも読んで
C++例外処理ってそもそも何ってとこをわかってから
出直したら？　そんな有様じゃマトモなレス付かないよ

**デフォルトの名無しさん** · 2022/10/15(土) 23:57:29.06

>>874 typeid と同等の情報で照合すれば可能ではあるんだから、何を不思議に思うことがあるのか。
「上手く働かないのでは」なんて言うぐらいならコード書いて確かめればいいだろうし。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/16(日) 01:59:22.59

>>874
例外を送出してスタックの巻き戻しをするのは例外を送出する側 (受け取る側ではなく) なんだよ。
つまり送出される例外オブジェクトの型はわかっている。
むしろどこまで巻き戻せばよいか (送出されるオブジェクトの型に対応する catch はどこにあるか) の情報が動的なものだ。

**デフォルトの名無しさん** · 2022/10/16(日) 14:48:55.82

メンバ変数をまったく使っていないメンバ関数を見つける方法ってなんかある？
CppCheckとかでできるんだっけ

**デフォルトの名無しさん** · 2022/10/16(日) 15:16:25.24

まあ普通の静的解析はチェックしてくれるのでは

**デフォルトの名無しさん** · 2022/10/16(日) 17:18:37.82

>>876
typeidは仮想関数を持っているクラスにしか働かないと思っていたが、
働くのか。

**デフォルトの名無しさん** · 2022/10/16(日) 17:21:15.08

typeid(x)の返すオブジェクトは完全にtype_info型なのか、
それとも、type_infoを継承したクラスなのか、どっち？

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/16(日) 22:40:17.52

>>881
std::type_info から派生したクラスであることはあり得る。
https://timsong-cpp.github.io/cppwp/n3337/expr.typeid#1

**デフォルトの名無しさん** · 2022/10/17(月) 05:46:15.36

それこそtypeidに聞いてみりゃいい
cout << typeid(typeid(some_one)).name();

**デフォルトの名無しさん** · 2022/10/17(月) 22:30:57.72

T x;
T y;
に対して
x=move(y); //(1)
とした場合、時系列的に
1. move代入演算子 T::operator=(T &&a);がyの中身をxに入れる。但しこれは、2とも
　関連しているがswap(x,y)とされることもある。
　swap(x,y)を使わない場合には、xにyの中身を入れる前に元々の xの中身が削除される。
2. swapを使って無い場合には、続いてmove代入演算子 T::operator=(T &&a);が
　y のポインタメンバなどに null 値を書き込む。
3. (1)の式の最後で、右辺のオブジェクト y に対してデストラクタが呼び出される。
4. デストラクタは、y ポインタメンバが null だと何も行なわない。
　yの中身がxに交換されていた場合は、もともとxの中身だったものを削除する。

というような流れになるという理解で合ってる？

**デフォルトの名無しさん** · 2022/10/17(月) 23:38:12.11

実装依存では

**デフォルトの名無しさん** · 2022/10/17(月) 23:46:42.02

>>885
特に確認したいのは、
>3. (1)の式の最後で、右辺のオブジェクト y に対してデストラクタが呼び出される。
の部分。
stroustrup氏によれば、yに対するデストラクタが必ず呼び出される、ということ
らしいが、それは常に正しいのかな？

**デフォルトの名無しさん** · 2022/10/18(火) 00:25:45.29

>>886
> stroustrup氏によれば、yに対するデストラクタが必ず呼び出される、ということ
> らしいが、それは常に正しいのかな？
そういう型を作ることはできるけど、そんな動作をしたらスコープアウトで走るデストラクタを
止めないといけなくなって非常に使いづらくなる。正しくなさそう。
あなたが何か読み間違えてるものと思われる。

**デフォルトの名無しさん** · 2022/10/18(火) 00:27:10.46

>>887
move代入の右辺のオブジェクトは、事後にデストラクタが呼び出される、
と書いてあったと思うが。

**デフォルトの名無しさん** · 2022/10/18(火) 03:36:36.81

xの元の中身も適切に破棄されますよっていう話を歪んだ理解してそう

**デフォルトの名無しさん** · 2022/10/18(火) 08:32:29.82

>>888
[訂正]
正しくは、
・move代入演算子 T::operator=(T &&a) 自体はデストラクタを呼び出さない。
・x=move(y) と書いたとき、コンパイラが右辺の y に対してデストラクタを呼び出す。

2つのパターンが有る。パターン1:swapを使う。パターン2:swapを使わない。
いずれにせよ、コンパイラによって y.~T() が呼び出される。

擬似等価コード:
x.operator=(rvalue(y));
y.~T();

パターン1:
T &T::operator=(T &&a) {swap(*this,a); return *this:}

パターン2:
T &T::operator=(T &&a) {thisの中身を削除; aの中身をthisにコピー; aにnull値を書き込む; return *this;}

**デフォルトの名無しさん** · 2022/10/18(火) 08:42:53.23

>>888 あなたの読み間違いではないと主張したいなら出典を挙げられるのがよいかと。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/18(火) 12:16:32.80

>>888
右辺と右辺値を混同しているとかじゃない？右辺値と右辺値参照も違う概念。

右辺値 (というか prvalue) が完結式の終わりで解体されるのは保証された動作だけど、
std::move でキャストした結果はあくまでも参照を右辺値参照として返すってだけで
元のオブジェクト (この場合は y) は依然として左辺値だよ。
y のデストラクタが呼ばれるのは y のスコープの終わりであることは保証される。

**デフォルトの名無しさん** · 2022/10/19(水) 01:49:23.30

>>892
>y のデストラクタが呼ばれるのは y のスコープの終わりであることは保証される。
なるほど。
でも結局、
T x;
T y;
x=move(y); //(1)
と書くと、(1) の部分で、
x.operator=(yを右辺値化したもの); //(2)
が行なわれて、
yの生存期間が終わる地点で、yのデストラクタであるところの y.~T() が呼び出される、
ということになることは間違いなのですね。
つまり、(2)が行なわれたら yはもはやmove後なのだから、yのデストラクタ呼び出しが
省略されるということではなく、yのデストラクタは絶対に必ず呼び出されるわけですね。
だから、T::operator=(T &&a) は、T::operator=(T &&a)の処理が終わった後に、
コンパイラによって yのデストラクタが呼び出されることを前提に処理しなければならない、
ということになる。

**デフォルトの名無しさん** · 2022/10/19(水) 02:44:50.18

>>893
誤字訂正です:
誤: ということになることは間違いなのですね。
正: ということになることは間違いないのですね。

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/19(水) 04:13:29.85

>>893
そう。 move assignment operator と呼ばれてはいるが
右辺値であるということがわかる以上の違いはない。

ムーブは寿命を左右せず、内容の状態がどうなるかは実装次第。
具体例で言えば std::unique_ptr はムーブ後には空になる (メンバ関数 get は空ポインタを返す) ことが保証されるが、
std::string は (新たな内容が与えられるまでは) 未規定の値になる。

右辺値参照が導入されたのは C++11 からで、
デストラクタのタイミングが変わってしまうような変更を入れられるわけがない。

**デフォルトの名無しさん** · 2022/10/19(水) 23:39:12.93

C＋＋で15年ぶりにプログラミングをすることになったんだけど、
C++11以降のことは何も知らないのでまずは復習もかねて勉強することにした
今でもbjarneの本が初心者にとって一番のテキストなの？
それとももっとシンプルで分かりやすい本が出てるのでしょうか？

**デフォルトの名無しさん** · 2022/10/19(水) 23:45:19.38

>>895
今考えてみれば、条件分岐の中だけでmove代入される場合も有るからかも知れませんね。

**デフォルトの名無しさん** · 2022/10/20(木) 03:01:20.64

昔のC++知ってるならとりあえずEffective Modern C++.でいいんじゃないの

**デフォルトの名無しさん** · 2022/10/20(木) 06:31:14.16

>>896
本は読者との相性があるから一概には言えないが
俺的にはやっぱ禿の本だな
変に手加減してこないところに安心感がある

ただし「プログラミング言語C++第4版」は
あくまでC++11で、C++14以後には触れていないので
構造化バインディングやコンセプトは学べない
俺はこのあたりはここやQiitaできっかけだけ拾って
あとは規格票やhttps://cpprefjp.github.io/で憶えてる

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/20(木) 13:52:31.60

>>896
C++ はごちゃごちゃした歴史的事情を継ぎ接ぎして出来ているので
説明を整理しようとするとかえって事情がよくわからなくなる。
どう頑張ったってそんなに簡潔にはならんよ。

場当たり的に追加された変則的なルールでも
実際に挙動に絡んでくるのなら知っておくしかしょうがないし、
きちんとした説明はそれなりの分量にもなる。
おそらく >>899 が述べる「変に手加減してこない」というのはそういう意味だと思う。

**デフォルトの名無しさん** · 2022/10/20(木) 17:53:11.99

ビャーネの本、章の構成がよく分からんのだけど何がどうしてああなったん

**デフォルトの名無しさん** · 2022/10/20(木) 18:26:02.35

昔は、ロベールが鉄板だった

**デフォルトの名無しさん** · 2022/10/20(木) 18:47:34.03

bj氏の本のダブルディスパッチの部分と、次のVisitorの部分、
どっちもよく分からなかった。
まず、前者のShape&の引数が何のためにあって、どういう役割を果たしているか
誰か教えて。