2017-02-22

アンチウイルスソフトウェアの利用者は過失が問われるべき

Google and Mozilla's message to AV and security firms: Stop trashing HTTPS | ZDNet

GoogleとMozillaの調査によれば、世の中のほとんどのアンチウイルスソフトウェアは通信内容を傍受するためにブラウザーに対してMITMを仕掛けている。

MITM(Man In The Middle)とはTLS(HTTPS)接続の証明と暗号を無効化するための方法で、中間者攻撃とも呼ばれる。

HTTPSにはふたつの役割がある。通信内容の暗号化と、通信相手と通信内容の証明だ。

通信内容が暗号化されていない場合、秘密の情報(クレジットカード番号など)が途中で通信を傍受している悪意ある攻撃者に筒抜けになってしまう。それを防ぐために通信を暗号化したいところだが、それだけでは不十分だ。

まず、通信相手が本人である保証がないし、通信内容は本人のものである保証もない。通信経路の途中で傍受できるということは、当然書き換えもできるはずだ。

通信相手が本人であり、通信内容が途中で改変されていないことを示すための証明方法がある。これで問題は全て解決したかというと、そうでもない。

通信をしたい二者の間に中間者が挟まって、二者のどちらにもHTTPSで使われている証明を行うことで、どちらとも相手と通信しているように錯覚させることができる。これを中間者(Man in the middle)攻撃という。

ただし、この中間者攻撃というのは、通常はうまくいかない。何故ならば、中間者の証明書を信頼しなければならないからだ。

ところで、アンチウイルスソフトウェアは、コンピューターの中で管理者権限で動くソフトウェアである。アンチウイルスソフトウェアは自分の証明書を信頼させることができる権限を持っている。すると、アンチウイルスソフトウェアはMITMができる。

なぜアンチウイルスソフトウェアがMITMをするかというと、通信内容を傍受して、悪意あるソフトウェアが紛れ込んでいないかを監視するためだ。そのため、アンチウイルスソフトウェアの中間者攻撃の意図に悪意はない。しかし、その実装は雑である。

多くのアンチウイルスソフトウェアは、中間者攻撃の実装に不具合や脆弱性を抱えている。その結果、ユーザーのセキュリティが弱められる。

さらに、アンチウイルスソフトウェアは管理者権限で動作し、カーネルも含む他のソフトウェアにコード注入する。これも脆弱性をうみだす。

ましてや、現代の悪意あるソフトウェアは単にパターンマッチやヒューリスティックによる検出で対応しきれない。

アンチウイルスソフトウェアを実行することはセキュリティを高める事にはならず、逆に下げることになる。したがって、アンチウイルスソフトウェアを使った結果セキュリティを弱め、コンピューターに悪意あるコードの実行を許し、他人に被害を与えた場合、アンチウイルスソフトウェアを実行している人間は過失が問われるべきである。

アンチウイルスソフトウェアは詐欺なので直ちに使用を中止すべきである。

2017-02-15

C++標準化委員会の文書: 2017-02のまとめ

2017-02 Pre-Kona mailingsが公開されている。

#MAILING2017-0: ISO/IEC JTC1/SC22/WG21 - Papers 2016

参考書の執筆に注力したいため、この記事では改訂版の提案のうち興味深い文書を取り上げる。

[PDF] N4637: Working Draft, Extensions to C++ for Modules

モジュールのドラフト

[PDF] N4640: Working Draft, Standard for Programming Language C++

現在のドラフト。変更点はeditorial上のものにとどまる。valarrayの文面が最新の用語を使って書き直された。

[PDF] P0045R1:Qualified std::function signatures

constなstd::functionにconstではない関数オブジェクトを代入するとconstなオブジェクトが変更できてしまう問題がある。

struct delay_buffer {
int saved = 42;
int operator () ( int i ) { return std::exchange( saved, i ); }
};
// Small object optimization — no heap allocation.
const std::function< int( int ) > f = delay_buffer{};
assert ( f( 1 ) == 42 );
assert ( f( 5 ) == 1 );

この問題への対処として、std::functionのテンプレート実引数にconst修飾を書けるようになる。既存のconstなstd::functionは[[deprecated]]を利用してdeprecated扱いであることを明示した上でconst_castを使う

std::function< void() > const f = []() mutable {} ;
f() ; // [[deprecated]]警告付きで動作する

// コンパイルエラー
std::function< void () const > const g = []() mutable {} ;

これは便利だ。

[PDF] P0052R3: Generic Scope Guard and RAII Wrapper for the Standard Library

汎用RAIIラッパーライブラリ、だいぶ仕様が固まってきたので、これ以上大きな変更はなさそうだ。

[PDF] P0059R3: A proposal to add a ring span to the standard library

固定長リングバッファーを実装するring_spanの提案。ring_spanはストレージを管理せず、コンストラクターでcontiguous iteratorで渡されたストレージを使う。

この提案では、ring_spanからイテレーターを得るbegin/endが削除された。ring_spanはストレージを所有しないため、イテレーターを提供するのは好ましくないとのことだ。

[PDF] P0082R2: For Loop Exit Strategies (Revision 3)

繰り返し文を条件式がfalseになって抜けたのか、break文で抜けたのかによって、繰り返し文を抜けた後で条件分岐したいことがある。しかし、C++ではそれを直接表現する方法がないので、極めて冗長かつ非効率的な方法で書かなければならない。

bool did_break = false ;

for ( ... )
{
    if ( ... )
    {
        did_break = true ;
        break ;
    }
}

if ( did_break )
    ... ;
else
    ... ;

この提案はC++に繰り返し文のあとにbreakで抜けたかどうかで条件分岐する文法を追加するものだ。この改訂版では、既存のキーワードを使い回すのではなく、新しいキーワードを追加する設計に改められた。


for ( int i = 0  ; is_completed(i) ; ++i )
{
    if ( is_error() )
        break ;
}
on_complete
    do_normal_things() ;
on_break 
    do_abnormal_things() ;

キーワードはon_complete/on_breakだ。

だいぶわかりやすくなった。

P0091R4: Template argument deduction for class templates (Rev. 7)

deduction guideをdelete定義できるようにする提案。まあ、必要になる場合もあるかもしれない。

P0103R1: Overflow-Detecting and Double-Wide Arithmetic Operations

オーバーフローが検出できる整数の四則演算と左シフト演算のライブラリの提案。オーバーフローの有無がbool型の戻り値で、演算結果が実引数に渡したポインター経由で得られる関数と、ひとつの型で返す関数がある


template <typename T> bool overflow_add( T* result, T a, T b );

1つの型で返す関数の方は、split_lowerとsplit_upperで上位下位に分けることができる。

P0104R1: Multi-Word Integer Operations and Types

固定長整数ライブラリの提案

template<int words> multi_int;
template<int words> multi_uint;

演算子がオーバーロードされていて普通に組み込みの整数型のように使える。問題は、現在の文面では、1ワードが何バイトなのか実装依存だということだ。

P0105R1: Rounding and Overflow in C++

浮動小数点数の丸め方とオーバーフローの挙動を指定して演算できるライブラリの提案。

P0237R5: Wording for fundamental bit manipulation utilities

整数型をビットのコンテナーとみなしてビットへのイテレーターなどのアクセス方法を提供するアダプターライブラリの提供。おそらく規格に入る。

[PDF] P0267R3: A Proposal to Add 2D Graphics Rendering and Display to C++,

2Dグラフィックライブラリのドラフト。よくもここまでまとめたものだ。文字列描画機能はないようだ。

P0275R1: A Proposal to add Classes and Functions Required for Dynamic Library Load

shared libraryやWindowsのDLLのように、動的に関数やクラスの実装をプログラムにロードして使えるライブラリの提案。果たして標準化できるのだろうか。

P0316R0: allocate_unique and allocator_delete

指定したアロケーターでストレージを確保してunique_ptrを構築するライブラリallocate_uniqueの提案。すでにshared_ptrに対するallocate_sharedはあるので、その補完。

[PDF] P0352R1: Smart References through Delegation (2nd revision)

operator .ではなく派生を使ってスマートリファレンスを実装できる機能の提案。operator .よりよほどマシな文法と意味だ。こちらが採用されるべきだ。

P0355R2: Extending <chrono> to Calendars and Time Zones

<chrono>を日付に対応させる提案。これでようやくCライブラリを使わずにC++で型安全に日付が扱えるようになる。



int main()
{
    using namespace std::chrono_literals;
    auto date = 2016y/may/29;
    cout << date << "\n";
    // 2016-05-29
}

便利だ。

[PDF] P0447R1: Introduction of std::colony to the standard library

flat_mapと同じくらい注目している新しいコンテナーの提案、colony。

colonyはvectorのような連続したストレージ上に構築される要素に順番の概念があるシーケンスコンテナーだが、中間要素への削除が定数時間ですむ。

どのように実装しているかというと、要素の数だけのビットマップを持っていて、それぞれの要素が有効かどうかの情報をビットマップで保持している。これにより、要素をずらす処理が必要なくなる。そして、中間への挿入も無効な要素がたまたまあれば定数時間で終わる。

これはほしい。

P0479R1: Attributes for Likely and Unlikely Statements

分岐先が実行されると期待できる場合と期待できない場合にその情報をコード中に記述できる属性、[[likely]]と[[unlikely]]の提案。


if ( is_unexpected_error() ) [[unlikely]]
{
    // まず発生しないエラーの処理
}

while( is_program_exit() )
[[likely]]{
// 終了することがほとんどないプログラムの処理
}

深いパイプラインを持つ近代的なプロセッサーでは、分岐予測を外した時のペナルティは大きい。もし、プログラム中のある分岐先がほとんど確実に実行される、あるいは実行されないことがコンパイル時にわかっている場合、プロセッサーによっては分岐予測にヒントを与える命令を使うことによって分岐命令のパフォーマンスを上げることができる。そのような情報をソースコードに付加するための属性。

if, while, do while, for, range-based forに記述できる。

既存の提案の改訂版を片付けた。あとは新しい提案のうち興味のあるものだけをさっと解説して参考書の執筆に戻りたい。

ドワンゴ広告

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

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

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

2017-02-09

高度に発展した特許業界はヤクザと見分けがつかない

Azure IP Advantage – intellectual property protection | Microsoft Azure

Microsoft AzureがAzure IP Advantageなるサービスを始めた。

特許ゴロによる大量のゴミ特許を抱えたうえでどれかに抵触しているだろうと当たりをつけて手当たりしだいに革新的な製品、サービスを提供しているものに訴訟を仕掛ける商売はいい儲けになっている。

そのような特許ゴロ訴訟に対抗する手段としては、こちらでも大量のゴミ特許を抱えておき、特許侵害を訴えられたら相手も自分のゴミ特許のどれかに抵触しているだろうとあたりとつけて特許侵害で逆提訴するというものだ。訴訟は技術を全くわかっていない弁護士と裁判官が何年も言葉遊びを弄した挙句、和解に終わるという泥仕合を繰り広げる。

といっても、そんなことができるのは大量の特許を保有できる資本力のある世界的に有名な大企業だけであり、大多数の実際に世界に技術革新を起こしている中小企業としては、訴訟の費用と特許利用料を天秤にかけると、訴訟をしないほうが安上がりになることが期待できるので、特許利用料を支払ったほうがマシという納得できない選択が最善の状態になってしまう。

今回Microsoftが始めた商売というのは、特許ゴロ訴訟を起こされた場合、Microsoftが大量に保有するパテント・プールをもって特許ゴロを叩くというものだ。

しかしこれは、何か見覚えのある商売のように思えてならない。

世の中にはヤクザと呼ばれる圧倒的な暴力を保有した複数の団体がいる。ヤクザは暴力を行使してあなたから金を巻き上げていく。あなたはヤクザの一つにみかじめ料を支払うことによって、他のヤクザの暴力に暴力で対抗して守ってもらう。

ヤクザを特許ゴロに、暴力を特許に置き換えるとどうだろうか。不思議なほどの一致を見るではないか。これでは特許ゴロとヤクザの見分けがつかない。ヤクザのような見た目でヤクザのように鳴くならばそれはヤクザである。

そして今回のタイトルに繋がる。「高度に発展した特許業界はヤクザと見分けがつかない」

ヤクザのシノギを作り出すだけで技術革新を阻害する特許制度は廃止すべきである。

2017-02-07

「目撃!ドキュンはドキュンをバカにし過ぎでひどくない」と妻は言った

「目撃!ドキュンはドキュンをバカにしすぎでひどくない?」と妻は言った。

僕はその言葉の解釈に数秒悩んだあと、おもわずこみ上げる笑いこらえるのに苦労した。

それは午前二時の真夜中のことであった。僕と妻は非常に腹を空かせていたが、あいにくと冷蔵庫にはごぼうと生姜とにんにくしかなかった。さすがの僕でも、ごぼうの生姜とにんにくの炒め物などという何の腹の足しにならない料理を妻に提案することはしなかった。我々が村上春樹の信奉者であれば、ここでパン屋を襲撃しに行かなければならないところだが、幸い我々は村上春樹がそれほど好きではなかった。

家のすぐ近くにはすき家があるが、我々夫婦はすき家に行くのは最終手段であると考えていた。というのも、夜中に寝巻き姿で夫婦揃ってすき家に行くのは、いかにもDQNのやることであり、文化的に生きる我々にははばかられる種類の行いであるように思われたからだ。

しかし腹は空いた。食べるものが家にない。コンビニにめぼしい物も売っていない。残念ながら、今夜は最終手段としてDQNに成り下がる必要がある。

我々夫婦は最低限の防寒具を着て、DQNのようにすき家に向かった。

「何、DQNの語源を知らないのかい?」

