2015-05-28

コマンド間違えると「コマンドではない。」って返してくれる江添プラギン

bashの場合、.bashrcに以下のように書けばよい。

command_not_found_handle()
{
    echo "コマンドではない。"
}

ちなみに、もともとのシェル関数をリネームする方法について興味深い方法があった。

bashrc - How do I teach bash in Ubuntu some curse words? - Ask Ubuntu

How do I rename a bash function? - Stack Overflow

これを元にUbuntuに提供されている便利な機能も維持すると、以下のように書ける。


alias_function() {
  eval "${1}() $(declare -f ${2} | sed 1d)"
}

alias_function orig_command_not_found_handle command_not_found_handle 

command_not_found_handle() {
  command=$1
  shift
  args=( "$@" )


  echo "コマンドではない。" 
  orig_command_not_found_handle "$command" "${args[@]}"
}

2015-05-27

C++標準化委員会の文書 2015-04 Pre-Lenexaのレビュー: N4400-N4409

N4400: Concurrency TS Editor's Report, April 2015

N4399 Concurrency TSドラフトの編集者による変更点の記述

N4401: Defaulted comparison operator semantics should be uniform

現在、特別なメンバー関数としてデフォルトの比較演算子を生成する機能を追加しようという提案が出ているが、その提案では、ポインターとmutableな型のデータメンバーに対してはデフォルトの比較演算子を生成しないとしている。その理由は、ほとんどの場合でユーザーの意図しない結果となるだろうからとのことだ。

この論文は、ポインターの比較方法はすでに厳密に定義されていてプログラマーも了解しているし、既存の特別なメンバー関数であるコピーコンストラクターは、ポインターだろうがmutableだろうがお構いなしにそのままコピーすることを引き合いに出し、これ以上特別なルールを付け加えることは無用の混乱を招くだけであるし、結果が利用者の意図した通りでないのは利用者の責任であるとして、その方針に反対している。

N4404: Extension to aggregate initialization

C++11のアグリゲート初期化は便利だ。


struct user
{
    uint32_t id ;
    std::string name ;
} ;

user u{ 10, "Alice" } ;

しかし、アグリゲート初期化は、基本クラスを持つ型には使えない。

struct common { } ;

struct user : common
{
    uint32_t id ;
    std::string name ;
} ;

user u{ 10, "Alice" } ;

この場合、従来通りコンストラクターを手で書かなければならない。

struct user : common
{
    uint32_t id ;
    std::string name ;

    user( uint32_t id, std::string name )
        : id(id), name(name) { }
} ;

user u{ 10, "Alice" } ;

これは明らかに面倒だから、基本クラスがdefault constructibleな場合ならば、アグリゲート初期化を使えるようにしようという提案。

N4405: Type of the accumulaters of standard algorithms std::accumulate and std::inner_product

ロシア人によって書かれたためか英語が少し拙い。

標準規格では、std::accumulateとstd::inner_productの内部の作業中の変数の型が明記されていない。これにより、実装に差が生じ、同じコードが実装によって通ったり通らなかったりする。

例えば、std::accumulateが以下のような実装になっている場合、


template <class InputIterator, class T>
T accumulate( InputIterator first, InputIterator last, T init )
{
 T acc = init; // 作業用の変数

 for ( ; first != last; ++first ) acc = acc + *first;

 return acc;
}

以下のようなコードは通らない

std::accumulate<decltype( std::begin( a ) ), const int>( std::begin( a ), std::end( a ), 0 ) ;

しかし、もし実装が、

auto acc = init ; // 作業用の変数

のようになっている場合、このコードは通る。

また、利用者は値のコピーを防ぐために、リファレンスを明示的に使うかもしれない。

long long aac = 0 ;
std::accumulate< decltype( begin(a) ), long long & >( begin(a), end(a), acc ) ;

これも、実装によっては通ったり通らなかったりする。

実装の差異を防ぐために、内部の変数の型について、規格で規定しなければならない。

提案では、内部の変数の型は、あたかもT accのように宣言され、初期値で初期化される。Tにはリファレンス型もありえるという文面を提案している。

N4406: Integrating Executors with Parallel Algorithm Execution

Parallelism TSとして、並列実行版アルゴリズムが提案されている。この提案は、並列実行が「どのように」行われるかを支持することはできるが、「どこで」行われるかを支持することはできない。

並列実行の方法には様々なものがあり、その方法を、実行媒体(execution agent)と呼ぶ。OSの提供するネイティブのスレッドもあれば、ファイバーのような協調的マルチタスクを用いた軽量スレッドもある。他にも、SIMDやGPGPUのような実行媒体もある。この提案は、具体的な実行媒体を扱うexecutorをParallelism TSに導入する提案をしている。

executorは共通のAPIを持つ。executorはどのような実行方式なのかを指し示す実行カテゴリーを持つ。executorは実行媒体を大量に確保するために、単一の呼び出しで多数の実行媒体を確保する方法を提供する。標準で提供されることが保証されている標準executorを用意する。実行を簡単に行える方法を提供する。

実行カテゴリーとして提案されているのは、シーケンシャル実行、並列実行、ベクトル実行。

標準executorとしては、シーケンシャルexecutorと並列executorとベクトルexecutor。また呼び出し元のスレッドで実行される版の並列/ベクトルexecutorもある。

N4407: Technical Specification for C++ Extensions for Parallelism, Working Draft

Parallelism TSのドラフト

並列実行版のアルゴリズムライブラリ

N4408: Parallelism TS Editor's Report

Parallelism TSドラフトの編集者による変更点の記録。今回はレイアウトの調整程度らしい。

N4409: Programming Languages -- Technical Specification for C++ Extensions for Parallelism

内容はN4408とほぼ同じ。

ドワンゴ広告

特に書くことがないが、今日はボドゲをせずに溜まったC++標準化委員会の文書を片付けている。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

Ubuntu 15.04の感想

Ubuntu 15.04がリリースされた。最近はすっかりなれてしまったので新鮮味がなく、特に書くこともなくなっていたが、とりあえず感想を書いてみる。

GCCのバージョンは4.9.2、Clangのバージョンは3.6。

最も個人的に結果がわかりやすいパッケージのバージョンアップは、gnubg(GNUバックギャモン)である。バージョンが1.04になり、起動直後にmutex関連のエラーを出して即座に終了する不具合が修正された。

ところで、iBusがクソすぎるので、そろそろiBusに見切りをつけようと、Fcitxを使ってみた。基本的に悪くないのだが、GVimで返還中の文字列が表示されないという問題がある。vim -gfで起動することで回避できるのだが、ターミナルエミュレーターのウインドウを無駄にひとつ多く表示する必要があって汚い。真剣に文章を書くにはGVimを使っているので、これは無視しがたい問題だ。

その他の不具合としては、System Settingsのダイアログがなぜか透明になっているという問題がある。しかも、ディスプレイの設定が全く動かない。

幸い、xrandrは動くので、ディスプレイの設定を変えたいときは、それで設定している。

2015-05-26

贈り物

私宛に、面白いものが送られてきた。

キリングバイツの一巻が贈られてきた。興味深いが自分で買う程でもないのでウィッシュリストに放り込んでおいたマンガだ。

冷凍のスライスベーコンの塊が贈られてきた。とりあえず冷凍庫に入れたが、かなりの量がある上、小分けにされていないので、解凍したら最後、速やかに調理して食べなければならない。6月6日のボドゲ会に使うとしよう。

そういえば、だいぶ前に贈られてきたラテン語入門の本は、だいぶ前に読み終わったが、感想を書くのを忘れていた。ローマの歴史小話も出てくる興味深い入門書だった。

本の内容は、格変化などの基本的な文法の解説だった。読み終えたはいいものの、到底覚えきれるものではない。やはり、ここは例文と辞書を用意して、しばらくラテン語に浸からなければ読めない。

Old New Thing: 超最新の実験的C++機能、オタマジャクシ演算子

New C++ experimental feature: The tadpole operators - The Old New Thing - Site Home - MSDN Blogs

僕はよくこういうコードを書いている。

x = (y + 1) % 10;
x = (y + 1) * (z - 1);
x = (double)(f(y) + 1);

+と-の演算子は優先順位が極めて低いために、その周りに括弧を多用しなければならず、とても読みにくい深くネストされたコードができあがってしまう。

Visual Studio 2015 RCには、実験的な演算子が2つ追加されている。その名もオタマジャクシ演算子。これは整数値から括弧を必要とすることなく1を加算、減算できる演算子である。

x = -~y % 10;
x = -~y * ~-z;
x = (double)-~f(y);

オタマジャクシ演算子と名付けられた理由は、オタマジャクシが値に向けて泳ぐ姿と、値から遠ざかって泳ぐ姿に似ているためである。チルダがオタマジャクシの頭で、ハイフンが尻尾だ。

文法 意味 説明
-~y y + 1 オタマジャクシが値に向かって泳ぐと大きくなる
~-y y - 1 オタマジャクシが値から遠ざかって泳ぐと小さくなる

この実験的オタマジャクシ演算子を有効にするには、C++ファイルの上部に以下のような行を追加しなければならない。

#define __ENABLE_EXPERIMENTAL_TADPOLE_OPERATORS

例えば、以下はオタマジャクシ演算子を使ったコードの例である。

#define __ENABLE_EXPERIMENTAL_TADPOLE_OPERATORS 
#include <ios>
#include <iostream>
#include <istream>
 
int __cdecl main(int, char**)
{
   int n = 3;
   std::cout << "3 + 1 = " << -~n << std::endl;
   std::cout << "(3 - 1) * (3 + 1) " << ~-n * -~n << std::endl;
   return 0;
}

この演算子はまだ実験的機能であることに注意すること。公式なC++の一部ではない。しかし、使ってみて感想を教えてくれ。

ちなみに、このオタマジャクシ演算子はx86とx86-64向けのGCCもClangもすでに実装済みであり、Borland 5.5やMSVC6.0といった超古代のコンパイラーすら対応している。

ドワンゴ広告

整数を2の補数で表現する場合、

\[-y = \sim{y} + 1\] \[ \sim{y} = -y -1 \]

つまり、

\[-\sim{y} = -(-y - 1) = y + 1\] \[\sim{-y} = \sim\sim{y} - 1 = y - 1\]

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-25

2015-04 pre-Lenexaのレビュー: N4390-N4399

N4390: Minimal incomplete type support for standard containers, revision 3

std::vector, std::list, std::forward_listの要素型に不完全型を認める提案。

これにより、以下のようなコードが書けるようになる。

struct Node
{
    // この時点で、Nodeはまだ不完全型
    std::vector<Node> nodes ;
} ; // Nodeはここから完全形

N4391: make_array, revision 4

std::arrayを返すstd::make_arrayの提案。文字列リテラルからそれぞれの文字のarrayを作るto_arrayも提案されている。

// std::array< int, 4 >
auto a = std::make_array( 1, 2, 3, 4 ) ;

// std::common_typeにより型が決定される
// std::array< long, 2 >
auto b = std::make_array( 2, 3L ) ;

// エラー、narrowing
auto c = std::make_array( 2, 3U ) ;

// OK、明示的な型指定
auto d = std::make_array<long>( 2, 3U ) ; 

// エラー、narrowing
auto e = std::make_array<unsigned>( 2, 3U ) ;

// std::array< const char *, 1 >
auto f = std::make_array( "foo" ) ;

// std::array< char, 4 >
auto g = std::to_array( "foo" ) ;

[PDF注意] N4392: C++ Latches and Barriers

標準ライブラリにラッチとバリアーの提案。

latchとは、初期化時にカウンター値を設定する。各スレッドはカウンターをアトミックに減少させることができる。カウンターが0になるとready状態になり、latchに対してwaitをしていたスレッドのブロックが解かれる。



