バイナリファイルの取り扱い

C++

データの保存のために、バイナリフォーマットは広く使われている。なのでそれを読まなければならないケースが多い。

C++におけるバイナリの読み方の一番の基本はstreamの関数std::basic_istream::read(char_type*, streamsize)だろう。 この関数は第二引数で示された文字数だけ読み込み、第一引数で示された位置へその内容を書き込む。 使い方は以下だ。

std::ifstream ifs("example.bin", std::ios::in | std::ios::binary);
std::int32_t i;
ifs.read(reinterpret_cast<char*>(std::addressof(i)),
         sizeof(std::int32_t)/* or simply 4 */);

なので、基本的に以下のような関数を用意することで、ストリームから簡単にバイナリ値を読み込むことができる。

template<typename T>
T read_binary_as(std::istream& is)
{
    T val;
    is.read(reinterpret_cast<char*>(std::addressof(val)),
            sizeof(T));
    return val;
}

const auto i = read_binary_as<std::int32_t>(ifs);

書き出しの時は同様にbasic_ostream::write(const char_type*, streamsize);が使える。

std::ofstream ofs("example.bin", std::ios::out | std::ios::binary);
const std::int32_t i = 42;
ofs.write(reinterpret_cast<const char*>(std::addressof(i)),
          sizeof(std::int32_t))

ラッパーを書くとすれば

template<typename T>
std::ostream& write_as_binary(std::ostream& os, const T& v)
{
    is.write(reinterpret_cast<const char*>(std::addressof(val)),
             sizeof(T));
    return val;
}

という感じだろうか。

続きを読む

変数への参照と「変数そのもの」

Python

Pythonは最近非常に流行っているので、静的型付け言語が好きな私も無視できないどころか使って便利だと感じることもある。 特に大抵のライブラリがPython APIを提供しているので、ライブラリを組み合わせて何かを組み上げる時は向いているだろう。

そんな感じの認識なので、私はPythonでまとまったコードを書いたことはなく、せいぜいで数百行、関数数個にユーザー定義オブジェクトもあって数個、で事足りるような程度の小物しか書いてこなかった。 なので、私のPythonの知識は入門を終えたところ、という感じだ。そこにC++等他言語の知識・経験を持ってきて必要に応じてやっていっている。

ところで、先ほど以下のようなツイートを見た。

それを見て試して（実際にツイートのようになった）、そのあまりの非直感的な挙動に少し驚いたあと、以前同じくTwitter経由で発見した以下の質問を思い出した。

ja.stackoverflow.com

このそれぞれの予想外の動作は、似た理由に根ざしているのではと思ったのだ。つまり、オブジェクトが基本的に参照で取り回されるという特徴である（後者にはスコープの問題も絡むが）。 何が起きているか説明するために、上記リンク先からコードをいくつか引用しよう。

続きを読む

読んできたプログラミング本

日記

割と今まで読んできた本を聞かれることが多いので、ちょっと思い出そうとしてみる。記憶から漏れているものもあるかもしれないので思い出したら足すかも知れない。

私はC++の前にCを少しだけやっていたので、記憶はそこから始まる。

続きを読む

暗黙の型変換の落とし穴

C++

こんなツイートを見た。

答えはboolだ。その理由は、こういう一見自明なクイズは大抵一番正しそうに見える解答が誤答だから、ではなく、暗黙の型変換の優先準位によるものだ。

まず、"Hello!"の型はstd::stringではない。これは文字列リテラルなので、その型はconst char[]だ。上記のコードにおいては、これがまず先頭を指すポインタ(const char*)へ変換され、ポインタがboolへ変換される。std::stringは標準ライブラリといえどユーザー定義型であることは間違いないので、built-inな型のほうが選択され、これはboolになる。

いや、確かに、この挙動はクソだ。100人に聞いたら100人が、これはstd::stringになるべきだと答えるだろう。私もそう思う。この挙動はライブラリがどうにかできるものでもないし、ユーザー定義型への変換を優先する方が問題が生じる場合もありそうで、仕方ないと言えば仕方ない気もするが……。

挙動が直感的でないのに対して、解決策は単純だ。文字列リテラルからstd::stringへの暗黙の型変換に頼らず、型を明示すればよい。つまり、std::string_literals::operator""sを使えばよい。

using std::string_literals::operator""s;
std::variant<std::string, int, bool> v = "Hello!"s;

これなら型はstd::stringになる。

以前、あるプロジェクトが使っているクラスがboolへの型変換関数を持っていることを知らず、そのクラスがboolへ変換された後にintに変換されることでオーバーロードが謎の方向に解決されるという事案が発生して死んでいたことがある。今回の件ではそれを思い出した。

emptyとsize==0

C++

コンテナが空（要素を持っていない）かどうかを確認するとき、タイトルの2つのメソッドのどちらを使うかという話題で界隈が盛り上がっていたようだ。

私はempty()一択だ。サイズが0かどうかを確認したいなら、size() == 0を使うべきだ。だが、コンテナが空であることを確認できるメソッドがある場合に、コンテナが空であるかを確認するために別のコードを書く理由がない。 その2つが異なる場合があるのか、というのは疑わしい。ただ、未初期化領域を区別できるようなコンテナを作って、過去のSTLの命名を全て無視して関数を命名したなら、場合によっては筋が通った形でemptyかつsize != 0という結果になることはありえるだろう。sizeはnon-zeroだが、確保してある全領域が未初期化のままなのでempty、というように。

C++では実際には、リストのようにsizeを取得するコストが定数でない可能性のあるデータ構造を考えてemptyが作られたのだろうと思われるが、list::sizeが定数時間とされてからはこの点に関してはどうでもよくなった。

問題があるとすれば、emptyの命名だろうか。C++界隈では人々は長年STLに親しんでいるのでこの名前の関数がどう機能するかについて合意しあっているが、そうでない人がこれを見た時にどう反応するかはわからない。 もしこれが、is_emptyやempty?のような命名であれば、オブジェクトの状態を取得し、boolを返すというところまで含意できたのだが。

というわけで以下のようにしよう。

#define is .
std::vector<int> vec;
std::cout << std::boolalpha << vec is empty() << std::endl;

言うまでもないがこのコードは冗談だ。

大掴みBoost.PolyCollection

C++

この間、Boost 1.65がリリースされた。リリースノートをざっと見た所、新規ライブラリがいくつか入っている。そのPolyCollectionなるものが気になったのでざっと見てみることにした。これはその覚え書きである。

PolyCollectionは、多相型向けのコンテナだ。基底クラスを指定してその派生クラスを格納したり、anyによってDuckTypingしたり、std::functionに関数ポインタや関数オブジェクトを放り込んだりする際にいちいち生じるヒープアロケーション、それによるキャッシュヒット率の低下と、仮想関数呼び出し時の分岐予測の失敗を解決する。

続きを読む

座標ベクトルと汎化について

C++ ポエム

私の書くプログラムでは、趣味でも仕事でも、低次元（大抵は2か3次元）でのベクトルを扱うことが多い。そうなると普通は座標ベクトルを意味する構造体を作って管理するだろう。

続きを読む