妻はDQNという言葉を知っている上によく使うにもかかわらず、DQNの語源を知らなかった。DQNとはドキュンと読み、かつての2ちゃんねるで使われていたネットスラングが定着した言葉である。今はDQNと書くことが多いが、当時はドキュンとかドキュソと書くほうが一般的だったはずだ。そもそもの語源は、昔「目撃!ドキュン」というテレビ番組があり、いかにも教養のない家庭環境に問題を抱えている下層階級の親子を放送していたので、そのような低俗な人間を指す言葉としてDQNが使われるようになったのであった。

「・・・そういうわけで、ドキュンは2ちゃんねるで使われていたスラングだけれど、もともとは目撃!ドキュンというテレビ番組が・・・」

「なにその番組名? ドキュンをバカにしすぎでひどくない?」と妻は言った。

僕はすき家の中で、おもわずこみ上げる笑いこらえるのに苦労した。

「それは逆だよ。目撃ドキュンという番組名が作られたとき、まだドキュンはオノマトペとしての意味しか持っていなかったんだ。」

言葉の変遷とは不思議なものだ。語源によって新たに創りだされた言葉の影響で語源の意味が変わってしまう。

2017-01-31

GDBがC++コード注入をサポート

C++ Support Added To GCC's libcc1, Benefiting GDB - Phoronix

C++ support in libcc1: A comprehensive update – RHD Blog

最新のGCC 7では、GDBがC++のコード注入をサポートするようになった。

GDBは、デバッグ中のプログラムにC言語のコードをその場でコンパイルしてコード注入して実行する機能を持っている。これにC++が対応した。

この機能はlibcc1.soを通じてGDBとGCCが強調動作することによって実現されている機能だ。

CとC++は似ている言語ではあるが、名前空間など名前検索のルールが異なるので、シンボル名を探すにもGDBにC++の名前検索を実装しなければならない。また、テンプレートにも特別な対応が必要だ。

ドワンゴ広告

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

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

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

2017-01-30

xkcdで最近面白かった話

xkcd: Wifi

縦軸:来客がWiFiに接続できる確率

横軸:来客の技術力

グラフ中の表記、左から:

技術力低い:WiFi設定が見つけられない

技術力普通:使える

技術力高い:「ファームウェア」に原因がある

titleテキスト:右端を超えると正しく使える。ただし、その理由には「ファームウェア」が関係している"

筆者も今使っているラップトップの一台のWiFiの調子がUbuntuで悪くて苦労している。

xkcd: 職場チャット

2004年:うちの部署はIRCでやり取りしている

2010年:うちの部署はほぼSkypeを使っているが、一部の同僚はまだIRCを使っている。

2017年:ほぼ全員がSlackに移行した。しかし3人だけIRCをやめるのを拒否してIRCゲートウェイ経由で接続している。

2051年:宇宙シンギュラリティによりすべての知的意識は統合された。ただし一人だけIRCクライアント経由で参加している奴がいる。
「俺は自分の好きなようにやりたいんだ。わかるだろ?」
やれやれ

titleテキスト: 2078年:奴はようやくscreenとirssiからtmuxとweechatに移行しやがった。

たしかにこの2017年では職場内のチャットはSlackが独占した感がある。

もっと訳そうと思ったが飽きたのでこの辺で。

2017-01-24

GCCの実験的なfilesystemを使う方法

C++17には<filesystem>が追加される。GCCは実験的な実装として<experimental/filesystem>を実装している。

これを使えば、例えば以下のようにディレクトリを列挙できる。

#include <experimental/filesystem>

namespace fs = std::experimental::filesystem ;

int main()
{
    fs::directory_iterator iter("/usr/bin"), end ;
    std::copy( iter, end, std::ostream_iterator<fs::path>(std::cout, "\n") ) ;
}

GCCのfilesystemは、実験的な実装であるので、ヘッダーファイルが<experimental/filesystem>であることに加え、デフォルトではライブラリがリンクされない。

GCCのfilesystemを使うにはライブラリとして、libstdc++fs.aとリンクしなければならない。これは、gccに-lstdc++fsオプションを渡すとよい。また、libstdc++fsにshared library版はないので、安全のためにコマンドラインオプションの最後に書くべきだ。


g++ -std=c++1z その他のオプション... -lstdc++fs

libstdc++fsについては、極めてわかりにくい場所に申し訳程度にドキュメントがある。

Linking

ドワンゴ広告

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

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

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

2017-01-22

最も日本人を多く殺す職について考察した結果、反医療主義という結論に至った

概要:この記事は最も多くの日本人を殺す職業について考察したうえで、最終的に意外だが確実に多くの日本人を殺している職業を特定したので書いた。結論を書くと反医療主義なのだが、考察の過程をたどっていこう。

今週の土日は何も予定がなく、かつ面白い本もPCゲームも見当たらないため、非常に暇である。そこで、最近執筆が滞っているブログのリハビリを兼ねて、何の意味もない文章を書いてみようと思う。お題はこれだ。

人を殺せる職につきたい

間接的に多くの日本人を殺せる職につきたい

絶望的に人望がないので政治家や起業家は難しい

スキルはITエンジニアの経験のみ

このクソみたいな人生の鬱憤を晴らすためだけに間接的に日本人を大量にぶち殺したい

どうすればいいのだろうか

なるほど、まず考察する内容を整理しよう。

  • この匿名ダイアリーの筆者を仮に増田とする
  • 増田は人を殺せる職につきたい
  • 人とは日本人である
  • 政治家と起業家以外の職である
  • 殺す人数は多くしたい

まず、「殺す」の意味を考えてみる。お題の文章を解釈すると、増田が自ら刃物や銃といった武器を使って人を殺す必要はない。間接的な殺人でよいのだという。すると増田は他人に殺人を命令する立場でもよいし、増田の意思決定の結果人が死ぬという状況でもよい。

死刑執行人はそれほど人を殺していない。日本で年間に行われる死刑執行の数は極めて少ない。大抵の年は0かひと桁であり、まれにふた桁の執行数があってニュースになるぐらいだ。

人を殺す機会のある職業と言われて警察、自衛隊、海上保安官を思い浮かべる読者もいるかもしれないが、これらの職業はあまり人を殺していない。自衛隊は国内の治安維持に出動した実績はまだなく、せいぜい訓練中に自衛隊員同士で殺しあったとか、事故の結果人を殺したことはあるとしても、あまりにも殺人数が少なすぎる。警察とて、治安維持に出動して暴徒と殴りあったり、犯人と交戦するような警官はほんのわずかであり、大多数の警官は窓口で非暴力的な一般市民と応対したりデスクワークをしたりしている。あとは「間接的」という言葉をどこまで拡大解釈するかの話でしかない。殺人をした警官を管理する立場にあるものは間接的に殺人をしたといえるだろうか。日本人を殺した警官の給与計算に関わっていた会計部署の警官も間接的に人を殺したと言えるのだろうか。すると、警察庁長官は警官による殺人の全件に関与したといえるのだろうか。この論法が行き着く先は内閣総理大臣が最も多くの殺人をしているということだ。いや、国家の象徴であり内閣に承認を与える天皇は内閣総理大臣を含む国内のすべての殺人を間接的に行っていると考えることはできるだろうか。しかし、現状では天皇は国民の総意と内閣の決定に従わなければならず自分の意志を表明することができない。それに、増田はおそらく天皇の職を得ることはできない。

間接的という言葉はいくらでも拡大解釈できる。

例えば、ラーメンは栄養のバランスが悪く、脂肪と塩分が過剰であり、健康に悪い。健康を損ねると人は死ぬ。すると、ラーメンの店主は殺人に貢献したことになるのだろうか。問題が塩にあるとすれば、塩の製造や販売を行う職業は殺人に関わっているのだろうか。

間接的をここまで拡大解釈していいとすると、結局日本人が最も摂取しているビールの販売元はどこか、タバコ農家は誰かということになってしまう。本来麻薬であり違法となるべき健康を害するたばこを製造、販売しているJTは極めて多数の日本人の殺害に貢献している。するとJTの多数の労働者を管理する人事部に職を得るべきだろうか。

しかし一般に、空腹の人間にラーメンをおごったり、アルコール分解能力がありビールを飲みたがっている車両を運転する予定のない人間に一杯のビールをおごったり、健康を損ないたがっている喫煙バカにタバコを一本差し出したりすることは殺人とみなされていない。

間接的な殺人を考えると、健康保険の範囲内の治療を定める職は、その意思決定によって大勢の日本人の生死を左右するだろう。政治家も間接的な影響力が大きい。しかし、これらの職は増田がつきにくい職業である。それに、これらの職業はできるだけ殺人を減らす目的があるので、判断を誤って殺人数が増えたとしても、全体的には殺人を減らす方向に貢献してしまう。

避妊具は妊娠を防ぐことによって本来生まれるべきであった人間を生まれさせないため、殺人とみなせるのではないか。すると増田は日本で最も売れている避妊具製造メーカーに勤務すべきである。しかしそのような間接的な可能性の殺人を考えるのであれば、避妊具が存在しないことによる間接的な殺人数も考えなければならない。

もし避妊具が存在しなければ、多くの望まれない子が生まれ、貧困で劣悪な環境で育てられることになる。避妊具の存在によって、そのような子供が成長して、人を殺す可能性が消されるので、避妊具は殺人件数の減少に貢献している。避妊具による未来に存在したはずの可能性の殺人を考えるのであれば、未来に存在したはずの殺人減少を差し引かなければならない。

事実、アメリカでは中絶が合法化されてからしばらくして、殺人件数が大幅に下がっている。

多くの職は、日本人の死亡に貢献している以上に、日本人の死亡を防ぐことにも貢献してしまっているのだ。

例えば、餅は毎年100人ほどの日本人を救急搬送しているが、餅を食べることは飢え死にを防ぐので日本人を生かしている。それに、窒息死の原因は餅ではなくおかゆのほうが多い。というのも、窒息死する日本人の多くは咀嚼力の著しく低下した人間であり、咀嚼力の低下した人間は日常的にお粥を食べているからだ。

そういう意味で、車も日本人を殺していない。交通事故では年間4000人ぐらいの日本人が死んでいるが、もし車がない場合、日本の物流は止まり、現在の人口を支えることができず、より多くの日本人が死ぬ。したがって、車の製造や販売の職業についた場合、殺した日本人の数より助けた日本人の数が大幅に上回ってしまう。

では非合法な職はどうか。この際、収入さえ発生していれば職業と認めてもいいだろう。例えば暴力団はどうか。残念ながら暴力団はあまり人を殺していない。というのも、日本における暴力団構成員が殺人、殺人未遂の容疑で検挙された件数は一年間にせいぜい200から300件程度なのだ。容疑者ですら3桁しかない。もちろん、検挙されていない殺人もあるだろうが、この程度の数では話にならない。コンビニ店員として酒と煙草と避妊具を売っていたほうがまだいくらか日本人の殺人に貢献できる。

とはいえ、日本全体の一年の統計上の殺人件数が1000件程度であることを考えると、暴力団による殺人は割合が高い。警察が認知する殺人件数に間接的に関わることを目的とするのであれば、やはり暴力団には所属しているべきだろう。しかし、警察に逮捕されて、勾留、懲役、禁錮の扱いを受けてしまうと、その最中はさすがに殺人に間接的にでもあれ関与したとはみなせないだろう。

警察に逮捕されずに暴力団との関係を続けて間接的に殺人に関与するには、増田は暴力団に脅されてやむを得ず金品をゆすり取られ続けるとか、暴力団の関与する高利貸しから金を借りて利子を支払うなどすればいいのではないか。こうすれば、増田は被害者であるので警察に逮捕されることはない。増田の提供した金銭は暴力団の利益となり、間接的に殺人にも使われる。しかし、これは職業ではない。しかもこのような状況は極めてクソであり人生の鬱憤を晴らすどころかますます鬱憤をためるだけだろう。

ここまで、具体的な統計を出さずに筆者の頭の中だけで考えていた。そのようなデータに基づかない考察を離れて、具体的な死因を見ていこう。

厚生労働省:死因順位(第5位まで)別にみた年齢階級・性別死亡数・死亡率(人口10万対)・構成割合

日本では、1年間に120万人ほどの日本人が死んでいる。死因の上位に来る理由を生じさせる原因となる職業につけば、最も効率よく日本人が殺せるだろう。

まず、0歳から4歳までの死因の第一位は、「先天奇形、変形、及び染色体異常」である。第二位以降もほとんどが病気によるものだ。

その後、10代の頃は病気が多い。

20代から30台になると自殺が死因のトップになる。

その後の死因のトップは癌だ。

なるほど、このことから、日本人の死亡に最も貢献できる職業が判明した。

反医療主義者である。

書籍や新聞やテレビやインターネットといった大衆に届く情報媒体を使い、反医療主義を煽って金を儲ける職業につけばよい。

乳幼児の死亡率を上昇させるためにワクチン摂取に反対する。がん死亡率を高めるために科学に基づかない、臨床試験で効果も認められていない代替医療を推奨する。

ホメオパシー、カイロプラクティック、菜食主義、反ワクチン、宗教、占い、何らかの植物やキノコを摂取すると癌が治るとの主張、タバコ、アルコール、これらの反医療主義を煽る本を書いて、テレビに出てさも効果があるかのように吹聴する職業。このような職業は実際に存在している上に、うまくやれば稼ぎもよい。

しかも、現代日本では、これらの行為を行うほとんどの職業は犯罪者とみなされていない。最悪の場合で薬事法違反程度の軽い罪だ。というのも、癌の治療を拒否するのは拒否した本人の責任であるし、抗癌剤の重い副作用について解説するのは違法ではないからだ。あとは薬事法に触れないように気をつければよいだけだ。増田は日本人さえ多く殺すことができれば、逮捕されたり懲役を受けることにはむとんちゃくかもしれないが、懲役を受けるとそれだけ反医療主義を煽ることができなくなる。