std::experimantal::latch l( 10 ) ;

void f()
{
    l.count_down_and_wait( ) ;
}

barrierとは、繰り返し使えるlatchだ。

flex_barrierとは、ready状態になった時に呼び出す関数オブジェクトを設定できるbarrierだ。

[PDF注意] N4393: Noop Constructors and Destructors

何もしないno-opコンストラクターとデストラクターを追加する提案。

本当に何もしないコンストラクターとデストラクターが欲しい。バイト列を操作して、それをそのままクラスのオブジェクトとして扱うような場合だ。用途としてはdestructive moveや、オブジェクトの内部表現のバイト列をディスクに読み書きしたりする場合だ。

提案では、文法例はさまざまある。仮に提案されている文法は、何らかのキーワード(バイク小屋議論を避けるために仮に__COOKIE__とする)をコンストラクターとデストラクターに渡すものだ。

struct X { ... } ;

void f()
{
    alignas(X) char buf[sizeof(X)] ;
    auto p = new(buf) X( __COOKIE__ ) ; // no-op constructor

    p->~X( __COOKIE__ ) ; // no-op destructor
}

no-opは本当に何もしない。バイト列がクラスの表現として正しいかどうかはプログラマーが責任を持つ。

ポリモーフィックな型はno-opコンストラクターを使えない。(vtableなどの実装が操作する隠しバイト列があるため)

自動ストレージ上に確保されたオブジェクトに対してno-opデストラクターを呼び出しても、依然として自動的にデストラクターは呼び出される。

struct X { ... }  ;
void f()
{
    X x ;
    x->~X( __COOKIE__ ) ; // no-op デストラクター
    // デストラクターは呼び出される。
}

どうも、reinterpret_castとあまり変わらない気がする。

論文では、将来的な拡張案として、ポリモーフィック型に対応したり(vtableなどの隠しバイト列だけを初期化する)、自動的なデストラクター呼び出しを抑制するなどの案をあげているが、これは今の提案の骨子ではないとして今回は提案しないとしている。

N4394: PL22.16/WG21 draft agenda: 4-9 May 2015, Lenexa KS/US

Lenexa会議の日程。

[PDF注意] N4395: SIMD Types: ABI Considerations

SIMDベクトル型を標準に追加する場合のABIに対する考察。

単一アーキテクチャーの中の複数のマイクロアーキテクチャーにどうやって対応したらいいのか。例えば、x86-64は、SSE, AVX, AVX2という複数のSIMDベクトル演算のマイクロアーキテクチャーが存在する。それぞれ最も効率の良いABIが異なる。異なる翻訳単位をまたぐと、ABIが一致しない。さてどうするのか。

論文では、ポリシーベースの実装が最も良いとしている。しかし、それは実装依存のアーキテクチャーを規格に盛り込まなければならないような気がする。

[PDF注意] N4396: National Body Comments: PDTS 19841, Transactional Memory

Transactional Memoryに対するNBコメント。

N4397: A low-level API for stackful coroutines

スタックフルコルーチンや協調型マルチタスクを実装するための低級APIの提案。Boot.Contextベースを参考に設計されている。

stacklessとstackfulの違いや仕組みの解説が初歩的なところからよく書かれているので興味深い。

[PDF注意] N4398: A unified syntax for stackless and stackful coroutines

stacklessコルーチンとstackfulコルーチンの文法を統一しようという提案。

概要

本論文はstacklessとstackfulコルーチンの統一文法を提案する。文法はN4397を元にしている。

主要な機能は、

  • 変数やコンテナーに格納できる第一級オブジェクト
  • resumableキーワードを用いたlambda風の式の導入
  • 実行のシンメトリックな(訳注:呼び出し元以外の任意の実行媒体に実行を渡せる)転送。アシンメトリックな転送よりも高級な実行制御が可能になる。
  • 通常の関数の呼び出しとreturnは影響を受けない。

stacklessとstackfulの統合というのは、

関数をみて、

コンテキストスイッチが発生していなければ、通常の関数。

トップレベルでコンテキストスイッチが発生していれば、stackless コンテキスト

その他の場合、stackfulコンテキスト

だそうだ。

N4397のstd::execution_contextとほぼ同じ設計になっているが、lambda風式がhint属性を取らず、stacklessかstackfulかは、コンパイラーが判断するようになっている。

N4399: Technical Specification for C++ Extensions for Concurrency, Working Draft

Concurrency TSのドラフト

futureの改良

futureがready状態になったときに実行される関数オブジェクトを指定できるthenや、複数のfutureがすべてready状態になった時に実行される関数オブジェクトを指定できるwhen_all, 逆に、ひとつでもready状態になった時のwhen_any。最初からready状態になっているfutureを作るmake_ready_future。最初から例外状態になっているfutureを作るmake_exceptional_future。

latchとbarrierライブラリ

初期化時にカウンター値を指定して、アトミックにデクリメントし、カウンター0になるまで実行をブロックできる使い捨てのlatch。再利用ができるbarrier。カウンターが0になった時に実行される関数オブジェクトを指定できるflex_barrier。

atomicなshared_ptr

atomicに操作できるatomic_shared_ptrとatomic_weak_ptr

ドワンゴ広告

C++標準化委員会の論文がたまっている。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-23

江添ボドゲ会@6月開催

江添ボドゲ会@6月 - connpass

6月の第一土曜日である6月6日に妖怪ハウスで江添ボドゲ会を開催する。

最近、引越して自らシェアハウスを始めることを考えている。ボドゲ会を開催するために広いリビングのある物件を探している。

Unixの歴史のgitレポジトリ

dspinellis/unix-history-repo

現在入手しうる限りの情報を使って、Unixの歴史を再現したgitレポジトリを作成する試みが行われている。

1972年から2015年までの入手可能な断続的なスナップショット、レポジトリ、研究記録を元に、単一の歴史を辿れるgitレポジトリを作り上げるというプロジェクトだ。

スナップショットからはソースコードと日付を、研究記録からは貢献者とブランチを、レポジトリからはすべての情報を得て、単一の歴史というメタデータを辿れるgitレポジトリを生成する。これはUnixの歴史研究のために非常に便利だ。

ちなみに、case-insensitiveなファイルシステム上に展開するとファイルの欠落を生じるそうだ。

2015-05-21

xkcd 1526: プラシボ阻害薬

xkcd: Placebo Blocker

プラシボ効果の作用原理についての研究が進んでいる。

その研究の成果を用いて、新薬を作成した。プラシボ効果阻害薬。

さて、臨床試験を行わなければならない。2つの被験者群を用意して、両方にプラシボを与え、しかる後に、片方には本物のプラシボ阻害薬を与える。そしてもう片方には・・・

・・まてよ

頭痛が痛くなってきた。

同じく。

この偽薬でも飲むかい?

2015-05-20

ask.fmの回答を簡単にするブラウザー拡張を書いた

Big Sky :: 江添さんに簡単に質問出来るコマンドを golang で書いた。

珍しくフルチンではないmattnさんが、ask.fmの私のアカウントに質問を投稿するCLIのツールをgoで書いたようだ。そのためと、しばらく回答していなかったため、ask.fmが大量のオヤジギャグを含む質問で埋まってしまった。

ask.fmをブラウザーから閲覧して質問に答えるのはいいが、UIに不満がある。マウスを使わなければ質問に答えられない。このため、キーボードだけで質問に答えられるよう、ブラウザー拡張を書いた。

https://github.com/EzoeRyou/askfm-mod

質問の一覧でショートカットキーを押すと、最新の質問の回答URLに移動する。回答を入力してショートカットキーを押すと、回答ボタンをクリックする。何も回答を入力しないままショートカットキーを押すと、「質問ではない」と回答する。

本来なら、こういうブラウザー拡張はもっと早く書くべきだったのだが、ダルいためなかなか作成に踏みきれずにいた。

ドワンゴ広告

久しぶりにChromiumの拡張を作ったら、manifest.jsonのフォーマットが微妙に変わっていた。こんなことより、早くC++の論文集を読まなければならないのだが。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-19

Linuxカーネルを2038年問題に対応させるには

System call conversion for year 2038 [LWN.net]

lwn.netでLinuxカーネルを2038年問題に対応させるにはという記事が公開されている。

32bit版Linuxカーネルのtime_tはsigned 32 bitなので、現行の32bit版Linuxカーネルをそのまま使い続けるシステムは、2038年問題の影響を受ける。

問題の日付が近づくにつれ、32bitシステムは様々な楽しげな理由により障害を起こすことが予測されるので、今日のLWN読者は、退職から呼び戻されて、紀南を救うために英雄的な活躍をするだろう。今対策をしなければの話だが。

さて、32bit Linuxカーネルでも、time_tなどの時間の表現に64bitの値を使えば2038年問題は解決できるか。実は、問題はそれほど単純ではない。

カーネル内部の時間表現を64bitに移行するだけではない。ユーザースペースのインターフェースも変えなければならない。いずれは移行しなければならないとしても、現行のバイナリとのABI互換はどうするのか。

このために、すべての時間を扱うシステムコールを、カーネル内部の64bit表現と、従来の32bit表現との変換を行う変換レイヤーとしてのシステムコールで置き換える。64bit時間表現のシステムコールには新しいシステムコール番号を割り当てる。もちろん、2038年までしか使えない。

最終的には、既存のバイナリは一掃される。

ところで、時間を扱うシステムコールと簡単に言うが、すべてを洗い出すのは難しい。ioctlには、現在何千も登録されているが、その一部は時間を扱っている。これをすべて洗い出して直していかねばならない。

ext4はタイムスタンプを32bitのtime_t型で格納している。ディスク上の表現として34bitに拡張しているバージョンのext4もあるが、ext3はそういう対応はしていない。ext3は使用を辞めなければならない。NFSv3も同様の問題があり、おそらく同じ道をたどるだろう。XFSは変更に問題を抱えている。ファイルシステムの問題は、64bitシステムにも影響を及ぼす。他にも、ユーザースペースとカーネルスペース両方で問題になる場面が多々あるだろうは疑う余地がない。そのため、2038年にシステムを対応させるのは、単にシステムコールを64bit値に移行する以上の問題がある。とはいえ、システムコールを直すのは、まず第一歩である。

2038年問題、一体どうなるのだろう。ファイルシステムのようなものは切り捨てるしかないのだろうか。NTPはどうするのだろう。GPSと同じようにするのだろうか。

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-18

歌舞伎座.tech #8 「C++初心者会」を開催した

歌舞伎座.tech#8「C++初心者会」 - connpass

5月17日に、歌舞伎座.thch #8 「C++初心者会」を開催した。

今回は、勉強会の初心者が発表できる場を設けようという意図から、発表枠には、初心者枠とガチ枠を設けた。これにより初心者が積極的に発表しやすくなるはずだ。さて、問題は参加者と発表者が集まるかどうかだ。いざフタを開けてみると閑古鳥が鳴いているようでは極めて痛い。

さて、connpassで告知と募集を開始すると、参加枠が即座に埋まっていく。どうやら勉強会の需要はあるようでまずは一安心だ。発表枠も埋まり始めたが、その参加者を見ると、どうも、技術的、勉強会的にみて、初心者とは思われない。

さて、公開直後の参加申し込みの波がひけてみると、参加枠と初心者枠は埋まっているものの、ガチ枠が埋まらない。どうやら、みなチョットデキル的な謙遜精神を発揮してしまったようだ。仕方がないので、ガチ枠をクソザコ枠に改名した。するとすぐに発表者で埋まった。しかし、発表者のプロフィールと発表タイトルをみると、どうもザコとも思われない。

さて、当日、

Eigenでオンライン機械学習アルゴリズムを実装したときの話

