constな変数の初期化とラムダ

この前、少し初期化が面倒な数値のリストを作らなければならなくなった。しかも結構急いでいた。

適当な例として以下のようなものを考える。

const std::vector<std::size_t> indices{1,4,7,10,13, ... 298}; //流石に手では書けない

こんなもの、for文を使えばいいのでは？

std::vector<std::size_t> indices;
for(std::size_t i=0; i<100; ++i)
    indices.push_back(i*3+1);

上のコードは完璧ではない(ex. reserveするべきだ)が、とりあえず動きはする。

しかしその後少し面倒なことをするので、できれば私はこれをconstにしたかった。不注意で書き換えてしまうのが怖かった。

外部でCSVを作って、

const std::vector<std::size_t> indices{
#include "indices.csv"
};

とするのも一瞬考えたが、流石に却下した。

例えばBoost Iteratorを使えば、これは普通にIteratorを2つ渡してその範囲を使って初期化するコンストラクタが使える。

const auto f = [](std::size_t i){return i*3+1;};
const std::vector<std::size_t> indices(
    boost::make_transform_iterator(
        boost::make_counting_iterator<std::size_t>(1), f),
    boost::make_transform_iterator(
        boost::make_counting_iterator<std::size_t>(100), f)
    );

だが長い。正しいやり方だが、その時私は本当に急いでいたので（実際、マクロ定義をして一部のコードを生成した程だ）、これはちょっと許容できなかった。

そして、関数の返却値としてならconstで受けられる、と思ったあと、一瞬関数を作ろうとして、すぐに一時的なその場で使える関数の存在を思い出した。

lambdaだ。

const std::vector<std::size_t> indices = [](){ // ラムダ定義開始
    std::vector<std::size_t> v;
    for(std::size_t i=0; i<100; ++i)
        v.push_back(i*3+1);
    return v;
}(); // lambda定義を終了し "}"、即座に呼び出す "()"。
// その場でラムダの中身が実行され、値が返る。それが`indices`になる。

その場でlambdaを作って、その中で必要なものを生成し、その場でconstなものに代入した。

今までstd::algorithmとの組み合わせとか、関数を渡すというような状況でばかり使ってきたが、lambdaにはこんな使い方もある。綺麗な書き方かどうかはおいておいて。

現代のC++

C++ ポエム

C++17での機能追加について、ネット上では「項目一覧見ただけで読む気失せる」「入門不可能」「闇」「誰も使いこなせない」「絶対に使いたくない」などと盛り上がっている。

だが私は一概にはC++はどんどん初心者を見捨てているとは言えないと思っている。C++は規格のアップデートの度に、その場しのぎだったり一貫性を欠いたりするルールを廃し(vector<vector<int> >の空白や、template template parameterにtypenameを許可など)、より意図が明快で細かいことを考えなくていい文法が追加され(型推論、構造化束縛、range-based forなど)、古式ゆかしい形式よりも安全で使いやすいライブラリ(optional、string_viewなど)が追加されてきた。たまにC++98を使うとよくわかるが、最新のC++はかなりユーザーに優しい。

つまりどちらかというとC++はアップデートの度にユーザーの方に寄ってきているのだ。ユーザーが欲していた機能を追加し、ユーザーの評判が悪かった機能を捨てて。捨てることになったものを中々本当には切り離さないので（トライグラフは誰が使っていたのだろう）外から見ていると肥大化しているように見えるが、使っている側としてはどんどん便利になってきていると感じている。むしろ、単に使うだけの静的スクリプト言語という用途にすらなり得ると思っている。インタプリタないけど（CLing使ったことなし）。

続きを読む

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

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;

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