考察を始めた当初は、とてもくだらない記事になることを危惧したが、どうやらなかなか啓蒙的な結論に達することができた。この記事の教訓としては、反医療主義は危険だということだ。

2017-01-21

HoloLensを体験したが10年早かった

MicrosoftのHoloLensが日本でも入手可能になったようだ。さっそく入手した人が身近にいたので体験させてもらったが、結論をいうと、10年早かった。

HoloLensは、一見するとバカバカしいまでに巨大で無骨なサングラスだ。そのレンズに投影することにより、あたかも空間上に物体があるかのように錯覚させることができる。空間上のある場所にウインドウや3Dモデルを設置すると、その場所に固定される。HoloLens装着者は空間に固定された表示物を好きな距離、好きな角度から見ているように錯覚する。

HoloLensがどのように空間を把握しているかというと、主に赤外線による深度センサーを用いて回りの深度を把握しているようだ。それにしても装着者の動きに追随する性能がすばらしく、ズレを一切感じさせない。

HoloLens風のコンピューターの性能が上がれば、通常のコンピューターの補助的に使うのはありではないかと思う。つまり、椅子に座って通常のコンピューターを操作している中で、HoloLensも装着して、周囲に作業中に参照するひつようのあるドキュメントを貼り付けておく。回りを見回すとドキュメントを読むことができる。これの何がいいかというと、物理的なディスプレイがいらないということだ。物理的なディスプレイは物理的な空間を専有する。しかもコンピューターにはディスプレイの枚数分、物理的な出力ポートが必要だ。HoloLens風のディスプレイであれば、これがいらない。

ホロレンズの操作はハンドジェスチャーで行う。しかし、ジェスチャーを正しく認識させるのはなかなか大変だった。それに、VRでさんざん学んだことだが、人間はよほど鍛えていない限り、腕を心臓より高く上げたままの姿勢を長時間続けることはできない生き物である。これは大変に深刻な問題で、筆者は数十年後、VRが普及して普通のコンピューターのディスプレイがVRになった未来の採用面接では、エリートの求職者は体育大体操部出身のマッチョで、面接ではその鍛え上げられた肉体美を披露しつつ、「はい、私はこのようによく体を鍛えているのでVR作業を3時間連続でこなすことができますフンヌー」などと自己アピールをしているのではないかと予想している。

結論から言うと、ハンドジェスチャーは面倒で疲れる。Bluetoothが付いているそうなので、キーボードやマウスを接続することはできるのではないか。将来的には、HTC Viveのように物理的な入力装置を使う方向に進むのではないか。

HoloLensの残念な点としては視野が極めて小さいということだ。目の前に腕を伸ばして両手で長方形を作った程度の視野しかない。しかも、頭に固定したHoloLensがずれるとその視野の長方形が移動してしまう。

HoloLensを体験していると、かつてOculus RiftのDK1を体験した時のことを思い出す。荒削りではあるが未来を感じさせる先進的な技術だ。Oculus Rift DK1は、この2017年の標準では、もはや犬も食わないほどのガラクタに成り下がってしまった。かつ、Oculus VR社の方針は邪悪かつ排他的であり、HTC Viveに性能面でも劣っている負け犬と成り下がってしまった。

もうひとつ思い出すのは、Microsoftは一時期タブレットに注力していたということだ。まだ実用的なタブレットが夢物語の時代に、極めて無骨な弁当箱のような厚さのタブレットを開発していた。結果として、Microsoftはタブレットでは負けたが、HoloLensでも同じことになるのではないかと思う。初期の技術研究には多大な資金を継ぎ込むも、結局競合他社にあっさり負けてしまう、そんな未来が見える。

結局、HoloLensは荒削りな開発評価機という印象を受けた。10年後に期待したい。

2017-01-17

GCCのSVN trunkをビルドする方法

GCC 7がC++17のコア言語機能を完全に実装したので、ようやく参考書のサンプルコードが検証できるようになった。

C++ Standards Support in GCC - GNU Project - Free Software Foundation (FSF)

しかし、GCC 7はまだリリースされていない。少し試すだけならばwandboxが使えるが、本格的に使うにはローカルにほしい。

[Wandbox]三へ( へ՞ਊ ՞)へ ハッハッ

そこで、GCCを自前でビルドすることにした。ビルドは以下の手順に従う。

Installing GCC - GNU Project - Free Software Foundation (FSF)

GCCのコンパイルに必要なソフトウェア

Prerequisites for GCC - GNU Project - Free Software Foundation (FSF)

GCCのコンパイル環境を整えるには、有名なGNU/Linuxディストリビューションを使うのが最も手っ取り早い。筆者はUbuntuを使っている。

GCCはC++98で書かれているためにC++98コンパイラーが必要になる。ある程度最近の安定版バージョンのGCCを使うのが最も手っ取り早い方法だ。

POSIX互換シェルが必要だ。これにはGNU bashを使えばよい。

awkが必要だ。GNU awkの最近のバージョンを使っておけば問題ない。

GNU binutilsが場合によっては必要だ。とはいえ、GNU binutilsが入っていない環境でGCCを使いたいとは思わないだろう。

gzip, bzip2, GNU make, GNU tar, Perlが必要だ。

GCCはオプショナルではあるが、デフォルトで4つのライブラリを使う。GNU GMP、MPFR, MPC, islだ。DebianとUbuntuでは以下のようにして入手できる。

apt-get install libgmp-dev libmpfr-dev libmpc-dev libisl-dev 

この4つのライブラリは、主要なGNU/Linuxディストロならば十分に最近のバージョンがパッケージ化されているだろうが、GCCのソースコードには./contrib/download_prerequisitesというスクリプトがある。これを実行すると、4つのライブラリのソースコードをダウンロードしてGCCのビルド時にビルドして使うようにもできる。

flexが必要だ。GCCのリリース版のソースコードには、.lファイルからflexで生成したファイルは含まれているのだが、SVN trunkには含まれていない。configureスクリプトはflexが存在しないことを警告してくれないのでハマる。

GCCのソースコードのダウンロード

Downloading GCC - GNU Project - Free Software Foundation (FSF)

GCCのソースコードは様々な方法でダウンロードできる。最新のSVN trunkのソースコードを入手するにはSubversionを使うのが最も手っ取り早い。

svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk

一度チェックアウトしたソースコードから最新版への差分をダウンロードするには、svn updateを使う。

他にも、gitミラーやtarで固められたスナップショットもある。

Configure

Installing GCC: Configuration - GNU Project - Free Software Foundation (FSF)

GCCのビルドは、configureスクリプトを実行してMakefileを生成してmakeするという古典的な方法で行われる。configureスクリプトの実行は、GCCのソースディレクトリとは別の場所で行うことが強く推奨されている。そこでそのようにする。


svn checkout svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk
mkdir gcc-build
cd gcc-build
../gcc-trunk/configure オプション

configureスクリプトには、いくつかのオプションを渡す。

今回、GCCをビルドする目的はC++17のコア言語機能を試すことだ。したがって、言語はCとC++しか必要がない。GCCはCとC++の他にも、Ada, Fortran, go, 醜悪なobjective-C, 太古の忌まわしきObjective-C++に加えて、LTOとJITも言語としてサポートしている。

言語をCとC++に限定するには、

--enable-languages=c,c++

をオプションに指定する。

この2017年では、ほとんどの読者はx86-64アーキテクチャのコンピューター上で自由なOSを実行しているはずだ。x86-64アーキテクチャは複数のビルドターゲットがある。GCCでは、32bitコードをm32、64bitードをm64、アドレスは32bitだがその他は64bitなコードをmx32としている。今回の目的はC++17のコア言語を試すことなので、複数ターゲットのコードを吐くことにしか興味がない。なので、multilibを無効にする。

--disable-multilib

GCCのビルドは、他のよくあるソフトウェアと違い、ややこしい。というのも、GCCはかつてCで、今はC++で書かれているからだ。システムのC++コンパイラーでGCCをビルドしたとして、システムのC++コンパイラーが壊れている場合、ビルドしたGCCも壊れてしまう。この問題を発見するため、GCCのビルドは3-stage bootstrapと呼ばれる方法で行われる。

  1. システムのコンパイラーでstage-1 GCCをビルドする
  2. stage-1 GCCでstage-2 GCCをビルドする
  3. stage-2 GCCでstage-3 GCCをビルドする
  4. stage-2とstage-3を比較して挙動に差がないことを確認する
  5. stage-3コンパイラーでランタイムライブラリをビルドする

今回はC++17コンパイラーを手っ取り早く試す目的なので、3-stage bootstrapは無効化する

--disable-bootstrap

結果として、configureスクリプトは以下のように実行する

configure --enable-languages=c,c++ --disable-bootstrap --disable-multilib

GCCのビルド

Installing GCC: Building - GNU Project - Free Software Foundation (FSF)

configureが成功したならば、configureを実行したディレクトリにMakefileが生成されているので、あとはmakeするだけでよい。

最適化を有効にして並列コンパイルもできる。

make BOOT_CFLAGS='-O' -j4

GCCのインストール

Installing GCC: Final installation - GNU Project - Free Software Foundation (FSF)

無事にビルドが終わればインストールできる。

make install

デフォルトではインストール先が/usr/local/下になっているので権限が必要だ。

筆者の体験では、flexをインストールしていない状態でconfigureが通り、makeに失敗した後、flexをインストールした後も途中からのmakeは失敗した。

ドワンゴ広告

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

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

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

2017-01-13

GCCがC++17のコア言語機能を実装完了

Hacker Newsで話題になっていて知ったのだが、GCCがいつのまにか、C++17の現ドラフトの全コア言語機能を実装している。

C++ Standards Support in GCC - GNU Project - Free Software Foundation (FSF)

とうとう、なかなか実装されなかったクラステンプレートのコンストラクターからの実引数推定も試すことが出来た。

#include <iterator>


template < typename T >
    struct X
    {
        X( T t ) { }
        template < typename Iterator >
        X( Iterator first, Iterator last ) { }
    } ;
// deduction guide
template < typename Iterator >
    X( Iterator, Iterator ) -> X< typename std::iterator_traits<Iterator>::value_type > ;


int main()
{
    // X<int>
    X x1(0) ;
    
    int a[] = {1,2,3} ;
    // X<int>
    X x2(std::begin(a), std::end(a))  ;
}

これが動く。感動だ。

ドワンゴ広告

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

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

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

2

2017-01-10

ボルダリングを初めて2年がたった

ボルダリングを初めて2年がたった。最初は7級すら苦労していたのだが、今は全く苦労せずに登れるようになった。現在のグレードは4級で、1ヶ月以上取り組み続けて簡単な3級が落とせる程度だ。

ボルダリングを初めてから体重が増えた。これは筋肉が増えたこともあるが、脂肪も明らかに増えている。運動により食事量が増えたためだろうか。ボルダリングを始める前は60kgであった体重が、いまは73kgほどになっている。体が重いと登りにくい。減量のため、食事量を意識的に減らし、通勤を電車から徒歩に切り替え、自宅から会社までの5kmほど歩くようにしている。5km歩くと50分ほどかかる。しかし電車で行くにしても自宅は駅から遠く、かつ乗り換えが発生するので結局40分かかる。通勤時間が10分しか変わらないのであれば、歩いてもよいということになる。一週間ほど徒歩通勤を続けたところ、体がなれたので特に疲れることはなくなった。一ヶ月ほど続けているが、痩せない。

ボルダリングでは特別な靴を使う。しかし未だに納得のいく製品に出合っていない。これまでは主にスポルティバの靴を履いてきたが、スポルティバの靴は3ヶ月ぐらいで潰れてしまう。スポルティバの中では、Geniusが一番気に入った製品だった。Geniusは9ヶ月履くことができた。今はFive TenのQuantumを履いている。この靴はFive Tenには珍しく、幅広の足でも履くことができる。3ヶ月ほど使ったが、つま先のソールが大分削れてきた。あと3ヶ月は持たないだろうと思う。Five TenのQuantumは相当に気に入ったので、次の靴もこれにするかもしれない。

ところで、クライミングジムでは、たまに白髪交じりの齢六十はとうに越していようと思われる翁が極めて動的な動きをしてグレードの高い課題を登っている。それをみて、なるほど、ボルダリングというのは歳をとっても問題なくできるスポーツなのだなと老後も頼もしく考えていると、ある人から、「果たしてそうだろうか。あの歳でなおあれだけ動ける強者のみ生き残っているだけではないだろうか」と生存者バイアスの可能性を指摘された。確かにそうだ。

2017-01-05

GoogleがGoによるPython実装、Grumpyを発表

Googleが既存の社内のPythonコードをGoで実行するためのPython実装を公開している。

Google Open Source Blog: Grumpy: Go running Python!

google/grumpy: Grumpy is a Python to Go source code transcompiler and runtime.

Googleの発表によれば、YouTubeのフロントエンドサーバーとYouTube APIはほとんどPythonで書かれているという。現在、YouTubeのフロントエンドはCPython 2.7で実行されているが、CPythonの制約により効率化には限界があるのだという。

GrumpyはPython 2.7のコードをGoのコードに変換するツールgrumpcの実装だ。grumpcはPythonで実装されていて、astモジュールでPythonをパースして、Goコードを吐く。Python 2.7系なのは、Google社内の既存のコードを実行するためだ。また、execやevalのようなインタープリター実装ならではの極めて動的な一部の機能は実装されていない。

Pythonの標準ライブラリのほとんどは、Pythonによって実装されているため、そのままGoコードに変換されてそのまま動く。

GrumpyにはGlobal Interpreter Lockが存在しない。リファレンスカウントのかわりにGoのGCにオブジェクトの生存管理を任せている。この設計のため、C extension moduleは使えない。この設計により、GrumpyはCPython実装よりスケールすると主張している。

