C#使いのための割と安全なC++

C#使いのための 割と安全なC++ 2023/2/21 須藤（suusanex）

自己紹介  ID：suusanex（ connpass・Twitter・GitHub共通）  名前：須藤圭太  サイエンスパーク株式会社という独立系ソフトウェアベンダーに所属  4年ほど受託開発で、上流から下流まで全部を回す  ここ8年ほどは、自社製品開発も担当  Windowsアプリ開発のネタが多い  勉強会もやってます。  https://sciencepark.connpass.com

• https://sciencepark.connpass.com/

概要  C++はとても多様な書き方ができる言語  メモリを確保すれば、型もスコープも無視して効率よく使う事が出来る  というより、そういう用途でこそ真価を発揮する  しかし・・・  普通のビジネスロジックをC++で書く場合、むしろその自由度は邪魔  その場合、自由度を減らして安全に書く方法を使おう   （そういう部分はC#で書こう、が出来る案件ならその方が良いが・・・） 要素1つずつで勉強会が出来るようなものも多いので、今回は理解するための キーワードとその役割を説明するところまで

話のポイント  メモリ：「メモリ等リソース解放漏れ」「バッファオーバーラン」を避ける技  Win32API：Windowsにおいては、C++そのものより「Win32APIとの組み合わせ 方」がポイント  特に、可変のメモリを引数にとるタイプ  例外：例外のメリットを得る  （上級おまけ） STL：Linqの代わりにSTLが使える

メモリ：スコープでのリソース解放  スコープの外で使う必要が無いものは、スコープで解放されるように書く  うっかり解放漏れを避けられるのも重要だが、何より「例外で抜けても解放さ れる」というメリットを得られる  主なテクニック  ハンドル解放  コンテナ  スマートポインタ

メモリ：ハンドル解放


ちょっとしたテクニックだが、知っているといないとでは効率が大違い



std::unique_ptrはテンプレートなので、HANDLE等のWin32APIの定義を追加す
ることが出来る



例：CloseHandleを自動で行う



次のように1回だけ定義

struct HandleDeleter {
void operator ()(const HANDLE handle) const
{
if (handle != INVALID_HANDLE_VALUE) CloseHandle(handle);
}};
typedef std::unique_ptr<std::remove_pointer_t<HANDLE>, HandleDeleter> unique_HandleDeleter;


使い方↓

auto hFile = CreateFileW(略);
unique_HandleDeleter phFile(hFile);

メモリ：コンテナ  ヒープメモリを自動で確保し、自分のデストラクタでメモリを解放してくれる ものの総称  とにかく、std::vectorを使えるようになろう  BYTE*でできて、std::vectorで出来ないことは、何も無い  後のページのWin32APIとの組み合わせで、いくつか例示する std::vector<BYTE> buf; buf.push_back(3); BYTE* pBuf = buf.data(); //ここまでで実質的に次のコードと同じで、解放も自動 //auto* pBuf = new BYTE[1]; //pBuf[0] = 3;

メモリ：最低限のstd::vector  さすがに、適当に使いすぎると効率が悪い  push_back , assign, reserveあたりは知っておくべき  ポイント：「確保しているメモリのサイズ」と、現在のsize()は異なる size()が確保メモリサイズを超えると、再確保するので遅い  push_back：size()の範囲の末尾にデータ追加、size()を増やす  assign：指定範囲にデータをコピー、それをsize()にする  reserve：指定サイズメモリを確保させる。size()は変えない →その範囲でのpush_backはメモリ確保をしないので速い reserve()したメモリ 現在のsize() push_back() assign()

メモリ：スマートポインタ  スコープを抜けた時に、newしたポインタを解放させたい場合に使う  ローカル変数宣言でスタックメモリに置く場合は不要  しかしヒープメモリに確保する場合はこれが必須  newしたらstd::unique_ptr型のローカル変数に渡せ。これだけ。 const std::unique_ptr<SampleClass> pSampleClass(new SampleClass); pSampleClass->MemberFunc();

メモリ：キャスト  かっこで囲むタイプのキャストは使わない（C-Style Castとして旧型扱い）   (int)val 原則としてstatic_castを使う。間違えていたらコンパイラが教えてくれる  static_cast<int>(val)  reinterpret_castはほとんど使わない。  必要に見える場合の大半はキャストミス  通常、BYTE*バッファを構造体にキャストする場合くらいにしか使わないはず  「他にも使うケースがあるぞ」と言えるくらい詳しい人は自由にどうぞ

