ルールズ・オブ・プログラミング読書会vol.44
https://scrapbox.io/files/655372c161a776001bf71cc6.jpeg
開催日時
2025年10月28日（火） 19:30～21:00
開催URL
参加人数
3人
ウォーミングアップ
ルール19 作り直しは並列で行うこと
そんなにぶつかるか？
マージの間隔が長いと起きうる
道の途上で起こる小さな問題
この状況、まさに今週起こってました
代わりに並列システムを構築する
どういうこと？
鉄道の新路線に掛け替えるようなもの
新システム=新しい線路
旧線の隣に新線を作っていき、ある夜一気に付け替える
「一生旧システムで生きていく」勢がいる
なかなか移行してもらえない・・・
心中してもらう
例：APIのバージョン更新
外部要因だと踏ん切りがつくが、内部要因だと移行せずダラダラと続いてしまう
具体的事例
allocaですね（この読書会でよく話題に出てくる）
バイト配列をユニークポインタで管理しても同じことでは？
たくさんオブジェクトがあるとその分、メモリ確保解放が繰り返されてしまう
1MB以上は一気に確保できないんだ
細かいオブジェクトに対する用途
意識せず平気で大量のメモリを確保する輩はいる
そういうコンテナがC++26にある
std::inplace_vector
vectorのように伸びたりはしない
スタックアロケーターによるメモリー確保の実際
StackVector<ELEMENT>::~StackVector()
各要素にデストラクタを走らせるfor文が後ろからではなく前から走査している
作り直し！
newElements[index] = move(m_elements[index]);
ここはムーブ代入ではなく、配置newでムーブコンストラクタにするのが正解
誰もコンストラクタを呼んでいない
あるいはconstruct_atを呼ぶ
作り直し！
ここでやっていることと似たようなことをuninitialized_moveでできる
例外安全を気にしていなさそう
それならpop_backはそのまま値を返してもよさそう
コンストラクタやデストラクタを呼び出すが、メモリ確保はStackVector自身は一切行わない
UEでも似たようなつくりを見かけた
FMemStackとFMemMark
水平線上の雲
次回ここから
お悩み雑談室