Grumpyはインタープリターではない。Grumpyによって生成されたGoのコードは通常通りGoによってコンパイルされる。これにより開発やデプロイの柔軟性は下がるが、ネイティブコードへのコンパイルと静的解析により、より効率のよいコードを吐くことができるようになる。また、Grumpyで実行されるPythonコードは、Goのモジュールをimportして使うことができる。

興味深いツールだ。

2017-01-03

ディストピア小説のネタとして使える実話

事実は小説より奇なりとはよく言ったもので、ディストピア小説を超える実話が世の中に溢れている。

Automated book-culling software drives librarians to create fake patrons to "check out" endangered titles / Boing Boing

East Lake Country図書館のシステムは、貸出記録から人気のない本を破棄するようになっている。この図書館の司書は、フェイクの利用者情報を登録して、司書がお気に入りの破棄されてほしくない本を守るために、多数の貸出記録を捏造した。

Healthcare workers prioritize helping people over information security (disaster ensues) / Boing Boing

ある病院の医療システムのセキュリティは、一定期間の入力がないとパスワードの入力を要求する仕組みになっている。このために、看護師の医療システムの利用時間の大半は、パスワードを入力することに費やされている。刻一刻と病状が悪化する患者の情報を即座に入手しなければ患者の生死に関わる状況では、パスワードの入力にかかる時間は致命的である。そのため、ある病院では、新米の看護師を医療システムのキーボードを一定期間ごとに押し下げる係に割り当てている。

このような話をネタにしたディストピア小説が読みたいものだ。例えば監視社会で観測データから社会に不要な人間が自立型の機械によって自動的に破棄されていくディストピア世界において、人類の大半が破棄された荒廃とした世界で、生存のために観測データの捏造を続ける人類。

あるいは、電力や食料の生産が完全に自動化された世界において、生産量の調整のためにひたすら入力を一定間隔で叩き続ける不毛な仕事。

そういえば、年末にPixivのアカウントに対して大規模な他所から流出したIDとパスワードの組み合わせによるログイン試行が行われ、結果として何が行われたかというと児童ポルノ画像のアップロードだったという。これは、児童ポルノというのは法律で所有が違法なことにより、画像を投稿できるWebサイトに対する最も手っ取り早い嫌がらせの手段であるのだという。この事件から、児童ポルノを武器として利用するディストピアネタを思いついた。

例えば、児童ポルノは存在が違法であり、児童ポルノを記録するストレージも違法である。そこですべてのコンピューター機器はRFC 3751ストレージは児童ポルノを検出すると自動的に自己破壊し、また児童ポルノを検出して破壊する自律型ロボットがそこらじゅうを徘徊している。大規模な児童ポルノをばらまくマルウェアの影響によりコンピューターの大半がOmniscience Protocolにより文鎮化した世界で人類が生き残りをかけて児童ポルノを武器にロボットと戦う。児童ポルノが武器になる理由としては、児童ポルノだと判定されるものををロボットに観測させるとロボットはOmniscience Protocolを発動して自己破壊を行うからだ。

2016-12-26

誤り:paizaの問題はC++17でも成り立つ

この記事は間違っていた。

この変更では、インクリメント演算子の副作用のコミット順序はまだ規定されていない。

paizaが以下のような質問を出している。

問題は、int i = 0 ;であるとき、以下の式を評価した結果が1になるのはどれかという問題だ。
  1. i++ + ++i
  2. ++i + ++i
  3. i++ + i++
  4. ++i + i++

C言語では、この式を評価した結果は未定義である。

C++14までは、この式を評価した結果は未定義である。

C++17では、サブ式の評価順序が固定されたことにより、この式は以下のように評価されることが規格上保証されている。

C++17でも未だに未定義。§1.10 p18に書かれている。

  1. 2
  2. 3
  3. 1
  4. 2

参考:

[PDF] P0145R3: Refining Expression Evaluation Order for Idiomatic C++

P0400R0: Wording for Order of Evaluation of Function Arguments

現在、Clang 4.0 headがP0145R3とP0400R0を正しく実装している。GCC 7 headはP0145R3の実装を謳っているが現時点ではバグのため、2番目の式の評価が4になるようだ。

ドワンゴ広告

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

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

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

2016-12-09

freeeの保有する特許5503795について読んで解釈を試みたがやはり新規性も技術的価値もわからないしゴミだったのでfreeeのエンジニアは早くfleeするべき

freeeが特許侵害でマネーフォワードに訴訟を起こしたそうだ。freeeのプレスリリースでもその事実を記載している。

特許権侵害訴訟の提起について | プレスリリース | freee株式会社

これによると、マネーフォワードが侵害したとfreeeが主張している特許は、特許第5503795号だそうだ。他の特許については触れていないのでこの特許を読んでみることにする。

特許 第5503795号 会計処理装置、会計処理方法及び会計処理プログラム - astamuse

この特許は本当にゴミなのだが、私の解釈した限りで、この特許を使った技術的な実装とは以下のようなものだ。ここで、この特許が主張している文脈やアイディアは無視して、単なる根本的な実装のみを書いている。

ユーザーの利用している金融機関やクレジットカードの取引の履歴データ(何をどこからいくらで買った、売ったという取引情報)をWeb上からスクレイピングする。

会計処理では、取引情報は、勘定科目という様々な名目に仕訳しなければならない。勘定科目とは、例えば費用の項目では、仕入とか接待交際費とか消耗品費とか賃借料といったものである。スクレイピングした取引履歴情報には、勘定科目はない。勘定科目というのはその文脈に依存する。例えば、鉛筆を購入したとして、その鉛筆を自社の社員が業務のために使うのであれば名目は消耗品費だ。鉛筆を更に第三者に販売するのであれば名目は仕入だ。

勘定科目は人間がその文脈に基づいて分類しなければならないのだが、ある程度の推測はできる。例えば、鉛筆の購入費用は、水道光熱費とか保険料にはまずならない。大方は消耗品費か仕入だろうし、大抵の場合は消耗品費だろう。したがって取引履歴情報から「鉛筆」というキーワードを抽出して、キーワードと勘定科目の対応テーブルを参照して、自動的に勘定科目の仕訳を行うことができる。

自動で仕分けた上で、人間に仕訳結果を見せて、間違いは修正させる。

とまあ、基本的にはこのような実装だ。

ちょっとまてよ、そんな分類作業は会計や簿記といった概念が発明されて以来行われている極めて一般的な既知既存の作業ではないか。キーワードで勘定科目を推定することに新規性などあるのか。

この特許は、極めてバカバカしい、人をけむにまくような、ポストモダンもかくやと思われるような言葉遣いをして、このような人間が何千年も行ってきた作業を再発明している。

まず、請求項1の冒頭を読んでみよう。

請求項1

クラウドコンピューティングによる会計処理を行うための会計処理装置であって、

「クラウドコンピューティング」とは一体何を意味する言葉であろうか。一般的に考えればAWSとかAzureのようなプラットフォームのことを言うのであろうか。クラウドだろうが非クラウドだろうが本質的には大差ないし、第一肝心の処理を実装するソフトウェアのみかけの実行環境は古典的なコンピューターと全く変わらない。クラウドは既存のソフトウェア資産を使えるように大変な努力をしているからだ。

気を取り直して、続きを読んでいこう。

ユーザーにクラウドコンピューティングを提供するウェブサーバを備え、

おや、「クラウドコンピューティング」とはユーザーに提供するものなのか。ということはAWSとかAzureなどではないということになる。freeeは自ら「クラウド会計ソフト」と名乗っている。すると、エンジニアがインフラとして使う意味のクラウドコンピューティングではなく、ユーザー側ではなくサーバー側で処理を行うことを「クラウドコンピューティング」と称しているのだろうか。こちらの意味であれば、例えばGMailはクラウド電子メールソフトであるし、Google Docsはクラウド表計算ソフトということもできる。

この特許の前文を検索しても、「クラウドコンピューティング」なる用語の定義が出てこない。ただし、

本発明はウェブ明細データを利用する点で、現時点では、中小企業及び個人事業主のうち、その恩恵を受けることができる割合が限られている。すなわち、我が国の企業におけるクラウドコンピューティングの利用率は、非特許文献1に記載されているとおり、9.1%に過ぎない、つまり大部分においてウェブ上のリソースが活用されていないのである。本発明は、中小企業及び個人事業主に初めて焦点を当てた上で、かつ、今後のクラウドコンピューティングの利用率向上を見越してなされたものであり、そこに大きな先進性がある。

この非特許文献1というのは、総務省、平成23年通信利用動向調査(企業編)、31頁のことで、以下から入手できる(ただしHTTPなので改変されていない保証がない。)

http://www.soumu.go.jp/johotsusintokei/statistics/pdf/HR201100_002.pdf

これによれば、クラウドコンピューティングの定義はしていないが、どうやら処理の一部をサーバー側で行い、ユーザー側のクライアントにWebブラウザーを使うソフトウェアのことを意味しているようだ。

しかし、「Web上のリソースが活用されていない」という表現は謎である。まるですでに持っている資産を使わずに放置しているような書きようだが、サービスを使う契約すら結んでいないのに、活用していないとは一体なんだろうか。例えば東京には流しのタクシーが多数走っているが、タクシーにほとんど乗らない東京人は、「公道上のタクシーリソースを活用していない」と言えるのだろうか。

そして、先進性というのも疑問だ。というのも、GMailは10年以上前に公開されているし、それ以前にもWeb上でメールを管理、送信できるようなWebサイトは、クラウドという言葉の登場以前にも存在していた。企業が使いたいかどうかということに先進性があるのだろうか。より使いやすいUI、管理しやすい機能、セキュリティなどは、別にいまに限った話ではない。

なぜ筆者が「クラウドコンピューティング」なる用語の定義にこんなに細かく考察しているかというと、この特許では、「クラウドコンピューティング」なる用語を多用しているからだ。特許の文章中に13回使われている。例えば、

ウェブサーバが提供するクラウドコンピューティングによる

クラウドコンピューティングによる会計処理を行うための会計処理装置

ユーザーにクラウドコンピューティングを提供するウェブサーバ

Webブラウザーをクライアントとして使いサーバー側の処理に依存するソフトウェアが、Webブラウザーではないソフトウェアクライアントと比べて技術的に何か先進性があるようには思われない。特許のクラウドコンピューティングをクライアントサーバー型サービスに変えても別に何の違いも内容に思われる。

クラウドコンピューティングという用語の使い方だけで謎であるし新規性のかけらも感じられない。

特許では、さも当たり前の人間が何千年もやっている作業が、まるで先例なく画期的な思いつきによって発明されたかのように書かれている。

例えば、キーワードには表記ゆれがある。ANAはエー・エヌ・エーと書かれるかもしれないし、エーエヌエーと書かれるかもしれない。このようなひらがな、カタカナ、漢字、アルファベット、ハイフンの有無、マイナス、長音記号などの表記ゆれを補正して同じキーワードとして扱うようにする処理が、あたかも画期的な思いつきで実施したところ効果があったかのように書かれている。

また、「モロゾフ JR大阪三越伊勢丹店」のようにキーワードが複数ある場合、JR大阪三越伊勢丹店のJRというキーワードで勘定科目を推定すると旅費交通費だが、モロゾフという洋菓子店で推定すると、贈答品を購入したので接待費だと推定できる。このように複数のキーワードがある場合、キーワードの種類によって優先度を設けることで、正しい判定ができる。この優先度として、品名は取引先より優先させた方が推定の制度が上がることが画期的なひらめきにより発見されたなどとしている。そんな複数のキーワードに優先順位をつけることは人間が何千年も行ってきたことであるし、コンピューターの発明以後即座に行われただろうに、どういう新規性があるのだろうか。

ちなみに、この特許は一度却下されているのだが、この優先順位という請求項を付け加えることで認められている。

この特許は、会計処理は発生主義の原則に基づいて「デイリーベース」(1日単位でという意味か?)で行われているが、個人や中小企業などの場合、期日までに会計処理を終わらせればよく、自動的に仕訳をした上で、ユーザーにWebブラウザー上で候補を表示して修正させる方法で、一括して仕訳を行うので、新規性があるとしている。

これもよくわからない話だ。というのも、人間が行う金の動きなのだから、その日のうちに申請し忘れて期日ギリギリに会計処理を行うことなど大企業であってもよくあるだろうし、コンピューターが今のように高性能になる前は、バッチ処理といってデータを一括で一気に処理していたものだ。すると、バッチ処理をしていた頃のコンピューターシステムで、キーワードに対応した分類を行うもので、更に会計処理をする先例が存在すれば、この特許は無効になる。そのような先例は探せばあるのではないかと思われるし、会計処理に限定したところで何か技術的に変わるとも思えない。

この特許は、とにかく人間が文字と数学を発明して以来、数千年も行ってきた会計処理という既存の作業をコンピューターでやったという他なく、しかもそのコンピューターというのが、クラウドコンピューティングとかWebサーバーとかWebブラウザーとか極めて限定的な範囲になっている。いくら範囲を狭めたところで、技術的に何か新規性のある発明には思えない。

さて、こんなゴミ特許は一体誰が発明したのか。特許に記載の情報によれば、佐々木大輔、横路隆、平栗遵宜が発明者になっている。

freeeのWebサイトの会社概要によれば、

会社概要 | freee株式会社

佐々木大輔は創業者で代表取締役。「形式的で非効率なことは大嫌い」とあるが、こんなゴミ特許を形式的で非効率的なゴミ特許を取得した上で、競合他社を極めて短い交渉期間でまるで妨害するかのように訴訟を起こす形式主義と非効率性は持ち合わせているようだ。

横路隆はCTOで共同創業者。「テクノロジーでスモールビジネスのありかたを再定義していきます」とあるが、技術ではなく特許で競合他社を妨害するビジネスを定義中のようだ。定義といえば、クラウドコンピューティングなる謎の用語も定義していただきたい。