Win32API：データバッファのタイプ  BYTE*などを引数に渡すタイプのAPI  ローカル変数（スタックメモリ）で足りずヒープメモリを使う場合  new byte[]ではなく、vectorを使えば良い void SampleBufAPI(BYTE* pBuf, int bufSize); std::vector<BYTE> buf(128, 0); SampleBufAPI(buf.data(), static_cast<int>(buf.size()));

Win32API：文字列バッファのタイプ


wchar_tの配列を渡すと、そこに値を返すタイプのAPI



ローカル変数（スタックメモリ）で足りずヒープメモリを使う場合



vectorからwstringへの余計なコピーが発生するが、下のようにすれば解放漏れ
は無い



コピーを避けるのなら、C++17以降でbasic_string::data()を直接使えば良い


VC++前提なら、atlstr.hのCStringWでも良い

void SampleStrAPI(wchar_t* pBuf, int bufSizeCch);
std::vector<wchar_t> buf(MAX_PATH, L'\0');
SampleStrAPI(buf.data(), static_cast<int>(buf.size()));
std::wstring outputStr(buf.begin(), buf.end());

Win32API：ヘッダと可変データのタイプ  可変サイズバッファを作成し、そのヘッダ部に情報を書いてポインタを渡す、というタイプ  架空のAPIで例を示す。下記の定義で、例は次のページ struct SampleHeader { int BufferSize; BYTE Data[]; }; void SampleAPI(const SampleHeader* pBuf);

Win32API：ヘッダと可変データのタイプ


ポイントは、バッファに対するindexではなく、「buf.end()」というイテレータを基準に書き込んで
いること（index管理ミスがあり得ない）



これなら、解放漏れやオーバーランは起き得ない（キャストをミスらない限り）

BYTE inputData[3];//何らかの入力データがここに入っているイメージで読むこと
std::vector<BYTE> buf;
//必要なメモリサイズを計算して確保（処理速度向上のためで、必須ではない）
buf.reserve(sizeof(SampleHeader) + sizeof(inputData));
//ヘッダ部分を追加（0埋めで）
buf.resize(sizeof(SampleHeader), 0);
//データ部分を追加（すでに用意したデータをコピー）
buf.insert(buf.end(), &inputData[0], &inputData[3]);
//ヘッダ部分のポインタを取得し、ヘッダの構造体にキャストして値を書き込み
const auto pHeader = reinterpret_cast<SampleHeader*>(buf.data());
pHeader->BufferSize = static_cast<int>(buf.size());
//ヘッダ部分のポインタをAPIに渡す（bufが消えたり変更されない限りは安全）
SampleAPI(pHeader);

例外：例外のメリットを得る  例外のメリットは、めっちゃ大まかに言えば次の点  戻り値チェックがない分、コードがすっきりする（特に関数の階層が深い場合）    「エラーコード」以上のエラー情報を返しやすい（メモリ確保、全メソッドの共通 定義などの考慮不要） デメリットは次の点   「基本的に、エラーが出たらそこで処理中断」という処理方針の場合に限る 発生時の処理が非常に遅い→正常系では使えない つまり、本セッションの対象である「効率よりも、安全で保守性が高いコー ド」が目的ならば積極的に使うべき

例外：メリットを得るための条件  メリットを得るためには、下記のようなルールを全体で守る必要がある    注意：これはC++の必須ルールでは無く、本セッションの目的のためのルール 1，例外は「原則としてcatchしないもの」と理解する（あえて極端に言った）  例外が発生した場合の後処理を行うメソッドだけが、例外をcatchする  例：コンソールアプリで「例外発生時は、アプリケーション終了コードを返してア プリを終了する」という場合、catchするのはmainメソッドだけ 2，例外の型は、全てstd::exceptionを継承する  こうすることで、最上位の関数でstd::exceptionをcatchすれば、必ず全ての例外を そこで止めることが出来る

（上級おまけ） STL：LINQの代わりに
STLが使える


list.FirstOrDefault(d => d.id == 3)みたいにシンプルに書けないのか？



書ける。ラムダ式も使えばほとんどLINQと同じ

std::vector<SampleIdClass> idList; //検索対象のリスト、実際にはデータが入っている
const auto result = std::ranges::find_if(idList,
[](const SampleIdClass& d) { return d.Id == 3; });
if(result != idList.end())
{
//対象が見つかった場合の処理
}

まとめ  C++にも、安全優先の書き方ができる（速度は落ちるが）  「スコープを抜けたら解放されるように書く」が最大のポイント  C++はC#と比べて厳密な定義を要求する傾向にあり、コードは複雑だが・・・  同じ複雑なコードでも、解放漏れとバッファオーバーランを避けられるのは大 きい  覚えて積極的に使っていこう  ただ、そういう場合はたいてい、C#を使った方がより良い（台無し）