C++初心者ではあるのかもしれないが、機械学習の初心者ではない人間が発表した。C++に関係のある部分としては、行列計算ライブラリとして、Boost.UBLASは使い勝手が悪く、Eigenの方がパフォーマンスも使い勝手もよいとのことだ。

Seastar 高スループットなサーバアプリケーションの為の新しいフレームワーク

C++初心者ではあるのかもしれないが、カーネル開発の初心者ではない人間が発表した。Seastarとは、カーネルではなくユーザーランドでネットワークスタックを実装して高パフォーマンス化を図るものだ。ネットワークスタックをユーザーランドで実装する利点として、カーネルからユーザーへのメモリコピーが省けるとのことだ。

なるほど、これが必要になるのはどういう状況だろうか。100GbpsのNICが出たら話は変わるのかもしれないが。

Improving Linux networking performance [LWN.net]

Seastarの提供するfutureがthenをサポートしているのも興味深かった。これはC++標準化委員会にconcurrency TSとして提案されている機能だ。そういう意味で、この発表者には是非ともC++標準化委員会に出てきて知見を上げてほしいものだ。

Boost.Asioで可読性を求めるのは間違っているだろうか

果たしてC++初心者はBoost.Asioを使えるのだろうか。Boost.AsioはC++標準化委員会で、ネットワーキングライブラリとしてTSに提案されている。既存のネットワークライブラリで、標準化委員会で合意に達することができるものは、Asioぐらいしかないであろうが、日本の標準化委員会の中では、Asioは使いづらいという意見が出ている。

Boost.Spirit.QiとLLVM APIで遊ぼう

果たして初心者がExpression Templatesの悪用の最たる例であるBoost.Spiritと、LLVM APIを使うだろうか。ただし、便利なライブラリのおかげで、コード自体はとても短く綺麗だった。

任意の文をマングリングすることができないクソザコなのでconstexprラムダをライブラリで作った

lambda式のクロージャーオブジェクトのoperator ()がconstexprではないのは、もし仮にそうであると、lambda式がSFINAEの文脈で使えてしまうので、任意の文のsubstitutionに成功するかどうかを判定する、極めて強力な悪用ができてしまう。その機能を実現するためには、任意の文を型としてマングリングしなければならない。そのような機能は、抜け穴的な技法ではなく、コンセプトのような、その目的のために特別に設計された機能で実現すべきだ。

発表者は、Boost.LambdaのようにExpression Templatesを悪用して、コンパイル時に評価できるlambda式風のDSLをC++上に実装していた。これがザコのすることだろうか。

Haskellを書きたい人生だった

C++でExpression Templatesを悪用して、Haskell風のDSLを実装した話。ソースコードがまるでC++ではない上に、初心者のすることではない。

文字列とC++

これは初心者らしい発表だった。C++を学ぶときに引っかかった落とし穴をいくつか解説している。

ロボティクスとC++

Pythonを褒め称える発表だった。

私が市販のロボットのプログラミング環境に思うことは、バイナリブロブでの配布が多すぎるということだ。そのプログラミング環境は、10年後に維持できない。使い捨てである。そんな使い捨て文化では、一向にソフトウェア資産がたまらない。発表者は個別に差異を吸収するレイヤーライブラリを書いて、自分のコードはその上に書けばよいと主張したが、そういう互換レイヤーは、個人個人で独立して書かれるので、一向にソフトウェア資産がたまらず、ロボット開発の未来は暗い。

不自由ソフトウェアは長期的な利益をもたらさないので根本的に価値がない。

クソ雑魚がC++のウェブフレームワークを食い散らかした話

巷に転がっているC++で書かれたWebフレームワークをいくつか試してみたという発表。

ビルドするのが極めて困難なフレームワークが多いという話だった。ビルド可能性はとても重要で、まともなシステム管理者がドキュメントを読んで数行のコマンドを入力するだけでビルドできるようにしておくべきだ。

大学でC++03を教わった私が、便利そうだと思ったC++11の新機能

これも初心者らしい話。聞説、発表者の大学では、この2015年に大昔の化石規格であるC++03を教えて、それで学位を与えているようだ。日本の教育機関は10年ほど前からC++標準化委員会と関わらなくなっているため、もはや日本の教育機関に最新のC++規格をまともに把握している人間はいない。そのため、C++11を教育できる人間がいないのだろう。

この2015年にC++03しか教育できない教育者しかいない大学というのは何なのだろうか。しかも発表者によると、教育内容には規格上の誤りが多かったという。

Visual C++で始めるOpenCV

OpenCVという画像認識ライブラリの概要を説明する発表のようだった。

組み込み向けC++のやり方を探る

あまり内容を覚えていない。

なぜC++は組み込みに採用されにくいのか

C++はどのようなコードに落とし込まれるか人間が手動で推測しにくいので組み込みには向かないという発表であった。

virtual関数の実装方法として主流なvtableによるクラスオブジェクトのサイズ増加や、関数のオーバーロードをされるとその処理コストがコードを見ただけではわからないという話。

これは疑問で、Cでも実行時に決まる情報を元に分岐処理を行えば、vtable文のメモリ消費量増加はあるので同じだ。

関数のオーバーロードでコストを見積もれないというのも不思議だ。組み込みの分野では、何度も行う処理を関数という単位に分割しないのであろうか。

class Something { } ;
Something plus( Something const &, Something const & ) ;
Something operator + ( Something const &, Something constg & ) ;

のようなライブラリがあったとして、

Something c = plus( a, b ) ;

と書くのと、

Something c = a + b ;

と書くのとで、その処理コストを手動で見積もる難易度に差があるとは思われない。

発表者は、C++標準化委員会は組み込みでも使えるC++のサブセットを定義すべきであると主張したが、それはC++を分断するだけである。C++を分断すると、利用者も分断される。それは適切ではない。C++標準化委員会はC++のサブセットの定義は行わない方針である。

C++でHello worldを書いてみた

これは一見すると実に初心者らしい、微笑ましいタイトルだ。しかし、ホットペプシと名乗るこの発表者のプロフィールを確認すると、競技プログラマーであるという。発表者の最近解いた問題を少し見るだけでも、もはやこの発表者はHello worldやFizzBuzzを書いて正しく動いたことを確認して喜ぶレベルはとっくに過ぎ去っていることが明らかである。

以下がhello worldのC言語のコードである。