平栗遵宜は開発本部長。「ユーザーに価値を届けるために必要なのは技術力と気合」とあるが、技術力ではなくゴミ特許で競合他社を妨害することで他の価値を抹消した上で唯一の価値を独占して届けるようだ。まさに気合が必要とされる。

創業者で代表取締役、共同創業者でCTO、開発本部長といった、役職キーワードから推定して会社の運営や技術の方向性の最終的な判断をする役割の人間が技術で勝負せず、くだらないゴミ特許を恥ずかしげもなく申請して同業他社に特許訴訟を起こすとは、freeeの技術的な先行きが危ぶまれる。

freeeのエンジニアは早くfleeするべきではないか。

2016-12-08

freeeのゴミのような特許の新規性が全く理解できない

freeeが特許侵害でマネーフォワードを提訴したというニュースが流れている。

freeeがマネーフォワードを提訴、勘定科目の自動仕訳特許侵害で | TechCrunch Japan

肝心の特許は、以下のものらしい。

特許 第5503795号 会計処理装置、会計処理方法及び会計処理プログラム - astamuse

読んでみたが、何の新規性もあるようには読めない。やたらとクラウドコンピューティングなる言葉が出てくるが、この特許でAWSとかAzureとかGoogle Apps Engineのようないわゆるクラウドかそうでない従来のサーバーかで何か違いがあるとは思えないし、その他のことも、人間が有史以前からやってきた分類作業であるようにしか読めない。数千年も存在する既存の概念をコンピューターで行うというだけのゴミ特許が乱立しているが、どうやらそのコンピューターを更に細分化してクラウドコンピューティングとかウェブサーバーとかのバズワードを追加しただけで、範囲をいくら狭めようと分類は分類でしかない。

特許制度は消え去るべきだ。

そして、歴史的に、このような特許ゴロ訴訟をしだす企業というのは4パターンある。

  • 何も具体的な特許技術を利用した現物を提供していないが、ゴミのような特許権だけ保有していて、わずかでも抵触している可能性のある企業団体個人に対して特許利用料を支払え、さもなくば訴訟だと迫るもの
  • 大量のゴミ特許を保有している大企業が小遣い稼ぎに、お前はうちの膨大な特許プールのどれかを侵害している可能性があるので特許使用料を支払え、さもなくば訴訟だと迫るもの
  • 競合相手に対し自由市場による競争をしたくないため存在を妨害するためにゴミ特許を振りかざして利益が出ないほど法外な利用料を要求して訴訟を行うもの
  • 時代についていけない死に体で破産寸前の企業が昔取ったゴミ特許を振りかざして最後の小遣い稼ぎを試みるもの

この特許は本当に新規性のかけらもない。

2016-12-07

江添ボドゲ会@12月24日

12月24日に私の自宅でボードゲームを遊ぶ会を開催することにした。参加方法と会場の場所は以下の通り。

江添ボドゲ回@12月24日 - connpass

参考書に昔の技法を書くべきか:C++17のコンパイル時分岐

今、C++17のライブラリの参考書を書いているのだが、C++14時代の、今は現役だが、もうすぐ古代の技術になる技法を紹介すべきかどうか迷っている。

問題はコンパイル時分岐だ。たとえば、イテレーターがランダムアクセスイテレーターかどうかで、最適な処理が異なるアルゴリズムがあったとする。以下のように書けばいいだろうか。

template < typename Iterator >
void algorithm( Iterator first, Iterator last )
{
    if ( std::is_same<
            std::random_access_iterator_tag,
            typename std::iterator_traits<Iterator>::iterator_category
        >{}
    )
    {
        // ランダムアクセスイテレーターに特化した高速なアルゴリズム
        first + 1 ; // ランダムアクセスイテレーターの処理の例
    }
    else {
    // Forward Iteratorにも対応できるアルゴリズム
    }
}

残念ながら、このコードにランダムアクセスイテレーター以外を渡すとコンパイルエラーになる。その理由は、イテレーターと整数をoperaotr +に渡しているからだ。これはランダムアクセスイテレーターしか提供していない操作だ。

コンパイルエラーを防ぐには、あるテンプレートコードが条件次第で実体化される措置が必要だ。つまり、コンパイル時分岐が必要になる。

C++14でコンパイル時分岐を実現する方法はふたつある。関数テンプレートのオーバーロードを使う方法と、テンプレートの特殊化(部分的特殊化)だ。

関数テンプレートのオーバーロードを使うには、以下のようにiterator_tagでオーバーロード解決を行う。


template < typename Iterator >
void algorithm_impl( Iterator first, Iterator last,
    std::random_access_iterator_tag )
{
// ランダムアクセスイテレーターを必要とする処理
}

template < typename Iterator >
void algorithm_impl( Iterator first, Iterator last,
    std::bidirectional_iterator_tag )
{
// 双方向イテレーターを必要とする処理
}

template < typename Iterator >
void algorithm( Iterator first, Iterator last )
{

    algorithm_impl( first, last,
        typename std::iterator_traits<Iterator>::iterator_category{}
    ) ;
}

テンプレートの特殊化は特にひねりはない。

template < typename T >
struct algorithm_impl
{
template < typename Iterator >
static void process( Iterator first, Iterator last )
{
// 前方イテレーター以上が必要な処理
}

} ;

template  <>
struct algorithm_impl< std::random_access_iterator_tag >
{
template < typename Iterator >
static void process( Iterator first, Iterator last )
{
    first + 1 ;
}

}

template < typename Iterator >
void algorithm( Iterator first, Iterator last )
{

    algorithm_impl<
        typename std::iterator_traits<Iterator>::iterator_category
    >::process( first, last ) ;
}

このようにコンパイル時分岐は実現できるのだが、C++17ではconstexpr ifが入ったことでこのような技法は古臭いハックに成り下がってしまった。

template < typename Iterator >
void algorithm( Iterator first, Iterator last )
{
    using iterator_category = typename std::iterator_tratis<Iterator>::iterator_category ;

    // ランダムアクセスイテレーターの場合の処理
    if constexpr ( std::is_same< iterator_category, std::random_access_iterator_tag >{} )
    {
        first + 1 ;
    }
    // 前方イテレーター以上
    else
    {
    }
}

constexpr ifがあれば、昔の泥臭いコンパイル時分岐ハックはいらなくなる。とすれば、参考書にわざわざ昔のハックを書く必要はない。

とはいえ、それはC++17が普及してからの話だ。C++17が制定されるのにまだ1年かかり、GCCやClangの規格準拠のC++コンパイラーの安定版がリリースされるまでに数年かかり、普及には更に時間がかかる。

とはいえ、歴史を振り返れば、かつてのenumハックがstatic constな整数型のデータメンバーになり、今ではstatic constexprなデータメンバーになっているのを考えると、わざわざ昔のハックを載せる必要はないように思える。

ドワンゴ広告

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

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

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

2016-12-01

AWSのアクセスキーをハニートークンとして使うアイディア

Early Warning Detectors Using AWS Access Keys as Honeytokens

この発想はなかった。

AWSのアクセスキーはハニートークンとして使える。

ハニートークンとは、普段使用しないものが使用されたことを検知して、意図しない利用を検知するトリックである。例えば、通常ならば使われないメールアドレスをパスワードとともに、自分しかアクセスできないストレージに格納しておく。その状態で、もしメールサーバーにログインされた場合は、自分しかアクセスできないはずのストレージに他人がアクセスして、マヌケにもメールアドレスとパスワードをストレージ上に保存しているのを発見して、利用を試みたということになる。つまり、侵入を検知できる。

AWSのアクセスキーは、ハニートークンに使うことができる。AWSに権限を持たないユーザーを追加して、そのユーザーでアクセスキーを発行する。アクセスキーの使用を検知してログをとったりアラートを飛ばしたりするために、AWSのCloudTrail/CloudWatchを設定する。あとはこのアクセスキーを自分しかアクセスできないはずの秘密の場所にばらまいておけばいい。たとえば、

  • サーバーのストレージ、特に ツールが慣習的に使う~/.aws/credentialsなど
  • 自分のローカルのコンピューターのストレージ
  • アプリケーションとかsystemdの設定ファイルの中
  • GitHubのプライベートレポジトリ

その後、アクセスキーが使われた場合、自分以外の誰かが自分以外には本来アクセスできないはずのストレージにアクセスしたということだ。

この方法の素晴らしいことには、AWSのインスタンスは立ち上げないため、金がかからないということだ。アクセスキーは無料でいくらでも発行できる。

2016-11-15

C++標準化委員会の文書: P0480R0-P0489R0

P0480R0: Explicit type checking with structured bindings

構造化束縛に型を制約できる機能を追加すべきではないかという提案。

我々は変数の型に制約をかけられる。

SpecificType var = func() ;
// 間に長いコード
process( var ) ;

このように書いた場合、funcの返す型はSpecificTypeに変換可能であり、processはSpecificTypeを受け取るという制約を書いたことになる。後にfuncやprocessの定義が書き換わって、このコードが通らなくなった場合は、コンパイル時に発見できる。

auto var = func() ;
process( var ) ;

このように書いた場合、型に制約がかからない。

構造化束縛では、型に制約をかす方法がない。ライブラリである程度の制約をかすことはできるが、そのためには冗長なコードを書かなければならない。構造化束縛で型に制約をかける機能が必要ではないか。

[PDF] P0481R0: Bravely Default

デフォルトのコピーコンストラクターがあるならば、デフォルトのoperator ==を生成しようという提案。

そして、operator ==が定義されていて、operator !=が定義されていないならば、デフォルトのoperator !=を生成する。

コピーは等価と深く結びついているので、この挙動は問題がないという主張。

なお、タイトルはスクエアエニックスから出された3DSのゲームが元ネタだという。タイトルは完全に意味不明だが、この提案に不思議と合っているから使ったという。

P0482R0: char8_t: A type for UTF-8 characters and strings

UTF-8文字型であるchar8_tの提案。

UTF-8文字列リテラルの型もchar8_t[]型になる。

移行のために、char8_t[]からchar[]への暗黙の型変換を追加する。この暗黙の型変換を追加するには標準変換の細かいルールを変更しなければならないので、最初からdeprecated扱いで入れるのもありだ。

std::u8stringからstd::stringへの暗黙の変換も提供する。

必ず入れなければならない。

[PDF] P0483R0: Extending Memory Management Tools, And a Bit More

T型の値を参照するイテレーター[first, last)を受け取り、未初期化のメモリを参照する出力イテレーターoutに対して、T型がnoexceptなムーブを提供していればムーブ構築を、そうでなければコピー構築を行うアルゴリズム、uninitialized_move_if_noexcept(first, last, out)の提案。

実装は簡単だがあっても困らないだろう。

[PDF] P0484R0: Enhancing Thread Constructor Attributes

C++のスレッドライブラリを使わず、実装依存の独自拡張のスレッドを使う理由に、スレッドに対して様々な実装依存のオプションを指定したいという需要がある。

オプションというのは、例えばスレッドの優先度、アフィニティ、スケジューリング戦略、スタックサイズ、スタック拡大の有無などだ。

これらのオプションをどうやって指定するか。実装がサポートしていない無効なオプションを渡した時にどう通知するか。実装がサポートしているオプションをクエリーする方法などについて、どのように設計すればいいのかということについて軽くまとめている。特に提案はない。

[PDF] P0485R0:Amended rules for Partial Ordering of function templates

テンプレートのpartial orderingの文面に考慮漏れがあり、パラメーターパックが関わった時に、関数テンプレートのテンプレートの実体化が曖昧になる問題を修正。

[PDF] P0486R0: for_each_iter algorithm proposal

参照する値ではなくイテレーターを得るfor_each_iterアルゴリズムの提案。

std::vector<int> v = { 1,2,3,4,5 } ;
for_each_iter( begin(v), end(v), [](auto && i )
    { std::cout << *i << '\n' ; } ) ;

ありそうでなかった。

P0487R0: Fixing operator>>(basic_istream&, CharT*) (LWG 2499)

以下のコードはバッファーオーバーフローの危険性がある。

char buffer[32] ;
std::cin >> buffer ;

C11でgetsが廃止されたように、operator >>( basic_istream &, charT * )も廃止しようという声がある。このオーバーロードは廃止すべきだが、以下のように変更してはどうか。

template<class charT, class traits, size_t N>
  basic_istream<charT, traits>& operator>>(basic_istream<charT, traits>& in,
        charT* scharT (&s)[N]);

これでバッファーオーバーフローの危険性はなくなる。

ついでにstd::arrayにも対応させよう

template<class charT, class traits, class arrayT>
  basic_istream<charT, traits>& operator>>(basic_istream<charT, traits>& in,
        charT*arrayT&& s);

という提案。安全のために採用されるべきだ。

[PDF] P0488R0: WG21 Working paper: NB Comments, ISO/IEC CD 14882

現在のドラフト規格の文面に対するNBコメント集

[PDF] P0489R0: WG21 Working paper: Late Comments on CD 14882

NBコメントの締め切りまでに提出が間に合わなかったコメント集

ドワンゴ広告

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

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

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

2016-11-14

C++標準化委員会の文書: P0471R0-P0479R0

P0471R0: Single argument std::inserter

引数が1つのinserterを追加する提案。

vectorの要素をすべてsetにコピーする場合、inserterを使うと便利だ。

std::vector<int> vector ;
std::set<int> set ;

std::copy( begin(vector), end(vector), std::inserter( set, begin(set) ) ) ;

問題は、inserterの第2引数は、この場合何の意味も果たしていないということだ。第2引数はbegin(set)でもend(set)でも挙動は変わらない。ならば、inserterに引数を1つしか取らないオーバーロードを追加すべきではないか。

引数を1つしか取らないinserter( Container c )は、inserter( c, c.begin() )と同じ意味になる。

これは入るべきだ。

P0472R0: Put std::monostate in <utility>

<variant>にあるstd::monostateを<utility>に移動する提案。

monostateは1値を表現する型である。monostateは1種類の状態しか取らない。monostateは比較演算子をサポートしている。この特性は汎用的に便利なので、variant以外の場面でも使いたい。monostateだけを使うのに<variant>に依存させるよりは、<utility>に移したい。

利用例としては、テンプレートコードがうっかり型独自の操作に依存しているかどうかを調べるテストの入力として、futureなどで値を持たないことを意味するためにvoidを渡しているが、voidは特殊な特性があり扱いづらいため、voidの代わりとして渡すことが上げられている。

voidは完全型にする提案が上がっているが、まあ、別にutilityでもいい気はする。

P0473R0: + for std::vector concatenation

operator +とoperator +=でvectorを連結できる機能の提案。まるでbasic_stringのようだ。

int main()
{
    std::vector<int> v1 = { 1, 2, 3 } ;
    std::vector<int> v2 = { 4, 5, 6 } ;

    auto v3 = v1 + v2 ;
    v3 += v1 ;

    // v3の中身は{1,2,3,4,5,6,1,2,3}
}

いまさら? 確かに、vectorの連結はよく行う処理ではあるので、簡単にかけるのは便利なのだろうが。

P0474R0: Comparison in C++: Basic Facilities

partial, weak, total orderの3種類の比較を提供する関数群の提案の文面案

P0475R0: LWG 2511: guaranteed copy elision for piecewise construction

C++17でコピー省略が必須になったので、CopyConstructible要件を付けなくて良くなった箇所から要件を取り除く提案。

P0476R0: P0476r0: Bit-casting object representations

ビット列を指定した型として解釈するライブラリ、bit_cast<To>(From)の提案。

ビット列を型として解釈するには、reinterpret_castやunionがよく使われるが、これには未定義の挙動の問題がある。規格に詳しいプログラマーはstd::aligned_storageとmemcpyを使うが、memcpyはconstexprではない。そこで、constexprなビット列キャストライブラリを追加する。

[PDF] P0477R0: std::monostate_function<>

関数ポインター、メンバー関数へのポインターのラッパーライブラリ、std::monostate_functionの提案。


void f() { }

struct X
{
    void f() { }
} ;

int main()
{
    std::monostate_function<&f> f1 ;
    f1() ; // fを呼び出す

    std::monostate_function< &X::f > f2 ;
    X x ;
    f2( x ) ; // X::fを&xをthisとして呼び出す
}

C++17から新しく入った非型テンプレートパラメーターに対するautoを使っているので、テンプレート実引数には値を指定するだけでよい。


template < auto Callable >
struct monostate_function
{
    template < typename ... Types >
    constexpr
    auto operator () ( Types ... args )
    noexcept( std::invoke( Callable, std::declval<Types>... ) )
    {
        return std::invoke( Callable, std::forward<Types>(args)... ) ;
    }
} ;

なぜこんなライブラリが必要なのか。関数ポインターを呼び出したければそのまま呼びだせばいいのではないか。一見するとそう思うかもしれない。このライブラリの目的は、非型ではなくて型を受け取るテンプレートに関数ポインターを渡すためのものだ。

当然ながら、関数ポインターは値である。値は型ではない。型ではないものは型テンプレートパラメーターには渡せない。

たとえば、setの比較関数に独自のcompare関数を使いたいとする。以下のように書ける。


struct UserData { /* データ */ } ;
// UserData型を比較する既存の関数
bool compare_UserData( UserData const & a, UserData const & b ) ;

int main()
{
    std::set< UserData, decltype( &compare_UserData )> set( &compare_UserData ) ;
}

これは甚だ冗長だ。かならずcompare_UserDataを呼び出す型ががあれば、setのコンストラクターに関数ポインターを渡す必要はない。そこで、以下のように書ける。

struct call_compare_UserData
{
    bool operator ()( UserData const & a, UserData const & b )
    {
        return compare_UserData( a, b ) ;
    }
} ;

int main()
{
    std::set< UserData, call_compare_UserData > set ;
}

しかし、これでは関数ごとにクラスをつくって引数を転送するだけのボイラープレートコードを書かなければならない。そこで、monostate_functionの登場だ。

std::set< UserData, std::monostate_function< compare_UserData > > set ;

このように簡単に書ける。

また、unique_ptrにデリーターをわざわざ書かなくても、引数さえあうのであれば、monostate_functionが使える。例えば、mallocで確保したメモリはfreeで解放しなければならないが、monostate_functionを使えば、以下のようにunique_ptrのデリーターが書ける。

int main()
{
    std::unique_ptr<int, std::monostate_function<&std::free> >
        ptr( reinterpret_cast<int*>(malloc(sizeof(int))) ) ;
}

なかなか悪くない。

[PDF] P0478R0: Template argument deduction for non-terminal function parameter packs

Variadic Templatesが最後のテンプレートパラメーターではなくても、実引数推定を行えるように制限を緩和する提案。

以下のように書けるようになる。

template < typename ... A, typename B > struct A { } ;
template < typename A, typename ... B, typename C > struct B { } ;

Variadic Templatesはテンプレート内に1つでなければならない。

これにより、パラメーターパックの最後の要素を取得したり、引数の順序に自由度が出せたりする。

これは当然入るべきだ。

P0479R0: Attributes for Likely and Unlikely Branches

条件分岐の分岐が実行される頻度をヒントとして与える属性、[[likely]]と[[unlikely]]の提案。

条件分岐で、どちらかの分岐がほぼ実行されることが事前に予測できる場合、これをコンパイラーに伝えると、よりよいコードを生成できる。また、現在の深いパイプライン、高度な分岐予測になったアーキテクチャ上でも、条件分岐の結果があらかじめ予想できるのは都合がいい。

GCCとClangには、__builtin_expectedという拡張機能がある。これを使って、ある分岐の選択が期待できるかどうかをコンパイラーにヒントとして与えることができる。既存のコードを調べたところ、__builtin_expectedを使うコードのほとんどは、

#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)

このふたつのマクロだけで用が足りる。現在、likelyとunlikelyを最も使っているのはおそらくLinuxカーネルで、likelyを3000回以上、unlikelyを14000回以上使っている。他にも、Mozillaはlikelyを200回以上、unlikelyを7000回以上使っている。chromiumも数百回以上likelyとunlikelyを使っている。

そこで、分岐が選ばれることが期待できる[[likely]]と、分岐が選ばれないことが期待できる[[unlikely]]というふたつの属性を追加する。これにより、コンパイラーにヒントを与えることができる。

この属性は、conditionに記述できる。

// エラーは通常起こらない
if ( [[unlikely]] check_error() )
{
    do_error_log() ;
}

// 計算は通常ならばすでに終わっている。
if ( [[likely]] is_calculation_completed() )
{
    show_result() ;
}

入るべきだ。

ドワンゴ広告

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

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

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

2016-11-10

C++標準化委員会の文書: P0460R0-P0469R0

[PDF] P0460R0: Flat containers wording

連続したストレージ上に構築したソート済みのデータ構造を持つ連想コンテナー、flat_map/flat_setの文面案。

入るべきだ。

[PDF] P0461R0: Proposed RCU C++ API

物理ページを仮想2ページに分割するクソみたいなオナニーレイアウトを使用したゴミ文書。

内容はRCUライブラリのようだがレイアウトがクソすぎて詳しく読む気がしない。

[PDF] P0462R0: Marking memory order consume Dependency Chains

memory_order_consumeの依存チェインについてLinusが激怒したことが発端の議論の落とし所。

これまたクソみたいなオナニーレイアウトを使用しているため読みづらい。

P0463R0: endian

コンパイル時にエンディアンを取得するこれ以上ないくらいわかりやすいライブラリの提供。<type_traits>に以下の定義が追加される。実装例は以下の通り。


enum class endian
{
    little = __ORDER_LITTLE_ENDIAN__,
    big    = __ORDER_BIG_ENDIAN__,
    native = __BYTE_ORDER__
};

nativeは実装のエンディアンになる。

コンパイラーはバイトオーダーを知っているし、バイトオーダーはコンパイル時に取得できる。

世の中にはバイトオーダーを実行時に変更できるCPUが存在するが、バイトオーダーの実行時の変更に耐えるOSは存在しない。バイトオーダーを変更する関数は提案されていないが、これは提案しない。PDPエンディアンが存在しないが、現在、PDPをターゲットにしたC++14コンパイラーは存在しない。将来、全く新しいエンディアンに対応する必要が生じた場合でも、この設計ならば容易に対応可能である。

P0464R0: Revisiting the meaning of foo(ConceptName,ConceptName)

現在のコンセプト提案では、

R f( ConceptName a, ConceptName b ) ;

という関数宣言は、

template < Conceptname C >
R f( C a, C b ) ;

と書いたものと同等になるが、これを、

template < Coceptname C1, ConceptName C2 >
R f( C1 a, C2 b ) ;

と同等にしようと言う提案。

これは当然こうなるべきだ。

[PDF] P0465R0: Procedural Function Interfaces

一応読んだが、なんとも一言でまとめがたい提案だ。一種の契約型プログラミングなのだろうか。それにしても、コードが冗長になり、しかも関数という単位が断片化され、非常に人間の目によって処理が追いにくくなるのではないか。

[PDF] P0466R0: Layout-compatibility and Pointer-interconvertibility Traits

2つの型がレイアウト互換かどうかを調べるtraits, are_layout_compotible<T, U>の追加

レイアウト互換とは、例えば以下のような型だ。

struct A { int x, y ; } ;
struct B { int x, y ; } ;

void f( A * a )
{
    B * b = reinterpret_cast<B *>(a) ;
}

このようなコードは必要になる。問題は、プログラマーがいかに注意深くレイアウト互換に気をつけようと、後でクラスの定義が変更されてレイアウト互換が壊れた場合、このコードはコンパイル時にエラーにならず、実行時に不可解なエラーとなる。ところで、コンパイラーは型がレイアウト互換であるかどうかを知っている。ならば、型がレイアウト互換であるかどうかを返すtraitsがあれば、このようなコードはコンパイル時に検証できる。

struct A { int x, y ; } ;
struct B { int x, y ; } ;

void f( A * a )
{
    static_assert( are_layout_compatible_v<A, B> ) ;
    B * b = reinterpret_cast<B *>(a) ;
}

これは便利なtraitsだ。

この提案は他にも、以下のようなtraitsを提案している。

is_initial_base<base, derived>

baseがderivedの最初の基本クラスである場合にtrueを返すtraits

struct b1 { int data ; } ;
struct b2 { int data ; } ;

struct d1 : b1, b2 { } ;
struct d2 : b2, b1 { } ;

// true
constexpr bool a = is_initial_base_v<b1, d1> ;
// false
constexpr bool b = is_initial_base_v<b1, d2> ;
template <class S, class M>
constexpr bool is_initial_member( M S::*m ) noexcept;

Sが標準レイアウトクラス型で、Sがunion型か、mがSの最初の非staticデータメンバーである場合にtrueを返す。

struct X { int x, y ; } ;
union Y { int x ; short y ; } ;
int main()
{
    // true
    is_initial_member( &X::x ) ; 
    // false
    is_initial_member( &X::y ) ;

    // true
    is_initial_member( &Y::x ) ;
}
template <class S1, class M1, class S2, class M2>
constexpr bool
are_common_members( M1 S1::*m1, M2 S2::*m2 ) noexcept;

S1とS2が標準レイアウト型で、m1とm2がそれぞれS1とS2のレイアウト内で共通のオフセットから始まる場合にtrueを返す。

struct S1
{
    int x ;
    int y ;
} ;

struct S2
{
    int x ;
    char y[sizeof(int)] ;
} ;

// true
are_common_members( &S1::y, &S2::y ) ;

あれば便利だろう。

P0467R0: Iterator Concerns for Parallel Algorithms

並列アルゴリズムは、既存のアルゴリズムのオーバーロードという形で追加された。既存のアルゴリズムのイテレーターの要件はあまりにも弱すぎて、並列アルゴリズムで使うには問題がある。

入力イテレーターと出力イテレーターは、値に対する具体的なオブジェクトがあるとは限らず、かつマルチパス保証(複数回イテレートして結果が同じこと)がない。並列アルゴリズムで入力イテレーターから入力を得るには、まず入力の個数分のメモリを確保して入力を全部コピーしなければならない。並列アルゴリズムで出力アルゴリズムに順番に出力するには、先頭から出力するよう同期処理が必要だ。

このため、並列アルゴリズムのイテレーターの要件を前方イテレーターに引き上げる。将来的に、イテレーターの要件を引き下げることができる制約や実装が示されたならば、要件を引き下げる。

P0468R0: P0468R0 : An Intrusive Smart Pointer

intrusive reference countingを採用したスマートポインター、retain_ptrの提案。

現在のshared_ptr<T>は、Tへのポインター型とリファレンスカウントのための整数型を別々に確保して管理している。

template < typename T >
class shared_ptr
{
    T * ptr ;
    long * count
public :
    explicit shared_ptr( T * ptr )
        : ptr( ptr ), count( new long{1} )
    { }
    shared_ptr( shared_ptr other )
        : ptr( other.ptr ), count( other.count )
    {
        ++*count ;
    }

    ~shared_ptr( )
    {
        --*count ;
        if ( *count == 0 )
        {
            delete ptr ;
            delete count ;
        }
    }
} ;

これを見ればわかるように、shred_ptr<T>は、ポインターの参照数を管理するためにlong型のオブジェクトを動的確保している。つまり、T型のオブジェクトのためのメモリに加えて、long型のオブジェクトのためのメモリを別々に確保する必要がある。