_[]={
'('-'!'|((','-' ')<<('$'-' '))|(('$'-' '|(('$'-' ')<<('$'-' ')))<<('('-' '))|(('$'-' '|(('#'-'!')<<('$'-' '))|((('/'-' ')<<('$'-' '))<<('('-' ')))<<('='-'-'))
,'('-' '|(('$'-' ')<<('$'-' '))|(('%'-' '|(('&'-' ')<<('$'-' ')))<<('('-' '))|((','-' '|(('&'-' ')<<('$'-' '))|((','-' '|(('&'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,'('-'!'|((','-' ')<<('$'-' '))|(('$'-' '|(('$'-' ')<<('$'-' ')))<<('('-' '))|(('$'-' '|(('#'-'!')<<('$'-' '))|(('$'-' '|(('/'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,'/'-' '|(('&'-' ')<<('$'-' '))|((','-' '|(('#'-'!')<<('$'-' ')))<<('('-' '))|((('#'-'!')<<('$'-' ')|(('('-'!'|(('('-'!')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,'('-'!'|((','-' ')<<('$'-' '))|(('$'-' '|(('$'-' ')<<('$'-' ')))<<('('-' '))|(('$'-' '|(('#'-'!')<<('$'-' '))|(('('-' '|(('/'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,'/'-' '|(('&'-' ')<<('$'-' '))|(('#'-'!'|(('('-'!')<<('$'-' ')))<<('('-' '))|((','-' '|(('&'-' ')<<('$'-' '))|(('$'-' '|(('&'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,'&'-' '|(('&'-' ')<<('$'-' '))|(('('-'!'|((','-' ')<<('$'-' ')))<<('('-' '))|(('$'-' '|(('$'-' ')<<('$'-' '))|(('$'-' '|(('#'-'!')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,','-' '|(('/'-' ')<<('$'-' '))|((!!""|(('#'-'!')<<('$'-' ')))<<('('-' '))|(('*'-' '|(('*'-' '|(('+'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,'.'-' '
,'('-' '|(('$'-' ')<<('$'-' '))|(('+'-' '|(('+'-' ')<<('$'-' ')))<<('('-' '))|((!!"")<<('='-'-'))
,('+'-' '|(('.'-' ')<<('$'-' '))|((')'-' '|((!!"")<<('$'-' ')))<<('('-' ')))<<('='-'-')
,('('-' '|(('$'-' ')<<('$'-' '))|(('-'-' '|(('('-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-')
,'$'-' '|(('('-'!')<<('$'-' '))|(('$'-' '|(('#'-'!')<<('$'-' ')))<<('('-' '))|((('/'-' ')<<('$'-' ')|(('/'-' '|(('+'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,!!""
,')'-' '|(('('-' ')<<('$'-' '))|(('('-' '|(('/'-' ')<<('$'-' ')))<<('('-' '))|(('/'-' '|(('%'-' ')<<('('-' ')))<<('='-'-'))
,!!""|(('#'-' ')<<('$'-' '))|(('/'-' '|(('/'-' ')<<('$'-' ')))<<('('-' '))|(('('-' '|(('+'-' ')<<('$'-' '))|((','-' '|(('#'-' ')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,(('/'-' ')<<('('-' '))<<('='-'-')
,'%'-' '|(('-'-' '|(('('-' ')<<('$'-' ')))<<('('-' '))|((','-' '|(('$'-' ')<<('$'-' '))|(('$'-' '|(('#'-'!')<<('$'-' ')))<<('('-' ')))<<('='-'-'))
,('/'-' ')<<('$'-' ')|(('('-' '|(('+'-' ')<<('$'-' ')))<<('('-' '))|(('$'-' ')<<('='-'-'))
,('-'-' '|((','-' ')<<('$'-' '))|((('('-' ')<<('$'-' '))<<('('-' ')))<<('='-'-')
,!!""|(('#'-' ')<<('$'-' '))|(('+'-' '|(('-'-' ')<<('$'-' ')))<<('('-' '))|(('('-' '|(('+'-' ')<<('$'-' '))|((!!"")<<('('-' ')))<<('='-'-'))
,(('-'-' '|((','-' ')<<('$'-' ')))<<('('-' '))<<('='-'-')
,('('-' ')<<('$'-' ')
};

このコードは、_という名前のint型の配列を定義している。その配列は.textセクションに配置される。配列のビット列は、x86とx86-64において"Hello, world!"と出力するものである。あとはプログラムのエントリーポイントを_startではなく_にしてリンクしてやれば、プログラムを実行するとこのビット列を実行しようとし、結果としてhello worldが出力される

このコードは、記号のみを使っている。アルファベットや数字は一切使っていない。ではどうやって、任意の数値を表現するのか。記号文字を使えるということは、たとえば'-'とか'$'のような文字リテラルを使うことができる。文字コードを限定すれば、その値はわかる。あとは、ビット演算を用いて任意の値に変えてやればいいだけだ。

_[]={ // 名前_の暗黙のint型の配列の宣言
'('-'!'|((','-' ')<<('$'-' ')) // 0xC7
    |
(('$'-' '|(('$'-' ')<<('$'-' ')))<<('('-' ')) // 0x44
    |
(('$'-' '|(('#'-'!')<<('$'-' ')) // 0x24
    |
((('/'-' ')<<('$'-' '))<<('('-' ')))<<('='-'-')) // 0xF0
,... 

// F0 24 C7 44
// mov dword ptr[esp-16], imm

もちろん、これを手で生成するのはダルいので、これを生成するコード、hello_gen.ccを書く。

#include <iostream>
#include <string>

using namespace std;

template <unsigned int n> struct Symbolizer {
 string s;
 Symbolizer() {
  if (n >= 0x10000) {
   s = "(" + Symbolizer<(n >> 16)>().s + ")<<(" + Symbolizer<16>().s + ")";
   if (n & 0xffff) {
    s = Symbolizer<(n & 0xffff)>().s + "|(" + s + ")";
   }
  } else if (n >= 0x100) {
   s = "(" + Symbolizer<(n >> 8)>().s + ")<<(" + Symbolizer<8>().s + ")";
   if (n & 0xff) {
    s = Symbolizer<(n & 0xff)>().s + "|(" + s + ")";
   }
  } else if (n >= 0x10) {
   s = "(" + Symbolizer<(n >> 4)>().s + ")<<(" + Symbolizer<4>().s + ")";
   if (n & 0xf) {
    s = Symbolizer<(n & 0xf)>().s + "|(" + s + ")";
   }
  } else {
   s = "(" + Symbolizer<(n >> 1)>().s + ")<<(" + Symbolizer<1>().s + ")";
   if (n & 1) {
    s = Symbolizer<1>().s + "|(" + s + ")";
   }
  }
 }
};

template <> Symbolizer<0>::Symbolizer() { s = "!\"\""; }
template <> Symbolizer<1>::Symbolizer() { s = "!!\"\""; }
template <> Symbolizer<2>::Symbolizer() { s = "'#'-'!'"; }
template <> Symbolizer<3>::Symbolizer() { s = "'#'-' '"; }
template <> Symbolizer<4>::Symbolizer() { s = "'$'-' '"; }
template <> Symbolizer<5>::Symbolizer() { s = "'%'-' '"; }
template <> Symbolizer<6>::Symbolizer() { s = "'&'-' '"; }
template <> Symbolizer<7>::Symbolizer() { s = "'('-'!'"; }
template <> Symbolizer<8>::Symbolizer() { s = "'('-' '"; }
template <> Symbolizer<9>::Symbolizer() { s = "')'-' '"; }
template <> Symbolizer<10>::Symbolizer() { s = "'*'-' '"; }
template <> Symbolizer<11>::Symbolizer() { s = "'+'-' '"; }
template <> Symbolizer<12>::Symbolizer() { s = "','-' '"; }
template <> Symbolizer<13>::Symbolizer() { s = "'-'-' '"; }
template <> Symbolizer<14>::Symbolizer() { s = "'.'-' '"; }
template <> Symbolizer<15>::Symbolizer() { s = "'/'-' '"; }
template <> Symbolizer<16>::Symbolizer() { s = "'='-'-'"; }

int main(int argc, char* argv[])
{
 cout << "_[]={" << endl;
#include "numbers.cc"
 cout << "};" << endl;
 return 0;
}

さて、.textセクションに書くバイナリ列はどのように生成するのか。これはhello_gen_gen.ccで、xbyakというライブラリを使って生成している。

#include <string>
#include <iostream>
#include <cstring>
#define XBYAK32
#include "xbyak/xbyak.h"

class PutString: public Xbyak::CodeGenerator {
 void syscall() { db(0x0F); db(0x05); }
 void int80h() { db(0xCD); db(0x80); }
public:
 PutString(const std::string &message) {
  unsigned int *data = (unsigned int *)message.data();
  mov(dword[esp - 16], data[0]);
  mov(dword[esp - 12], data[1]);
  mov(dword[esp - 8], data[2]);
  mov(word[esp - 4], data[3]);
  mov(edx, message.length());
  dec(eax);
  mov(ebx, 1);
  jmp("@f");
  add(byte[eax], al);
  dec(eax);
  lea(esi, ptr[esp - 16]);
  mov(edi, 1);
  mov(eax, edi);
  syscall();
  xor(edi, edi);
  mov(eax, 60);
  syscall();
L("@@");
  lea(ecx, ptr[esp - 16]);
  mov(eax, 4);
  int80h();
  xor(ebx, ebx);
  mov(eax, 1);
  int80h();
 }
};

int main(int argc, char * argv[])
{
 PutString put_string("Hello, world!\n");
 unsigned int *bin = put_string.getCode<unsigned int *>();
 size_t dwords = (put_string.getSize() + 3) / 4;
 std::string delim = "";
 for (size_t i = 0; i < dwords; ++i) {
  std::cout << "cout << " + delim + "Symbolizer<" << std::dec << bin[i] << "U>().s << endl;";
  std::cout << "  // " << std::hex << bin[i];
  std::cout << std::endl;
  delim = "\",\" + ";
 }
}

また、生成するビット列は、面白い工夫をすることで、x86, x86-64どちらでも動くようになっている。

実際にコードを入手して手元で動くことを確認したので、認めるしかない。

https://github.com/firewood/test

https://github.com/herumi/xbyak

ツール系で「BiiCodeとCLion」

あまり覚えていない。パッケージマネージャーはOSが提供すべきだ。

不遇の標準ライブラリ

valarrayの話。

Nicolai Josuttisが参考書に書いていたのだが、valarrayは標準化の途中で作者が途中で抜けたが、そのまま残ってしまったものらしい。標準ライブラリなので、ベクトル型としてコンパイラーが認識すれば最適化できるが、既存のほとんどの実装はvalarrayをベクトル型と認識した最適化をしない。

ベクトル計算は、Expression Templatesによる最適化に研究が向かってしまったので、型情報としてのベクトル型は放置されてしまった。

ただし、コンパイラーの最適化技術は進んだので、今ベクトル型として認識すれば、かなりいいコードが生成できる。現にiccはvalarrayをそれなりに最適化する。

ただし、ベクトル型を定義するのであれば、今新たに設計したほうがいい設計になるだろうから、やはりvalarrayに価値はない。

unique_ptrにポインタ以外のものを持たせる時

std::unique_ptrはカスタムデリーターにネストされた形名pointerを定義すれば、ポインター以外のものも管理できそうだが、既存の実装はnullptrと比較していたりして結局動かなかった。

C++標準化委員会には汎用RAIIラッパーが提案されている。

その後、22時頃まで一部の参加者が残って雑談したあと、解散した。

後片付けをした筆者が職場の自席に戻ると、日曜日なのに同僚のtayamaがいた。こんなに夜遅くに休日出勤なのだろうか。話しかけてみると、そうではなく、単に職場近くを通りかかったので、ついでに寄って、アニメを鑑賞しているだけだという。

勉強会で競技プログラマーがすごいhello worldを書いていたという話に及び、そのついでに、AtCoderで問題開示後3秒でコードを提出して通った猛者がいるという話をした。chokudai氏によれば、「問題の流出は確認されていない」という声明を出すに及んだという。

その場で調べてみると、3秒で提出されたコードは以下のものであった。

Submission #286413 - AtCoder Regular Contest 030 | AtCoder

問題は以下の通り。

A: 閉路グラフ - AtCoder Regular Contest 030 | AtCoder

n個の頂点からなる閉路グラフがあって、その頂点のいくつかを取り除くことでグラフを分断し、最終的にk個の連結成分のみが残るグラフにできるかという問題である。

問題文が意図的に難しく書かれているが、解法は、実際にグラフを生成して操作する必要はなく、単に\(k < \frac{n-1}{2}\)の場合は"YES"を、そうでなければ"NO"を出力すればいいだけだ。

問題開示後3秒でコードを提出したので、もはや人間業ではない。AtCoderにログインしてページをダウンロードしてコードを生成してアップロードするまですべてが自動化されている。どうやら、問題文は無視して、入力と出力のサンプルから、入力に対する正しい出力の計算方法を推定して、コードを生成したようだ。

ちなみに、問題の提出を探す仮定で、24秒で提出して通過したものなどが見つかった。こちらはどうやら手で書かれたようだ。問題は極めて簡単とは言え、人間業とは思えない。

我々はひとしきり感心した後に、職場を後にした。

ドワンゴ広告

この記事はドワンゴ勤務中に書かれた。

ドワンゴは勉強会の会場を提供しています。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-14

歌舞伎座.tech #8 C++初心者会の参加枠を10人増やした

歌舞伎座.tech#8「C++初心者会」 - connpass

17日に行われるC++勉強会について、当日の都合の悪い人は、早めにキャンセルをしていただきたい。

まだ会場の空間に若干の余裕があることと、当日の参加率(100%参加は経験上おそらくない)を見込んだ上で、10人ほど枠を増やした。これにより、待機枠からの10人分の繰り上げが発生した。

繰り上がった人は、これまた都合が悪ければ、早めにキャンセルをしてもらいたい。

ドワンゴ広告

そういえば、勉強会は私の発表時間を確保していなかった。ただ、今話せるネタもあまりない。C++17はまだ遠く、現在の提案を元に何を話しても、おそらく最終的にはガラリと変わってしまうだろうから。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-13

C++標準化委員会の文書集、2015-04 pre-Lenexa mailingsのレビュー: N4381-N4389

ISO/IEC JTC1/SC22/WG21 - Papers 2015

N4381: Suggested Design for Customization Points

現在、C++の標準ライブラリにはいくつかのユーザー側で挙動を変更できる箇所が存在する。

  • swap
  • begin
  • end

だ。文面の解釈次第では、iter_swapも該当するかもしれないとのことだ。

論文は、標準ライブラリのうち、これらの挙動を差し替え可能な部分を、カスタマイゼーションポイント(Customization point)と名づけている。

この関数テンプレートは、std名前空間で定義されていて、汎用的な実装になっている。もし、独自のユーザー定義型に独自のswap/begin/end実装を書きたい場合

struct X
{
    int data[100] ;
} ;

その型の名前空間スコープに、同名の関数/関数テンプレートを書けばよい。

int * begin( X & x ) { return data ; }
int * end( X & x ) { return data + 100 ; }

こうすることによって、ADLで適切な関数が選ばれる。

問題は、標準のカスタマイゼーションポイントと、ユーザーの提供するカスタマイゼーションポイントを合わせて呼び出すには、std::beginのようにqualified nameで呼び出すことはできない。現行のカスタマイゼーションポイントは、ADLを使っているので、以下のように呼ばなければならない。

template < typename Container >
void f( Container && c )
{
    using std::begin ;
    using std::end ;

    auto iter = begin( c ) ;
    auto end = end( c ) 
}

こうすることによって、std::begin, std::endという名前をname lookupで発見できるようにしたうえで、unqualified name lookupを行うと、ADLも働き、見つかった名前の中でオーバーロード解決が行われる。

しかし、このようにusing宣言を書いてからunqualified nameを使うやり方は、その原理の説明まで含めると、規格の詳細まで踏み込まねばならず、面倒だ。普通にstd::funcのようにqualified nameで呼び出してもこのような挙動になってほしい。

このようなcustomization pointは、今後も追加される見込みであるから、将来追加されるcustomization pointは、関数オブジェクトにして、その中でADLを用いたディスパッチにしようというという提案。

namespace std {
    namespace __detail {
        struct __begin_fn
        {
            template < typename R >
            constexpr decltype(auto)
            operator () ( R && rng ) const
            noexcept(noexcept(begin(forward<R>(rng))))
            {
                return begin(forward<R>(rng)) ;
            }
        } ;
    }

    template < typename T >
    constexpr T __static_const { } ;

    namespace {
        auto const & begin =
            __static_const< __detail::__begin_fn > ;
    }

}

つまり、std::funcはstd名前空間にあるfuncという関数や関数テンプレートではなく、関数オブジェクトになる。その関数オブジェクトは内部でADL経由のオーバーロード解決を行う。単純に__begin_fnの変数を宣言していないのは、ODRを回避するためだ。変数テンプレートにすることで外部リンケージを持ち、そのリファレンスを取ることですべての翻訳単位で共通にする。かつ、無名名前空間で囲むことによってその翻訳単位だけにする。

論文では、最適化の結果、出力されたコードにオーバーヘッドは一切ないことを確認したと書いてある。非最適化コンパイルではオーバーヘッドが生ずるが、問題ないコストであるという。

ただし、論文にも挙げられているように、問題も多少あるので、まだ議論が必要そうだ。

論文は、既存のcustomization pointには互換性のためにこの技法を適用しないとしている。そういう不一致もどうかと思う。

この手法は、range-v3ライブラリで試されているという。

N4382: Working Draft, C++ extensions for Ranges

イテレーターをさらに高級にしたレンジというライブラリの提案。提案中の軽量コンセプトを使って作られている。番兵の概念も導入するらしい。

N4383: C++ Standard Library Active Issues List (Revision R92)

N4384: C++ Standard Library Defect Report List (Revision R92)

C++ Standard Library Closed Issues List (Revision R92)

標準ライブラリの既知の問題、解決済みの問題、議論の結果却下された問題の一覧。

[極めて無駄なPDF] N4386: Unspecialized std::tuple_size should be defined

std::tuple_sizeのプライマリーテンプレートは従来未定義だったが、これを定義する提案。これにより、enable_ifのようなSFINAEの文脈で使いやすくなる。

N4387: Improving pair and tuple, revision 3

pairとtupleのコンストラクターがexplicitとなっているために、一部の初期化ができない問題を修正する提案。

以下のコードはエラーになる。

std::tuple<int, int> pixel_coordinates() 
{
  return {10, -15};  // エラー、なんで?
}

// コピーできない型、直接初期化はできる。
struct NonCopyable { NonCopyable(int); NonCopyable(const NonCopyable&) = delete; };

std::pair<NonCopyable, double> pmd{42, 3.14};  // エラー、なんで?

pairとtupleが設計されていた当時、暗黙に型変換できない型から暗黙に構築できてしまうことを防ごうとした。

また、C++03時代の0というnullポインター定数の挙動の互換性を保とうという設計もされていた。

また当時、pairはアロケーターサポートのためにコンストラクターの数が膨れ上がっており、新しくコンストラクターを追加するのはできない雰囲気であった。

結果として、N3240提案を受け入れた結果、pairとtupleは以下のような設計がなされることになった。

1. 要素の型が実引数の型から暗黙に変換できない場合は弾く。

struct B { explicit B(bool); };

std::tuple<B> tb = std::tuple<bool>(); // エラー

非テンプレートとテンプレート版の同等のコンストラクター、tuple( const Type & ... )は、explicitとなった。これにより、要素がひとつだけのtupleが、explicitしかコンストラクターがない実引数からコピー初期化されるのを防ぐ

struct X { X(); explicit X(const X&); } x;

std::tuple<X> tx = x; // エラー

struct E { explicit E(int); };

std::tuple<E> te = 42; // エラー

非テンプレート版のコンストラクターは、nullポインター定数である0からの変換を許容する。

class C;

std::tuple<int*> tpi(0); // OK
std::tuple<int C::*> tpmi(0); // OK

この提案は、実装例として、perfect initializationと称する技法を提示している。テンプレートのexplicit/非explicitのコピー風コンストラクターをオーバーロードすることで元の型とほぼ同じように初期化できるという仕組みだ。文面はこの技法を使うことを必須としておらず、実装上の自由をもたせている。

N4388: A Proposal to Add a Const-Propagating Wrapper to the Standard Library

メンバー関数のconst性をポインター風のメンバーに対しても伝播するライブラリ、propagate_constの提案。

非staticメンバー関数のconst修飾は、ポインター風のデータメンバーを伝播しない。

struct A
{
    void f() { } // 非const
    void f() const { } // const
} ;

struct B
{
    std::unique_ptr<A> ptr ;
    B() : ptr( std::make_unique<A>() ) { }

    void f()
    {
        ptr->f() ; // 非const版が呼ばれる
    }

    void f() const
    {
        ptr->f() ; // 非const版が呼ばれる
    }
} ;

これは言語的には正しい挙動だが、意味上のconstとして、ポインターを経由したアクセスでもconst版のメンバー関数が呼ばれて欲しい場合がある。この時に使える。propagate_constライブラリを提案している。名前通りに、const性を伝播させる。


struct B
{
    std::propagate_cosnt<std::unique_ptr<A>> ptr ;

//  以下同じ
} ;

N4389: Wording for bool_constant, revision 1

std::integral_constantのbool版のエイリアステンプレート、bool_constantの提案。既存のtrue_typeとfalse_typeはbool_constantを使ったものに書き変える。

namespace std {
  // 20.10.3, helper class:
  template <class T, T v> struct integral_constant;

// N4386提案
template <bool B>
using bool_constant = integral_constant<bool, B>;

// C++14の定義 
// typedef integral_constant<bool, true> true_type;
// typedef integral_constant<bool, false> false_type;

// N4386提案
typedef bool_constant<true> true_type;
typedef bool_constant<false> false_type;

ドワンゴ広告

今週末は勉強会だ。今回は初心者に発表経験を持たせるために、初心者ばかりを募ったはずなので、それほど怖い話はないはずだ。たぶん。

歌舞伎座.tech#8「C++初心者会」 - connpass

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-11

D4492: Bjarne StroustrupによるC++17の考察の翻訳

April 2015 : Standard C++

C++WG内部のMLで議論していた内容が、どこからか外部に流れて、様々なフォーラムで話題になっている。

“What will C++17 be?” -- Bjarne Stroustrup on C++17 goals : programming

What will C++17 be? | Hacker News

C++ Daddy Bjarne Stroustrup outlines directions for v17 • The Register Forums

これを受けて、Bjarne Stroustrupは議論をまとめて標準化委員会の論文として公開することにしたが、それも時間がかかるので、ドラフトがC++財団にあがっている。

[PDF注意] D4492

C++17の考察

Bjarne Stroustrup

このドラフトはLexena会議における議論の方向を定めるためのものである。

これは標準化委員会内部のやり取りが外部に流通して広く議論されていたのを、ドキュメント化する価値があるので、意見を参考にまとめたものだ。委員会内のわかりにくい符牒は置き換えるようつとめた。内部で議論したり、Web上で議論した人間に感謝する。筆者はリンクも追加した。これは正式な論文や提案というよりは、議論のための考えの列挙に過ぎない。

この文章は委員会のメンバーに向けて書かれたものだが、いつのまにか公に出回った。以下がWeb上のコメントの一部である。

見てわかるように、委員会外の人間も、強い意見を持っている。これらの意見は、筆者が委員会内で聞くものとはかなりかけ離れているし、現実ともかけ離れている。

筆者は、「C++17はどのようになるのか?」とか、「C++17は私に何をもたらすのか」といった質問をよくされる。「よくされる」というのは、「ほぼ毎週2回以上」程度である。私はC++17がどのようになるかを簡単に説明することができないので、この質問に対しては自信恥ずかしい思いをする。言語機能や標準ライブラリの一覧は、納得できる答えではない。

筆者はC++98, C++11, C++14における目標について話そうと思う。今のC++を実現してきた目標とは何か。

今と同じように、かつてもC++を委員会による設計の弊害を受けた汚らしい成れの果てだとみなす風潮があった。これは、委員会が組織される前から言われていたことだが、今や更にひどく言われているように思う。今やC++はより巨大になった(特に標準ライブラリを考慮すると)。そのことと、現在の大量の提案を考えれば、その指摘にも一理あるように見える。この手の連中が、変態的な技法を用いたパズルめいたものを提出して攻め立てるのはいらただしいことだ。その手のものは、筆者からすれば、「何か問題があるのかね。もちろんメタハンマーで頭を叩くのは痛いだろう。だからそんなことはするな」というカテゴリーに分類されるべきものである。連中は委員会の責め立てる。そのようなコードはたいてい、C++を貶めるために使われるものだ。よりよいソフトウェアを書いたりするのに役に立たないばかりか、。人々をC++の学習から遠ざけてしまう。

物を作るより批判するほうが簡単だ。

Robert Klarerが言うには、「委員会による設計に対する懸念は、必要以上に恐れられている。そもそも、この世界の殆どの者は委員会によって設計されているというのに。人間によって作られたもので、何らの協調作業も発生していないものは極めて少ない」と。我々はチームで作業しなければならない。他の方法はないのだ。

C++は多くの利用例において最良のツールである。特に、リソースの制約が厳しいであるとか、巨大であるとか、利用期間が長いなどの過酷な用途に向いている。これをさらに改良し、かつ初心者にわかりやすくし、それほど過酷ではない仕事(ただし、大抵は急いでいる)に従事する人にも使いやすくしたい。

さて、C++17はどのようなものになるべきか。私の考えはこうだ。

  • 巨大な依存のあるソフトウェアのサポートの改良
  • 高級な並列実行モデルのサポートの提供
  • コア言語の利用を簡単にする。とくに、STLと並列実行と、主要な間違いの元を改良する

最後の項目は、先の2つの項目の書き直しでもある。

そして以下が、C++11やC++14で継続して行ってきたことの簡単なまとめだ。実際、C++の長期的な目標からはあまり違わない。

標準化委員会はC++の根本的な強みを維持しなければならない。

  • ハードウェアに直接マッピング可能なこと(Cから)
  • ゼロオーバーヘッドの隠匿(Simulaから)

[訳注:Simulaは極めてオーバーヘッドが大きかったので反面教師的な意味合いか?]

この強みから離れると、その言語はもはやC++ではなくなる。別の目標を持った言語は様々ある。他の言語とてすべての問題に対する解決を提供しているわけではない。当初の目標から外れず、変化を受け入れる姿勢こそが、理想に近づけるのだ。C++は計算機の歴史上、もっとも成功した言語の一つとなった。これを維持するためには、2つの落とし穴を避けねばならない。

  • 過去を捨て去ること(例、互換性を深刻に失うこと、C++は長期的に使われるシステムで多用されてきた)
  • 新しい問題への対処を怠ること(例、高級な並列実行モデルをサポートしないこと。C++は並列実行の需要を満たすために多用されている)

さて、これが基本だ。以下が詳細だ(関連する論文へのリンクもある)

筆者はライブラリと言語機能を意図的に分割しなかった。そういう区別は一般ユーザーには無意味なものだからだ。

筆者の予想では、C++17は2017年に制定される。標準的なISOの10年リリースサイクルに戻るべきだとは思わない。

この表に好きな機能がないとしたら? それはフレームワークに取り込んで使える機能だろうか? C++の目標は変えるべきだろうか? 主要な目標は3つ程度であるべきで、後の2つは外せない重要なものだ。なにかよりよい目標を設定できるだろうか?

もし、お気に入りの機能が今回入らなかったとして、C++20の時間枠に入るだろうか? 筆者は、単に自分の提案だからという理由ではなく、短期から中期(C++17, C++20)において、いま重要だと思うことに注力している。

歴史的に、委員会は、目標にそぐわなかったとしても、自明に有用でよく使われているものを追加しようとしてきた。complex<T>はそのいい例だ。そのようなことは二度としないとはいわないが、頻繁に行うべきではない。そのような方向性の定まらないアイディアで、重要な目標や納期を見失ってはならない。

C++17は、マイナーリリースだったC++03やC++14と違い、メジャーリリースとなる予定である。何か主要な機能を提供しなければ失望されるだろう。筆者の考えでは、2つか3つほどの主要機能と、いくつかの中規模な機能と、いくつかの小規模なものが、最低限の許容可能で実現可能なものだろう。筆者は規模の大小について、標準規格の文面の量ではなく、ユーザーに与える影響で考える。そのため、コンセプト、モジュール、レンジは大規模(そして筆者の好ましいと思う機能)で、デフォルト比較やstd::optionalは小規模だ。(とはいえ、筆者の好みの機能だ)

無関係の機能やライブラリを大量に追加するのは、言語を複雑にし、初心者にも、「通常のプログラマー」にも、C++を恐れさせてしまう。一部のエキスパート(標準化委員の一部とその身内)は満足だろうが、目標を明確に見据えなければ、一般のプログラマーを惹きつける魅力は得られない。これを「マーケティング」と呼ぶ人もいるだろうが、筆者は、「設計」と呼びたい。

わかりやすい例を出すと、STLはそのいい例だ。もしAlex Stepanovがたった数種類のコンテナーと数個のアルゴリズムしか提案しなかったのであれば、その提案は今よりとてもわかりやすかっただろうが、STLに与えた影響は今よりも軽微であっただろう。実際、STLは変わっていくものである。筆者はコンセプトとコンセプトベースの標準ライブラリが次のいい例となることを期待している。「委員会による設計」の典型例となって嫌われることは望まない。

筆者がしたくないこと:

  • C++を劇的に違う言語にすること
  • 分割された言語のサブセットを提供することで、C++の一部をさらに高級な言語とすること
  • 新しいパラダイムをサポートするためにC++に機能をツギハギすること
  • C++が必要とされている分野でC++が使われることを妨げること
  • 99%の利用者にとってC++を使う際の複雑性を上げることによって、1%(標準化委員とその身内)を利すること

このどれもが失敗のもとだ。

これについては同意できるだろうが、果たして読者はその同意を維持できるだろうか。怪しいものだ。抽象的な目標について同意することはできても、その目標の意味する具体的なところについては、何かができなくなったり、納期に間に合わせるために後回しにしたりしなければならないため、この基本目標への同意は用意に破られやすい。「何を捨てるのか決定するのが難しいのだ」とはよく言ったものだ。

もちろん、筆者は特定の一覧の他は一切C++を改良するための提案を行わないことを主張しているわけではないが、しかし、なにか優先度について合意をしておかなければ、委員会には何十もの「ほぼ完了した」主要機能が2016年に溜まり続け、機能追加を辞める段階になっても、どれも規格制定には至らない状態になっていることだろう。何十もの小規模な、独立した機能は、我々がプログラムを構築するのにそれほどの影響をもたらさないので、主要機能ほどの魅力はない。

Pete Beckerの言葉を要約すれば、鉄の三原則とは、機能、品質、納期だ。2つまでならば選んでもよい。選択をしなければ、委員会は何も選ばなかったことになる。

委員会の避けるべき悪い習慣、C++批判の燃料となる習慣:

  • 言語機能よりもライブラリのほうが標準化委員会で受け入れられやすいのでライブラリとして提供する(たとえその提供する機能が根本的なものであると主張する十分な材料があるとしても)
  • 既存の機能と組み合わせた使い方は互換性の問題を生ずるので、独立した機能として提供する。これは単に組み合わせを将来に先送りするだけだ
  • 2つの相反する選択肢がある場合に、両方とも採用する。あるいは選択肢を3つにして、最初の2つの選択肢を、投票権を持つ全員が喜ぶ形に書き直す(これは純粋に委員会による設計だ)
  • 自分のお気に入りの提案に費やす時間と労力が足りないために、別の提案に反対する
  • 超短期的な利益のみを追求する
  • 現在の自分の仕事に関係のない提案に反対する。他人を利する改良を停滞させる。
  • 論文の文面に注力して、ユーザーの需要を無視して、現在の文面に一致する技術的な選択をする。
  • 文法の多さはプログラマーを楽にするはずだという考え
  • ライブラリ作者などのエキスパート達のみを相手にして、大多数の現在と潜在的な世間一般のC++プログラマーを無視する
  • 「現在の流行」を追い、C++のプログラミング流儀に与える影響と既存のC++機能との併用を考えずに、他の人気の言語からの機能をダメ押しする
  • 既存の機能との併用を避けるために、提案を自己完結させる
  • すでに提案されている他の提案を無視する
  • 「原則」を神聖にして不可侵るものだと主張する
  • 完璧でないものを受け入れない
  • 何でもしようとする

こういうことをしてはいけない。

筆者がよく聞かれることに、特に、影響力がある有名人に聞かれることに、D&E 2を予定していないかということがある。予定していない。筆者はC++の利用と改良にとても忙しい。しかし、もし引退するのが都合がいいと考えたならば、D&E 2はよい企画だ。しかし、そのためには言語と友人をけなす必要が内容にしなければならない。委員会は自ら誇って語れるものを制定する必要がある。

標準化委員会には長期的な目標が必要だが、そういう目標は、往々にして「カーチャンの味噌汁の味付け」のような絶対に反論不可能なものになる。委員会には短期的な目標も必要だ。さもなければ、現在の誰かの問題を解決するためだけの機能を追加し続けることになり、将来の発展の妨げになり、機能の重複にもつながる。これは、筆者が、「開発者視点の思考」と名付けるもので、何十年も存続する長期的なプロジェクトにはふさわしくない。目標についてよく考える必要がある。筆者の主要な目標は、長期的な利益の方にバイアスがかかっており、残りの2つは、C++17についてだ。

標準化の仕事では、標準化委員は単なる開発者ではいられない。成功するためには、委員は、研究、目標の設定、計画、管理、実装、教育と普及などなどの様々な役割をこなさなければならない。

標準化委員会はなにか大きなものをC++17で制定しなければならない。筆者が考えるに、委員会はその方向で動いている。実験と称して規格制定を遅らせたり、小さな改良のみに注力するのは大きな間違いだと思う。つまり、標準化委員会はいくつかの大きな問題と、それを支える小さな問題に注力しなければならない。筆者の恐れることは、委員会はすべてのことをしたがるあまりに、すべての提案を等しい優先度で扱い、結果として、全方向に僅かな改良だけが得られるということだ。明らかに、C++20まで先送りにしなければならないものもある。標準化委員会にはStudy GroupとTS(ISO Technical Specification)があり、両方共、標準化のために必要な諸々の作業を提供することができる。現在作業しているすべての労力がC++に入るわけではないし、好ましいもののみがC++17に入るわけでもない。大きな集団にありがちな、利己的な目標を達成するために規則を悪用するようなことにはなってほしくないものだ。

「でさ、Bjarne」と私の友人の一部が笑いながら言う。「お前が本当に考えてることを聞かせてくれよ」と。つまり、私の考えていることはあまりにも尊大で誰かを侮辱するかもしれないということだ。私の考えることが、誰か、C++コミュニティの利益を考える人間を侮辱するということはない。実際、私の言っていることは侮辱ではない。

さて、これが個人的なC++17のトップ10リストだ(順不同)

  • コンセプト(ジェネリックプログラムを詳細に規程できる上、エラーメッセージの品質が悪いという不満を解消できる)
  • モジュール(マクロから独立できる上、コンパイル時間の短縮になる)
  • レンジとその他のコンセプトを使ったSTLコンポーネント(エラーメッセージの改良とSTL2としてのライブラリ文面の改良)
  • 統一関数呼び出し記法(仕様の簡単化とテンプレートライブラリ利用の簡略化)
  • コルーチン(とても高速で簡単であるべき)
  • ネットワークのサポート(TSのasioベース)
  • 契約(C++17の標準ライブラリで使われる必要はない)
  • SIMDベクトル演算と並列アルゴリズム
  • コルーチン[訳注:原文ママ]
  • optional, variant, string_view, array_viewのような"vocabulary type"

最後に、筆者は言語とライブラリと、新機能と、既存の機能との、一貫性の重要について再び記しておく。標準化委員会の目標は、関係性の曖昧な機能群ではなく、有用なアイディアのための一貫した言語でなければならない。

この一覧表はすべて、C++17の標準規格の文面に入れるのに現実的であり、コンパイラーとライブラリの実装も現実的である。ほとんどの機能は、すでに何らかの形で存在している。重要なのは、どのように設計するか、どのようにコードを書くかである。

これが、筆者の機能一覧だ。C++コミュニティの利益と、実現性を考えた結果だ。読者の機能一覧はこれとは異なるかもしれない。よく考えてもらいたい。私の好む提案で、特に筆者も著者となっている論文で、この一覧にあげていないものもある。解決すべき問題があるが、まだ技術的な解決法がないのだ。例えば、標準C++ABIなど。筆者が思うに、C++17にはまだいくつかの提案が出てくるだろうから、これを最終的な機能一覧だとは考えないでもらいたい。これは議論を集中させるための土台で、最終決定ではない。それに、まだTSもある。

C++17制定後は、C++20がC++17を完成させるだろう。C++14がC++11に大してそうだったように。

ドワンゴ広告

この記事はドワンゴ勤務中に書かれた。この翻訳は疲れた。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-07

InfoQのC++17についてBjarne Stroustrupへのインタビュー記事の翻訳

Stroustrup: Thoughts on C++17 - An Interview

C++の設計者にして最初の実装者であるBjarne Stroustrupは、C++17の設計と新機能の議論の起爆剤となるための、ドラフトを公開した。Stroustrupによれば、C++17は以下の3つの設計目標がある。

  • 巨大な依存関係のあるソフトウェアのサポートの改良
  • 並列実行に高級なモデルのサポートの提供
  • コア言語を簡単にする

上記の設計目標について、StroustrupはC++17に入る以下もしれない機能を列挙した。Stroustrupの好ましいと考える機能の例が以下だ。

Stroustrupは、「言語とライブラリの新機能の一覧」をもって、C++17がどのようなものになるかを説明することはできないと注意を促している。C++17は、C++14と違い、メジャーリリースであるため、少なくとも、言語がユーザーに与える影響として「2つか3つほどの大きな機能」が入っているべきであるとしている。例えば、コンセプトやモジュールやレンジなど。

この文書は興味深いことに、C++17が目指さないことについても書いてある。特に、Stroustrupが不適切であるとしたものは以下の通り。

  • C++を急激に別言語にすることや、言語のサブセット言語を作ること
  • 「他の言語がみんなサポートしている」とか、新しいパラダイムをサポートするという理由だけによって、新機能を追加すること
  • 言語を複雑にしたり、システムプログラミング用の言語としての力を阻害すること

InfoQはStroustrupと話す機会を得た。

InfoQ、「C++17の機能一覧についてコメントをくれませんか。優先順位はありますか」

Stroustrup:

コンセプトは既存のジェネリックプログラミングへの考え方を改めるだろう。ジェネリックプログラミングをさらに主流のものとする。コンセプトはエラーメッセージが難解であるという不満への解決でもある。それには、標準ライブラリにコンセプトを対応させなければならない。

モジュールはコンパイル時間とマクロの濫用を劇的に改善し、優れたC++のツール開発につながるだろう。

高級な並列実行モデルは並列コードを書くのをとても簡単にし、低級なスレッドとロックによる並列コードよりも、結果のコードの実行を高速にするだろう。

これらの機能はコードを簡単にすることで品質を向上させるので、理想的だ。

InfoQ、「ここ数年と今後の標準化委員会のC++17働きにより、C++言語はよく議論される制限を克服しようとしているように見えます。これは、「委員会による設計」は実用的なものを生み出さないという意見を否定的に証明しているようです。委員会による設計についてコメントをください。どのようにすれば成功するのでしょうか。」

Stroustrup:

委員会による設計の問題を見過ごすことはできない。100人もの個人(会議に出てこないものまで含めれば、あるいは300人もの個人)からなる集団から、なにか新しい、信頼できる、統一感のあるものを創りだすのは並大抵ではない。

我々がやっていけるのは驚異的なことだ。もちろん、もっとうまくやれた部分もある。もちろん、委員会として活動するのは埒が明かないときもある。しかし、このスケールは、個人ではやり遂げることができない。これは委員会か個人かどちらがよいかという問題ではなく、委員会として活動するのが必須であるというだけの話だ。この世界の重要なことで、個人によって成り立っているものは実に少ない。

InfoQ、「C++17はC++が根本的に、低級(言語の意味をとても細かく操作できるという意味)で、マルチパラダイムで、複雑な言語であるということを示しています。しかし、委員会の目的に言語を使いやすくするということが含まれています。C++をより使いやすくするという委員会の思想についてお答えください。」

Stroustrup:

言語の低級性高級性について考えるのは間違いだ。C++はハードウェアを直接操作することを妨げないということと、それに加えて、隠匿の仕組みを用いて、必要であればより高級に隠匿できるものとして考えるべきだ。ハードウェアに近いプログラミングは必要だが、あまり快適ではない。C++はゼロオーバーヘッドの隠匿を可能とし、コストを加えずしてハードウェアから離れることができる。「ゼロ隠匿」というのは、手で書いた低級な実装よりも、1バイトも1サイクルも無駄にしないということだ。関数呼び出しのオーバーヘッド(特に間接的な関数呼び出し)ですら懸念される。ハードウェアアクセスと隠匿を同時に提供するのが、C++の考えだ。それを効率的に行うというのが、他の言語との違いだ。

私はこれをもう「マルチパラダイム」とは呼んでいない。なぜならば、私はこの言葉が、言語のすべての力を活用するより、単にひとつのパラダイムを選択してソレだけを使うことを推奨してしまっていると気がついたからだ。残念ながら、私はこれに変わるいいバズワードを思いついていない。

委員会が何らかのひとつの思想を持っているというのは公平ではないだろう。我々は多くの個人であり、それぞれ異なる事情と視点を持っている。多くはC++について上記のことに同意している。これがC++の精神であり、誤解してはいけない。我々は互換性を厳格に守らなければならないということについても同意している。C++業界は改良を求めるが、しかし、この業界は絶対に絶対に既存の何十億行ものコードが、その改良の結果として壊れることを望まない。どのような改良をしたかの詳細については重要だ。これはまともな時間内に実現可能でなければならないし、言語とライブラリでどのように表現するかということも重要だ。これは多くの集団で合意が得られにくいものだが、合意は必須だ。だからこの文書を書いたのだし、次の会議でもこのことについて話すのだ。

私がC++とその標準化に多大な時間を費やしてきたのは、これが多くの業界にとって重要だからだ。コンピューター、セミコンダクター、交通、電信、ファイナンス、製造業、旅客機、娯楽業界、などなど。多くの重要なシステムやガジェットの中身を見てみると、だいたいC++が使われている。この事実と、ソフトウェアシステムによって科学に貢献していることが、私の動機だ。C++は重要な財産を作るために使うためのツールだ。

ドワンゴ広告

この記事はドワンゴ勤務中に書かれた。最近、ドワンゴがITSCJの規格賛助員になったので、いつかC++標準化委員会の国際会議にも出席してみたいものだ。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-06

Jacob Kaplan-MossのPyCon 2015における基調講演: プログラミングの才能という都市伝説

Keynote - Jacob Kaplan-Moss - Pycon 2015 - YouTube

The programming talent myth [LWN.net]

PyCon 2015で、Djangoの貢献者であるJacob Kaplan-Mossが興味深い基調講演をしているので紹介する。LWM.netでほぼ全面書き起こしに近いまとめがあったので助かった。

自己紹介

Kaplan-MossはDjangoの貢献者であり、Herokuのセキュリテイ部門の部長である。PyCon参加者としては歴史が長く、その他のカンファレンスでもよく発表している。Pythonコミュニティは「自分にとってこの業界におけるとても重要なもの」であり、PyConの基調講演を行うということは、「自分のキャリア上の絶頂」である。

自分の最初のPyConの発表は2005年のことで、PythonとAppleScriptを結びつけるツールについてのものであった。ワシントン DCで開かれた当時のPyConで、Adrian HOlovatyは、自分の働くカンザス州Lawerenceの新聞社のWebサイトを構築するためのツールの技術デモを行った。このツールは、後にDjangoとなるものであった。今や、Djangoは10歳になり、世界中で使われている。PyCon参加者が300人から3000人に膨れ上がるまでを見てきた。コミュニティは新規参加者で膨れ上がり、別物になりつつある。そのため、「自分のキャリアにおける絶頂」というのは、文字通りの意味だ。

しかし、頭の中でふと思うに、自分はこの発表のステージに立つのにふさわしくないのではないか。この成功を受けるほどの価値ある人間ではないのではないか。脳内で、謙遜が起こる。

今までの業績は誇らしい物だ、実際、自分の過去の業績は、自分をこの場に立つ価値があるものにしている。しかし、自分は聴衆が考えているような人間ではない。

聴衆の多くは、自分がここで基調講演を行っているのは、「Djangoの発明者」であるからだと考えているだろう。しかし、それは違う。Djangoの由来を知っているものは、「Djangoの共同開発者」であると考えるだろう。しかし、これも過大評価である。実際には、自分はAdrian HolovatyとSimon WillisonがDjangoを発明して共同開発した一年後に、新聞社に雇われて開発に参加した者である。そんなわけで、自分は「すでに出来上がって1年以上たったものを開発するために雇われた人間」である。

皆、自分のことをDjangoの発明に関わりのある人物だと考えるのは、自分が「素晴らしいプログラマー」であると考えているからだろう。つまり、「ロックスター」とか「ニンジャ」とか、あるいは「転職エージェントが最近よく使う言葉」のプログラマーであると考えているからだろう。皆、自分はプログラミングの能力によって成功したと考えている。しかし、それは違うのだ。「私は、言うてありきたりなプログラマー」である。

ランニングについて

[ライドにウルトラマラソンランナーのAnn Trason] Ann Trasonはスポーツの歴史上素晴らしい成果を上げた者だ。ウルトラマラソンとは、26マイル以上走るマラソンのことだ。大抵は、山道を走ったり、川を横切ったりするもので、難しいものになると、何日も走り続けなければならないものだ。走る距離はたいてい50kmから160kmほどだ。Trasonは10年、20年後も破られない記録をいくつも作っている。彼女の記録に一時間以内に入れる人間はいない。Trasonはこの業界を独占していて、実にずば抜けて優秀な人物である。自分がこれを話すのは、自分もこの間、50kmのウルトラマラソンを走ったからだ。

しかし、自分はTrasonには遠く及ばない。同じブランドの靴を履いているだけだ。自分はどこにでもいるありきたりなランナーであり、1000人中535位であった。ランニングのパフォーマンスを評価する数値は多数ある。ペース配分、コースの距離や高度などだ。ランナーのスコアを計算して、そのランナーがどのくらい優勝者に近いかをはじき出すWebサイトがある。自分は68%であり、Trasonは98.58%だ。つまり、彼女はだいたい優勝するということだ。

この差は驚くに当たらない。レースのタイムのヒストグラムを描いてみると、よく見慣れた曲線が描かれる。ベル・カーブ、あるいは正規分布と呼ばれているものだ。ほとんどの人間は平均的で、ごく一部の例外的に優秀か、ダメな者が、極めて細い曲線の終わり付近にいる。我々が計測方法を知っているおよそすべての能力は、この曲線のような分布をする。

ありきたりということについて

さて、じぶんはありきたりなプログラマーであるが、聴衆の中には、信じない人もいるだろう。何故だ? ここにいる聴衆のほとんどは、Kaplan-Mossと共同作業をしたことがないはずなのだが、なぜ自分のコーディング能力が例外的に優秀であると言えるのか。評価すべきデータが存在しない状況では、曲線の中央辺りに位置すると考えるべきではないのか。そもそもの問題として、コーディング能力を評価する方法がないということがある。我々はソフトウェアを作成する能力を評価する方法を模索している赤子のようなものだ。評価基準としては何がある? コード行数か? 一体それは何を評価しているのだ? ストーリーポイントか?[訳注:スクラム用語、ストーリーを完了するために必要な作業時間の見積もり]。そもそも、ストーリーポイントって何なんだ?

プログラマーは論理的な解析的な現場で働いていると思いがちであるが、実際のところ、プログラミング能力を機械的に計測する方法などないのだ。人間は、データが与えられない時、逸話を作る。この逸話は、単純でステレオタイプになりがちである。そこで、我々は、「プログラミングのできないザコ」とか、「プログラミングのできる神」などと言ったりして、その中間を完全にすっ飛ばしてしまうのだ。人というのは誰でも、素晴らしいプログラマーか、あるいは、「椅子を浪費するだけの無能」のどちらかに分類される。

しかし、その場合、プログラミング能力というものは、U字型の曲線を描くことになる。ほとんどの人はその両端のどちらかに属している。これはいかにもありえないことだ。思うに、人間というものは経験を積むにつれて学んでいくものだろう。どうやって、何もできないザコからガチ勢まで、中間を経ずして能力の向上ができるのだろうか。両極端な2つの分類しかできないため、多くの者は自分を「素晴らしいプログラマー」に分類するのだ。あいつはDjangoの関係者である。するとクソなプログラマーの方に分類することはありえない。自然として、もうひとつの方を選ぶようになるのだ。

しかし、もし、何らかの方法でプログラミング能力を評価できるとしたならば、その曲線は正規分布するはずである。ほとんどのひとはほとんどのことにおいて平均である。Wobegon湖[架空の地名。過大評価する例えに用いられる]ではないのだから、大多数が平均より上であることはありえないのだ。

危険な都市伝説

この、プログラミング能力がバイモーダル分布(U字型)するという考えは、危険であり、都市伝説である。この都市伝説は、ロックスターかニンジャでなければプログラミングできないという雰囲気を作り出す。これは人々をプログラミングの学習から遠ざけるという害悪をなしており、将来のためによろしくない。

アメリカ労働省の統計によれば、2020年には150万人のプログラマー職の求人数にたいする労働者の供給不足が生じると予測されている。これは、多くの職場で人手不足ということになる。これは5年後のことだ。EUも似たような数字を出している。2018年に120万人。3年後だ。つまり、我々はなんとかしてもっと多くの人材をこの業界に呼び込まねばならない。しかし、この都市伝説はプログラミングを仕事に選択しようと考える人たちを躊躇させるものとなっている。この都市伝説は、プログラミングというものは生まれながらにして持つ先天的な才能であるという考え方からも支持されている。まだソフトウェアを書いたことがなく、都市伝説を信じるものは、用意にこの罠に引っかかる。年齢が30か、あるいは20か15になって、まだ一度もコードを書いたことがないので、一生コードを書けるようにはならないだろうと考えてしまう。

もし、選択肢が神かザコしかないのであれば、仕事に対してやりがいを感じなければやってられないと考えるようになるだろう。いつなんどきでも四六時中プログラミングのことを考えている奴、ほんの僅かでもよそ見をすれば、すぐに神からザコに落ちてしまうという考え。この考えは、人々をして長時間労働させ、プライベートな時間でも常にプログラミングについて学ぶようにさせていたりする。

しかし、他の業界については、我々はそのようには考えない。去年マラソンを走った50万人の参加者の全員が、先天的にランナーとしての才能を持っていたのであろうか。疑わしいものだ。私はそんな才能は持っていない。ほとんどの参加者は、かなり悪く走っていた。極めてひとにぎりの者達が、とてもよく走っていた。ランナーとなるためには、靴が一足あればいいだけのことだ。ランナーとなるために、走ることを好きになる必要はない。

自分がランニングで一番好きなことは、ゴールすることだ。マラソンを走るのは難しい。訓練と継続が必要だ。ソフトウェアを書くことは、Pythonを書くことは、マラソンを走るより難しいだろうか。なぜここには50万人の聴衆がいないのか。コーディングという能力に対してはそういうは話をしておきながら、ランニングという別の能力にはそういう話をしていないではないか。

自分は数年前、カンザス大学のGISデーで、カンザス川の反乱の予測に関する素晴らしい発表を聞いた。この学生が使ったツールは、このPyConでは使い慣れたものが多いであろう、Amazon Web ServiceとかLinuxとかPostgreSQLとかPytonとかDjangoとかGeoDjangoといったものだ。この学生はPythonで数千行のコードを書いたばかりだった。自分はうちの会社の採用面接を受けるつもりはないかと聞いてみた。学生は、「自分にはできない」という。なぜならば、「自分は本物のプログラマーではないから」と。この学生は自前で分散GISデータ処理パイプラインをたったいま実装した者であるが、本物のプログラマーではないという。これはプログラミングとは都市伝説の中の話で、自分に関係のあることではないという考えによるものだ。

実際のところ、プログラミングというのはやりがいとか才能によるものではない。プログラミングとは学ぶことができる能力を寄せ集めたものでしかない。そもそもプログラミングとはひとつではない。ここまで、プログラミングというひとつのものがあるかのように話してきたが、プログラミングには実に多くの能力が必要であり、コーディングはその能力のうちのひとつでしかない。設計、コミュニケーション、作文、デバッグも必要だ。そうそう、それからUnicodeについて理解している者が最低一人は必要だ。[聴衆の笑い声]

実に多くの独立した能力があるが、我々は人をスキルセットのうちの最も貧弱なもので評価しがちである。ほう、君はデザイナーとして優秀で、人前で話すこともできれば作文もできる。しかもプロジェクトマネージャーとして優秀である。結構なことだ。しかしリンクリストを理解していないだと? 「おうちに帰んな坊や」とね。他の能力と同じように、プロとしてプログラミングすることもできれば、たまにプログラミングすることもできるし、趣味としてプログラミングすることもできる。パートタイムかフルタイムかどちらでもよい。プログラムを下手に書くこともできるし、うまく書くこともできる。しかし、大半は平均的なプログラマーだ。

「そこそこの実力で十分だ」という考え、平均的な能力でよいという考えが広まれば、新参者がプログラミングに抱く恐れが少なくなる。もし、成功のハードルが、ずば抜けて優れているのではなく、そこそこで十分だとなれば、コミュニティに新たにやってきた人にも、やすやすと飛び越せるだろう。実際、コミュニティにやってきた人に、才能の都市伝説が与えた悪影響は一度限りではない。人々を技術から遠ざける結果となってしまう。

技術業界は、性差別、人種差別、同性愛差別などのあらゆる差別が渦巻いている。これは一つの問題ではないし、原因も一つではないのだが、才能の都市伝説も問題のひとつだ。我々の業界では、才能の都市伝説は、優秀なクソ野郎の都市伝説としても存在する。つまりこうだ。世の中には10倍以上の生産力を発揮するプログラマーがいて、仕事があまりにも素晴らしいので、その挙動が難ありだとしても、周りはなんとか協調してやらねばならないというものだ。現実には、正規分布を考えれば、その手の人間は、それほど例外的に優れているものでもない。しかし、もし仮にそういう10倍プログラマーがいて許容するとしても、そいつ一人を維持するために何人のプログラマーを拒否しなければならないというのか。

[スライド:優秀なクソ野郎というタイトルでLinusがnVidiaに対して中指を突き立てている画像を表示、聴衆は大笑い]

10倍プログラマーはどういう見た目をしているのか。

さて、現実には能力は正規分布するのに、プログラマーは神かザコのどちらかに分類されるという考えには、危険なバイアスが待ち構えている。さて、10倍プログラマーはどのような見た目をしているのかということを考えてもらいたい。

[スライド: 映画ソーシャルネットワークで、Mark Zuckerbergを演じたJesse Eisenbergの写真]

我々はこのような見た目を思い浮かべるであろう。これはMark Zuckerbergだ。若い白人の男だ。なぜならメディアで目にするのはそういう人間だからだ。ネタバレしないでもらいたい[聴衆から笑い声]。だがこれはMark Zuckerbergではない。先ほどから笑っている人もいるように、これはMark Zuckerbergを演じたJesse Eisenbergだ。大手映画会社で、その内容は・・・若い白人の男がIT起業するという話だ。

[スライド: Sutarday Night LiveというアメリカNBCのコメディバラエティ番組のキャストで、Mark Zuckerbergを演じたJesse Eisenbergを茶化して演じたAndy Sambergの画像 ]

これがMark Zuckerbergだ。[聴衆から笑い声]。いや、これはMark Zuckerbergではない。これはAndy Sambergで、Jesse Eisenbergを演じていて、その演じられたJesse EisenbergはMark Zuckerbergを演じている。

[スライド: Mark Zuckerbergの写真]

これが、たぶんMark Zuckerbergだ。

[スライド: 三者の顔]

とにかく、ここで言いたいことは、若い白人の男という典型例は極めて一般的で、3人とも同じ人物を演じているというわけだ。どれが本物だっけ? とにかく、この3人に似通わないような人間は本物のプログラマーには見えないので、本物のプログラマーとはみなされない。自分の知るこの業界の女性のほとんどは、プログラマーだとは思われなかったという話を持っている。このPyCon、今年のいまここで、複数の女が、どの男と来たかとたずねられたと聞いた。ここに来る理由は、配偶者の男がプログラマーだったからというわけだ。もし、男だったならば、そういう質問はされただろうか。

逆に、ステージに上がった自分は、そういう典型例に似ている。そこで、聴衆は自分を本物のプログラマーだと推定する。このような推定は、かなりの数の人間をこの業界から遠ざける。

National Center for Women & Information Technologyによれば、コンピューターサイエンス科の学位を得た女の半数は、雇用にその学位を使っていないとのことだ。40%の女は10年以内にこの業界を去る。男はたったの17%だ。女性の半数以上はキャリアの途中で業界から去るわけだ。

もちろん、性差別だけが原因ではないだろうが、何十年もの経験ある女が、ド素人だとみなされるのは極めて不快だろう。この差別を克服するには大変な努力が必要だ。我々がプログラマーというもの、プログラミング能力というものについて考えなおさなければ、解決は望めない。

ランナーには様々な人がいる。短距離走者、長距離走者、マラソン走者などなど。体格や性別や年齢や人種も様々だ。皆、成功の条件が違うし、その条件にあった成功を収めることができる。この業界にも、そのような考え方が必要だ。

何年も前に、Lynn RootとPyConで話した内容が、この発表の元ネタになっている。Rootはプログラマーで、PyLadiesのサンフランシスコ支社の創始者で、Python Software財団の委員で、このコミュニティに長くいるものだ。PyLadiesは、その当時はまだ新しいもので、その集団の能力や意欲には期待すべきものがあった。その時自分はRootに、「そういう強者の女プログラマーが出てきたのはよいことだ」などと言った。するとRootは、「まあ、そうだけど、本当に成功するためには、大量の平均的な女プログラマーが必要だ」と答えた。

我々の言う才能の都市伝説は、参入のハードルを不可能なほどに上げてしまう。この都市伝説を元に考えれば、今ここに我々がいるという事自体が驚きだ[訳注: ほとんど者はその資格がないはずのため]。この都市伝説は捨て去る必要がある。コミュニティは、「平均は実際とてもよいことだ」という考えを持つ必要がある。さて、私はありきたりのプログラマーで、皆にもそうなってほしいし、普通にやることをこなそうじゃないか。

人間のたいていの能力の評価値をグラフに描くと正規分布するのでベル曲線を描く。ザコと神しかいない、プログラミングには生まれながらの天性の才能が必要だという都市伝説に従えば、正規分布していない。すごくできない奴とすごくできる奴ばかりで中間がほとんどいないという、バイモーダル曲線を描く。とはいえ、前に紹介したふたこぶラクダの論文は、現実の評価結果がバイモーダル曲線だったと報告している。

本の虫: 60%の人間はプログラミングの素質がない

ドワンゴ広告

ドワンゴはベル曲線の良い方の端にいるC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-04

constexprで非定数式の状態を保持

Non-constant constant-expressions in C++

なんと、C++のconstexpr関数を呼び出すたびに戻り値を変える方法があるという。つまり、以下のstatic_assertが引っかかるコードだ。

int main ()
{
    constexpr int a = f ();
    constexpr int b = f ();

    static_assert (a != b, "fail");
}

なんと、constexpr関数は状態を保持できる計算能力を備えているというのだ。

fはconstexpr関数である。

読んでみたところ、要するにこうだ。

noexcept演算子はオペランドが定数式かどうかを判別するのに使える。

// exprが定数式であればtrue
constexpr bool b = noexcept( expr ) ;

未定義の関数は定数式ではない。

// 宣言
constexpr int f( int ) ;

void check1( )
{
    noexcept( f( 0 ) ) ; // false
}

// 定義
constexpr int f( int ) { return 0 ; }

void check2( )
{
    noexcept( f(0) ) ; // true
}

friend宣言は関数の定義を書くことができる。

constexpr int f( int ) ;

struct S
{
    friend constexpr int f( int ) { return 0 ; }
} ;

friend宣言で定義した関数はADL経由でしか呼び出せないが、それは問題ではない。friend宣言が現れて初めてconstexpr関数fが定義され、呼び出しが定数式になるということだ。

もし、frined宣言をするクラスをテンプレートにしたらどうなるだろうか。テンプレートが実体化した時だけ、関数fは定義されるということになる。

// 定義されたかどうかの1bitのフラグ
constexpr int flag (int);

// 関数を定義することでフラグ書き込む
template<class Tag>
struct writer {
  friend constexpr int flag (Tag) {
    return 0;
  }
};

// writerの実体化を遅延させるためのラッパー
template<bool B, class Tag = int>
struct dependent_writer : writer<Tag> { };

// 実際の使い方
// 一回目に呼ばれた時点ではまだwriterが実体化しておらず、
// flag<int>は定義されていない
// 二度目以降に定義されるのでtrueとなる
template<
  bool B = noexcept (flag (0)),
  int    =   sizeof (dependent_writer<B>)
>
constexpr int f () {
  return B;
}
int main () {
  constexpr int a = f ();
  constexpr int b = f ();

  static_assert (a != b, "fail");
}

あとはこれを並べれば、何ビットでも状態が保持できる。

ドワンゴ広告

GWは長い。今週は休みだが、有給を申請し忘れたので木金は出社する。

ドワンゴは本物のC++プログラマーを募集しているようですが、休暇中なのでa要素を使ってリンクしません。

<a href="http://info.dwango.co.jp/recruit/">採用情報|株式会社ドワンゴ</a>

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2015-05-01

婚約者が作って欲しい料理:オムライス

婚約者がオムライスを作って欲しいと言ったので、作ってみた。

オムライスを作るにあたって問題がある。私はケチャップが嫌いだということだ。ケチャップは安直な味がする。スパゲティにケチャップをかけるさもしい異端者になりたくはないものだ。私はケチャップと味覇を封印することを空飛ぶスパゲティモンスター様に誓っている。ラーメン。

色々と調べた結果、ケチャップではなく、ホールトマト缶で作ることに決めた。

作り方

鶏の胸肉を細かく刻んでオリーブオイルと塩とハーブ(コショウ、バジル、オレガノ)を入れたジップロックに入れておく。

タマネギ、人参、ピーマンをできるだけ細かくみじん切りする。

フライパンで肉と野菜を炒める。

ホールトマトを入れて、コンソメと塩とハーブをいれて煮込む。

ご飯を入れて炒める。

卵に牛乳を少しだけいれてよく混ぜる。

フライパンを熱して、多めにバターを入れて、溶き卵を入れる。火は10秒ほどで消す。

卵の片側にトマトチキンライスを置き、真ん中からふたつに折るようにしてくるむ。

フライパンの底側の方が見た目がよいので、皿に移すときにひっくり返す。

こうして、ケチャップを使わないオムライスが完成した。

なお残念なことに、婚約者は冒涜的にもケチャップで上に絵を描いてしまった。