しかし、もしT型のなかにカウンターがあればどうだろう。メモリ確保は一回で済む。メモリ管理によるオーバーヘッドが減少し、データの局所化によるキャッシュの恩恵も受けられる。


class UserData
{
    long count = 1 ;
    // その他のデータ

public :
    void increment() noexcept { ++count ; }
    void decrement() noexcept { --count ; }
    long use_count() noexcept { return count ; }
} ;

あとは、要素型の中のカウンターの取得、インクリメント、デクリメントをする方法さえ共通化してしまえばよい。この提案では、mixin設計を採用している。

要素型Tは、reference_count<T>を基本クラスに持つことでカウンター処理を提供できる。

class UserData : public std::reference_count<UserData>
{
// その他のデータ
} ;

不自由なMicrosoft Windowsが使っているクソみたいなAPIであるCOMのリファレンスカウントのような独自のリファレンスカウントのAPIに対応するには、retain_traitsを使う。

template < >
struct retain_traits<IUnknown>
{
    static void increment ( IUnknown * ptr ) noexcept
    { ptr->AddRef() ; }
    static void decrement ( IUnknown * ptr ) noexcept
    { ptr->Release() ; }
} ;

retain_ptrはリファレンスカウンターの値が0になっても、自動的にdeleteを呼び出してくれない。deleteを呼び出すのはretain_traits::decrementの役目である。Micorsoft WindowsのCOMの場合、deleteを呼び出す設計ではないため何もしていない。また、リファレンスカウントの値が取得できる場合は、long retain_tratis::use_count() noexceptを呼び出すと取得できる。COMの場合、リファレンスカウンターを変更せずに値を得る方法がなく、またその値もテスト目的のみであるとドキュメントに示されているので、実装しない。retain_traitsにuse_countメンバー関数がない場合は、retain_ptrのuse_countは-1を返す。

様々な場合に対処できる設計になっているのでなかなか悪くない。

ちなみに、retain_ptrはBoost.intrusive_ptrとは全く異なる設計になっている。これは、boostのintrusive_ptrは2001年当時の設計のままで、当時のC++の制約を受けているので、今の進化したC++の恩恵を受けることができないからだ。boostのintrusive_ptrと混同されることを考えて、名前もretain_ptrにしたそうだ。

reference_countの代わりにatomic_reference_countを用いることでリファレンスカウンターの増減をアトミック操作にできる。

また、掴んでいるポインターの解放はreleaseではなくdetachになっている。これはretain_ptrはポインターを所有しているわけではなく、ポインターの解放処理にもかかわらないため、その違いを区別するためにわざと別の名前にしているらしい。

悪くない。

P0469R0: P0469R0: Sample in place

inplace_sampleアルゴリズムの提案。

sample( first, last, out, n, g )は、[first,last)の範囲の値から乱数gを使ってmin( distance(first, last), n )個の標本をoutにコピーするアルゴリズムだ。

inplace_sample( begin, end, n, g )には、コピー先のoutがない。標本は[first,first+min( distance(first, last),n) )の範囲に配置される。イテレーターの参照する型のコピーのコストが重いか不可能で、swapのコストは軽い場合に便利なアルゴリズムだ。

これは追加されるべきだ。

ドワンゴ広告

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

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

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

2016-11-08

C++標準化委員会の文書: P0451R0-P0459R0

P0451R0: P0451r0: Future-Proofing Parallel Algorithms Exception Handling

並列アルゴリズムで要素アクセス関数が例外を投げた時、並列に実行されるので当然複数の例外がキャッチされる可能性があるが、この例外はexception_listという複数の例外を格納するクラスに入れてthrowされるということになっていた。

しかし、このexception_listについて、実装経験がなく規格通りに実装できるかどうかわからないとして、要素アクセス関数が例外を投げた場合は、std::terminate()が呼ばれるように変更された。

この提案では、将来の拡張のために、カスタマイゼーションポイントとしてfail()関数を呼ぶようにしてはどうかと提案している。デフォルトのfailはterminateを呼ぶ。

P0452R0: P0452r0: Binary-Binary transform_reduce(): The Missing Overload

inner_productは規格の定義上並列化できないので、並列化できる設計のtransform_reduceを提案。また、既存のアルゴリズムの流儀に従って同じオーバーロードを提供する。

P0454R0: P0454r0: Wording for a Minimal mdspan

連続したストレージを多次元配列に見せかけるラッパーライブラリ、mdspanの文面案。

名前が暗号的だ。

P0457R0: String Prefix and Suffix Checking

basic_stringとbasic_string_viewに対して、指定した文字列が冒頭、末尾にあるかどうかを調べる、starts_with/ends_withというメンバー関数を追加する。

この機能は極めてよく使う機能であり、また一般的でもある。例えばPythonやJavaの文字列ライブラリは実装しているしQtの文字列ライブラリも実装している。また、最近のQtのコードは1193件のstarts_withと953件のends_withを利用している。他の例を見ても、webkitは304件のstarts_with、142件のends_withを使っている。LLVMは113件のstarts_withと38件のends_withを使っている。

フリー関数ではなくメンバー関数にした理由としては、既存の設計と一貫性があることと、フリー関数にした場合は引数の順序という問題が発生するためである。

using std::literals ;

auto s = "hello world" ;

bool b1 = s.starts_with("hello") ;
bool b2 = s.starts_with("hell") ;
bool b3 = s.starts_with('h') ;

basic_string_viewもしくはcharを引数に取る。

今更追加するのか呆れるが、とはいえよく使う処理ではある。

P0458R0: Checking for Existence of an Element in Associative Containers

連想コンテナーに指定した要素が存在するかどうかを調べるメンバー関数containsの追加の提案。

現状では、連想コンテナーcにある値eの要素が存在するかどうかを調べるには、メンバー関数findを呼び出して、戻り値がc.end()と等しいかどうかを調べることで実装できる。

template < typename C, typename E >
bool contains( C && c, E && e )
{
    return c.find( e ) != c.end() ;
}

このコードは甚だ冗長である。初心者はこのコードを読んでも意図がわからない。また、初心者はこのコードを思いつかず、stack overflowに「連想コンテナーにinsertせずに要素が存在するかどうかを調べる方法ってないの?」という質問をする

c++ - How to check if std::map contains a key without doing insert? - Stack Overflow

この提案により、以下のように書けるようになる。

template < typename C, typename E >
bool contains( C && c, E && e )
{
    return c.contains( e ) ;
}

あまりにも今更な機能追加だが、直ちに追加すべきだ。もともと要望としてはstd-proposalsに上がっていたのだが、誰も公式に提案文書を書いて標準化委員会に提出して国際会議に出席して議論するという労力をかけるものがいなかったのだ。

委員会による設計の欠点の最たる例だ。

[PDF] P0459R0: C++ Extensions for Ranges, Speculative Combined Proposal Document

修正案をマージしたRangeの文面案。

ドワンゴ広告

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

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

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

C++標準化委員会の文書: P0440R0-P0448R0

P0440R0: P0440r0 : Floating Point Atomic View

浮動小数点数に対するatomic_viewの提案

P0441R0: Ranges: Merging Writable and MoveWritable

Range TSでWritableコンセプトとMoveWritableコンセプトがほとんど同じなので、このままにしておくとジェネリックコードが分断されてしまうので、マージしようと言う提案。

P0443R0: A Unified Executors Proposal for C++

様々なC++の提案で必要な実行媒体について、その最小の共通項を抜き出して低レベルなライブラリとする提案。

[PDF] P0444R0: Unifying suspend-by-call and suspend-by-return

コルーチンとresumable関数の統合のための低レベルライブラリの提案。

文書中で、WG21は技術の発明ではなく、既存の技術の標準化を目的としている、この提案は既存の記述の標準化であると言い訳をしているが、どうも発明しているように思えてならない。

[PDF] P0445R0: SG14: Low Latency Meeting Minutes 2016/09/21-2016/10/13

[PDF] P0446R0: SG5: Transactional Memory (TM) Meeting Minutes 2016/07/18-2016/10/10

それぞれ、タイトル通りの会議の議事録

P0447R0: Introduction of std::colony to the standard library

colonyコンテナーの提案。colonyコンテナーは順序保証がないソート可能な非連想コンテナーだ。要素の追加や削除の操作で、削除される要素とイテレーターの終端以外を指すイテレーターは無効化されない。

データ構造的には、複数の要素を格納できる大きさのメモリブロックが複数と、メモリに要素が構築されていないことを示すスキップフラグで構成されている。リファレンス実装では、メモリブロックとスキップフラグを双方向リンクリストで管理している。メモリブロックが空になった場合はメモリは解放される。要素を追加した時に、メモリブロック内に要素を確保できる空きがある場合は、その空きに確保される。このため、順序保証がない。

colony<int> c ;

// 要素を挿入
// 要素を挿入する位置を指定する必要はない。
c.insert( 1 ) ;
c.insert( 2 ) ;
c.insert( 3 ) ;

// イテレーターを取得。値の順番は保証されていない
auto i1 = c.begin() ;
auto i2 = std::next(i1) ;
auto i3 = std::next(i2) ;
auto end = c.end() ;

// イテレーターi2の参照する要素を削除
c.erace(i2) ;

// i1, 13, endは無効化されない

// assertはかからない
assert( i3 == std::next(i1) ) ;

// 要素を挿入、endが無効化される
c.insert( 4 ) ;

利用用途として想定しているのはゲームだ。ゲームでは、多数のオブジェクトがhas-a関係を構築する。たとえば、あるゲーム中の物体を表現するオブジェクトはメッシュやテクスチャやシェーダーやサウンドといったオブジェクトを参照する。このオブジェクトは当たり判定だとか描画だとかを受け持つ様々なオブジェクトから参照される。さらに、オブジェクトはゲームに頻繁に追加されたり削除されたりする。

参照を表現するのに最も都合のいい方法はポインターだ。しかし、オブジェクトを管理するのにvectorなどの既存のコンテナーを使うと、要素の追加削除の際に、イテレーターが無効化されて参照が壊れてしまう。ゲームでは要素の追加削除が頻繁に行われる。

このために、ゲーム業界ではたいてい独自のコンテナーをそれぞれ書いて使っているわけだが、汎用的な実装がほしい。

それが今回提案しているcolonyコンテナーだ。

なかなか良いので、flat_map同様に入ってほしい。

[PDF] P0448R0: A strstream replacement using span<charT> as

廃止されたstrstreamの代替案の提案。固定長のバッファーを使うストリームライブラリは必要であり、近代的な設計により安全に使うことができるというもの。

今更ストリームに労力を注ぐのもどうかと思う。

残りの文書はあと40件ぐらい

ドワンゴ広告

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

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

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

2016-11-07

C++標準化委員会の文書: P0430R0-P0439R0

[PDF] P0430R0: File system library on non-POSIX-like operating systems

<filesystem>はPOSIX準拠のファイルシステムを前提にして設計されているが、POSIX以外のファイルシステムの対応も考慮している。その考慮が浅い部分がいくつかあるので修正案。

P0432R0: Implicit and Explicit Default Comparison Operators

暗黙と明示的な比較演算子を生成する提案。

前回の提案では、比較演算子をそれぞれクラスの定義内で=defaultするものであった。これは極めて冗長であり、プリプロセッサーマクロが書かれることが予想できる。

今回の提案は、operator ==とoperator <を=default、=deleteすると、残りは暗黙に生成してくれる。

  • 明示的に比較演算子を生成する=defaultの文法
  • deleted定義する=deleteの文法
  • 生成された比較演算子は条件次第でconstexprやnoexceptになる
  • aとbが同じ型の場合、a == bはEquality-by-subobjectする
  • aとbが同じ型の場合、a < b はLess-than-by-subobjectする。
  • a == b が定義されていてdeleted定義されていない場合、a != b は!(a==b)として生成される
  • a < b が定義されていてdeleted定義されておらず a > b がユーザー定義されていない場合、a > b は b < a として暗黙に生成される
  • a == bとa < bが定義されていてdeleted定義されておらずa <= bがユーザー定義されていない場合、a <= bはa == bもしくはa < bとして暗黙に生成される
  • a <= bが定義されていてdeleted定義されておらず a >= がユーザー定義されていない場合、a >= bはb <= aとして暗黙に生成される。

Equality-by-subobjectは、operator ==を使ってサブオブジェクト同士を比較するものだ。

Less-than-by-subobjectは、operator ==とoperator <を使ってサブオブジェクト同士を比較するものだ。

例えば、


struct A { } ;

に対しては、以下のような比較演算子が生成される。

constexpr bool operator==(A const &, A const &) noexcept {
    return true;
}
constexpr bool operator!=(A const &, A const &) noexcept {
    return false;
}

以下のコードは、コンパイルエラーになる。

struct B {
    A a;
};
bool operator<(B const &, B const &) = default;

理由は、クラスAはoperator <を提供していないからだ。

以下のように書くと、

struct C {
};
bool operator<(C const &, C const &) = default;

以下のような比較演算子が暗黙に生成される。

constexpr bool operator==(C const &, C const &) noexcept {
    return true;
}
constexpr bool operator!=(C const &, C const &) noexcept {
    return false;
}
constexpr bool operator<(C const &, C const &) noexcept {
    return false;
}
constexpr bool operator>(C const &, C const &) noexcept {
    return false;
}
constexpr bool operator<=(C const &, C const &) noexcept {
    return true;
}
constexpr bool operator>=(C const &, C const &) noexcept {
    return true;
}

以下のように書くと、

struct E {
    int a;
    int b;
    std::string c;
    bool operator<(E const &) const = default;
    bool operator<=(E const &) const = delete;
};

以下のような比較演算子が暗黙に生成される。

inline bool operator==(E const & lhs, E const & rhs) {
    return lhs.a == rhs.a and lhs.b == rhs.b and lhs.c == rhs.c;
}
inline bool operator!=(E const & lhs, E const & rhs) {
    return !(lhs == rhs);
}
bool E::operator<(E const & other) const {
    if (this->a == other.a) {
        return false;
    }
    if (this->a < other.a) {
        return true;
    }
    if (this->b == other.b) {
        return false;
    }
    if (this->b < other.b) {
        return true;
    }
    return this->c < other.c;
}
inline bool operator>(E const & lhs, E const & rhs) {
    return rhs < lhs;
}
bool operator<=(E const &, E const &) = delete;

だいぶマシな提案になった。

P0433R0: Toward a resolution of US7 and US14: Integrating template deduction for class templates into the standard library

C++17にはクラステンプレートのコンストラクターに実引数推定が追加された。これにより以下のように書ける。

template < typename T >
struct A { } ;

// A<int>
A a(1) ;

この機能を追加することにより、既存の標準ライブラリにどのような影響を与え、どのような対応が必要か調査が必要だというNBコメントに応える形で、標準ライブラリすべてを調査した結果、多くのライブラリでdeduction guideが必要であることが判明した。

コンストラクターはテンプレート仮引数名以外の型を使うこともあるので、実引数推定ができないことがある。例えばvectorにはイテレーターのペアを取るコンストラクターがある。


template < typename T, typename Allocator = std::allocator >
class vector
{
public :
    template < typename Iter >
    vector( Iter begin, Iter end ) ;
} ;

このような場合に、deduction guideという文法を使って、型推定のヒントを与えることができる。

template < typename Iter >
vector( Iter, Iter )
    -> vector< iterator_traits<Iter>::value_type > ;

この文書は、標準ライブラリでdeduction guideが必要な場所を列挙している。

[PDF] P0434R0: Portable Interrupt Library

ポータブルな割り込み処理のためのライブラリの提案。

割り込み処理はデバイスドライバーやファームウェアの実装に重要な処理であるが、C++は標準の割り込み処理方法を提供していない。そのため、てんでばらばらな方法で実装されている。そこで、標準の割り込み処理用のライブラリを提供することで、割り込み処理をポータブルに書けるようになる。

device_baseはTriggerというpure virtual関数を持っていて、派生して実装する。割り込み番号やタイマー割り込みを処理できと、大雑把なことが書いてある。

趣旨はわかるが、デバイスドライバーやファームウェアのプログラマーは出力されるアセンブリ言語がわかるほどの低級なコードを好むという偏見があるのだが、果たして標準の割り込みライブラリなど可能なのだろうか。

[PDF] P0435R0: Resolving LWG Issues re common_type

common_typeに持ち上がっている様々な問題を解決すべく、コンセプトを用いたcommon_typeの実装の提案。

問題はコンセプトが入らないことだが。

[PDF] P0436R0: An Extensible Approach to Obtaining Selected Operators

比較演算子の自動生成の提案。

比較演算子を自動的に生成するP0221が却下されてしまったので、別の提案が出てきている。この提案では、P0221の問題のない部分だけを入れる提案だ。

常識で考えて、a == bとa != bの結果は異なるものであるべきだ。また、boolを返すoperator <が比較の意味で定義されている場合、その他の演算子も、x > yがy < x、x >= yが!(x < y)、x <= yが!(y < x)と考えるのが最も自然だ。

ならば、この自動的な解釈だけ提案しよう。つまり、a != bと書いて、boolをoperator ==が定義されていて、operator !=が定義されていない時、a != bは!(a == b)と解釈される。その他も比較演算子も同様。

この提案では、比較の大本であるoperator ==とoperator <を自動的に生成することはないが、このふたつの比較を使って他の比較を自動的に生成する。

[PDF] P0437R0: Numeric Traits for the Next Standard Library

<limits>, <cfloat>, <cmath>に点在する数値の特性を取得するメタ関数を、モダンなtraitsベースの設計のライブラリ、<num_traits>に集約する提案。

例えば、numeric_limits<T>::max()と書いていたものを、num_max<T>::valueもしくはnum_max_v<T>もしくはnum_max<T>{}と書ける。

便利なので追加されてほしい。

[PDF] P0438R0: Simplifying simple uses of <random>

に持ち上がっている数々の提案を寄せ集めたTSを作ろうと言う提案。これ自体には特に内容はない。

P0439R0: Make std::memory_order a scoped enumeration

タイトル通りmemory_orderをscoped enumにする提案。

今のmemory_orderは、C言語風のクソみたいな流儀で定義されている。これは、もともとatomicをCとC++で共通化する目的だったが、C言語はC言語で_Atomicのようなこれまたクソみたいな文法を追加したので、C++としてもmemory_orderをC言語のクソみたいな流儀に合わせる理由は、もはや何もなくなった。

そこで、scoped enumを使う。

現在のクソみたいなmemory_orderの定義

 namespace std {
    typedef enum memory_order {
      memory_order_relaxed, memory_order_consume, memory_order_acquire,
      memory_order_release, memory_order_acq_rel, memory_order_seq_cst
    } memory_order;
  }

これを以下のようにする。

  enum class memory_order {
      relaxed, consume, acquire, release, acq_rel, seq_cst
    };

互換性のために、以下の定義も追加する。


    inline constexpr auto memory_order_relaxed = memory_order::relaxed;
    inline constexpr auto memory_order_consume = memory_order::consume;
    inline constexpr auto memory_order_acquire = memory_order::acquire;
    inline constexpr auto memory_order_release = memory_order::release;
    inline constexpr auto memory_order_acq_rel = memory_order::acq_rel;
    inline constexpr auto memory_order_seq_cst = memory_order::seq_cst;

これは即座に追加されるべきだ。C言語のクソな流儀を取り払え。

ドワンゴ広告

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

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

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

2016-11-05

江添ボドゲ会@11月23日

11月23日の12時から、自宅でボードゲーム会を開催します。

詳しくはconnpassを参照のこと。

江添ボドゲ会@11月23日 - connpass

2016-11-04

PornhubはWebSocketを使ってAdBlockを回避している

BugReplay

あるWeb開発者が、開発のためにchromeで通信内容をキャプチャしたいと考えchrome.webRequestを使ったが、WebSocket経由の通信は得られないことを発見した。さっそくこれをバグ報告した。

その後、インターネット上でわいせつ動画を頒布する大手Webサイトとして有名なPornhubの運営会社であるMindGeek社の社員がこのバグを修正しないようコメントした。

不思議に思って調べてみると、PornhubはWebSocketを使って広告データをやり取りすることで、AdBlock系のブラウザー拡張による広告除去を回避していることが判明した。

なお、この記事を公開して程なくして、AdBlock PlusとuBlock OriginはPornhubに対するWebSocket経由の広告除去も実装した。

技術的に可能であることを示すことと、実際に労力を割いてまで実用的に実装するということの間には、大きな苦労の差があるが、そこまでするとは。

Pornhub Bypasses Ad Blockers with WebSockets | Hacker News

このことについて、Hacker Newsのコメントにコメントを寄せたある人物は、実際にポルノ業界で働いていた人間で、ポルノ業界には世界でも一流の技術者と広告人がいると書いている。ポルノ業界では、ある技術がトラフィックを増やしたり、トラフィックの品質を上げたりする可能性がわずかでもあるならば、その技術を試みるのだという。この人物は、今は世界的な大企業で働いているそうだが、ポルノ業界に比べてなんと保守的でつまらない開発サイクルであり、技術者に裁量が与えられていないかということを嘆いている。この人物はまたあの技術的に魅力的なポルノ業界に戻りたいとは思っているが、ポルノ業界の秘密的でマフィア的な部分には嫌気が差しているとのことだ。

少し前、まだWebサイト上で動画を提供するにはほとんどがFlash Playerを使っていて、YouTubeもサムネイルを実装していなかった時代、なぜYouTubeなどの大手動画サイトはFlashを使いプレイヤー実装も貧弱なのに、ポルノサイトの提供する動画プレイヤーは、いち早くHTML5も提供し、サムネイルも提供し、動画のシークも完璧に動き(当時、YouTubeなどでは動画のシークはあまりよく動かなかった)、画質もよく、その他あらゆる点で優れているのかという疑問がネット上で話題になっていたこともあった。その時は、ポルノ業界は激しい競争に晒されているので市場の原理によりそうなるのだという回答が一番納得の行くものであった。また、ネット上でクレジットカードによる支払いにいち早く対応したのはポルノ業界であるという。

なお、chrome.webRequestがWebSocket経由の通信を補足しないという問題は、すでにパッチが書かれ、いずれ修正される見込みだそうだ。

2016-11-03

Ubuntu 16.10にアップグレードしたらログイン時にディスプレイが点灯しない不具合に悩まされている

Ubuntu 16.10にアップグレードした。

アップグレードは何事もなく終了したようであるが、ログイン時に高確率でディスプレイが点灯しないという不具合に悩まされている。

今使っているコンピューターは、AMDのGPUを積んでおり、Ubuntu 16.04からは、AMDのGPUはAMDの不自由なドライバーを廃止して、自由なドライバーが使われている。Ubuntu 16.04では、OpenGLを使うゲームを起動してしばらく負荷をかけると、急にGPUに問題が発生したらしきエラーメッセージを端末に表示してカーネル自体が止まる問題があったが、日々のテキスト編集作業では何の問題もなかった。

Ubuntu 16.10では、起動に16.04より時間がかかり、かつログイン時に不自然なディスプレイのちらつきがある。時にLightDMのGreeterが表示する場面でディスプレイが消灯してしまう。Greeterが表示されていても、ログインするとディスプレイが消灯することもある。

ディスプレイが点灯しない以外は問題がないので、手探りでリブートを行うと、再びディスプレイの点灯ガチャが引ける。ディスプレイが点灯するかどうかは確率の問題のようだ。一度点灯したままGreeterを突破まで行くと、そのあとは安定しているようだ。少なくとも、現在これを書いている時点で、30分ほどはディスプレイが安定して点灯している。

そして、安定して動作する状態でdmesgをみてみると、AMDのGPU回りのエラーがいくつも表示されている。

画面が見えない状態でリブートする最も確実な方法は、Ctrl+Alt+F1でtty1に切り替えて、ユーザー名とパスワードを入力し、"sudo shutdown -r now"と入力し、パスワードを入力することだ。

さて、Ubuntu 16.10は、GCCのバージョンが6になっている。その他にはあまり目新しい変更はない。デフォルトのClangはまだ3.8のままだ。3.9もパッケージには存在する。libc++の<string>のコンストラクター宣言でnoexceptが一致していない問題もそのままだ。

2016-11-02

C++標準化委員会の文書: P0421R0-P0429R0

P0421R0: Static class constructor

staticクラスコンストラクターの提案。

staticクラスコンストラクターは、一度だけ、main関数の実行前に実行される。

同等のことは、グローバル変数でもできるが、ヘッダーオンリーのコードで実現するためには、提案されている機能が必要になる。

クラスのメンバーという文法である必要があるだろうか。

P0422R0: Out-of-Thin-Air Execution is Vacuous

Out of thin air valueの考察

複数のスレッドで複数のアトミックオブジェクトに対するアトミック操作をmemory order relaxedで行った場合に、値が未規定になることが規格上許されているが、その結果として、絶対に起こりえない値が出てきたらどうするのかという問題。

例えば、2つの初期値がゼロのアトミック変数を複数のスレッドからお互いに間接的に代入し合った結果、人生、宇宙、すべての答えである42がでてくる可能性がある。

Java規格では10年以上も問題になっていて、未だに結論が出ていない問題。

P0423R0: Variable templates for Networking TS traits

Networking TSのtraitsに値テンプレート版(_v)が提供されていないので、提供する提案。

[PDF] P0424R0: Reconsidering literal operator templates for strings

ユーザー定義リテラルのオーバーロードに文字列リテラルを取って文字をそれぞれテンプレート実引数に渡すオーバーロードの追加の提案。

template < typename T, T ... args >
auto operator "" _udl( ) ;

// operator "" _udl< char, 'h', 'e', 'l', 'l', 'o', > ;
"hello"_udl ;

この提案は、C++14にも提案されたが、コンパイル時に文字列を扱う機能が必要だとして却下された。そのような特別な機能は必要ないので当時の提案をそのまま入れるべきだと主張しているのがこの文書。

P0426R0: Constexpr for std::char_traits

string_viewをconstexpr対応させるために、char_traitsのメンバー、length, compare, findをconstexprにする提案。

[PDF] P0428R0: Familiar template syntax for generic lambdas

lambda式にテンプレートを記述できる機能の提案。

[]<typename T >(T x ) { } ;

もともと、C++14に入ったジェネリックラムダの提案に含まれていた機能だが、C++14ではautoを使ったジェネリックラムダだけが入った。しかし、引数の型を扱いたい場合に、autoだけでは不便なので、テンプレートも明示的書けたほうがよい。

[PDF] P0429R0: A Standard flat_map

連続したストレージ上に構築されたソート済みの要素をバイナリサーチすることによる連想コンテナー実装、flat_mapの提案。Boostにあるものが土台になっている。

flat_mapと従来のmapのベンチマーク結果があるが、要素の挿入と削除はとても遅く、イテレートはとても速く、検索はmapより速いがunordered_mapよりは遅い結果となっている。そのデータ構造から考えて予想通りの特性だ。

また、メモリ使用量が少ない。これは当然の話で、mapを素直に実装するには左右の葉ノードと親ノードへの3個のポインターを持つノードによるバイナリツリーになる上に、メモリ確保をノード単位で行うためにメモリ管理のためのメモリも必要になる。また、連続したストレージ上に確保されるためキャッシュの局所性が最高だ。

多くのmapを使うところでは、flat_mapをデフォルトで使ったほうがいいのではないかと思う。

ドワンゴ広告

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

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

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