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

kbkz.connpass.com

Eigen

@olanleed

機械学習とか、自然言語処理とか専攻してる

C++の機械学習ライブラリ

github.com

AROWとか使いたかった。

アルゴリズムの実装→線形代数

uBLASをつかっていたけど使い勝ってが悪いのでEigenに

uBLASへの不満

AutoEncoderの例

• 重み行列
• sigmoid(w * x + b)

• 現実は甘くなくって、matrix or vector型同士しか*演算子しか使えないので、prod関数を使わないといけない。スカラー積にしか対応してない

• prod関数で行列とベクトルの積ができる

• for文を使って更新するしかない
• でも数式がたくさんあるとつらい
• できれば数式をそのままコードの表現したい
• 数式とコードが素直に対応していれば、とても読みやすくなる→使い勝ってが悪い

ので、Eigenを使う。

• ライブラリのビルド不要
• 日本語の文献が多い
• 論文の数式をそのままコードに書ける
• パフォーマンスが良い
• 多用途
• 機械学習アルゴリズムの実装
• AROW解説

blog.k11i.biz: AROW を Ruby で実装してみた

• 教師あり学習
• オンライン学習
• 線形分類器

教師あり学習 - Wikipedia

• AROWはノイズにつよい。SVMより高精度、変動にあまり敏感ではない
• 更新式にしたがって、各特徴の分散を小さくしつつ、与えられた教師データを正しく分類

実装はとてもシンプル

• ハイパーパラメータ
• 共分散行列 単位行列で初期化

• 平均、0初期化しておく

• margin計算

• confidence計算

• 損失関数の定義。推定の悪さを定義した関数

• 平均と共分散

• βの計算

d.hatena.ne.jp

Eigenを使えば楽々実装できる。予測関数の定義。

問題

• 共分散行列をまともに計算。対角要素だけを計算すれば高速化できる。
• MatrixではなくVectorでよい 超高次元にも対応できるから。

AROW実装でも前準備。

• Pythonのnenumerate関数みたいなのが欲しかったので書いた。
• Eigen::Vectorの先頭を指すイテレータを返す関数と末尾を返すイテレータの関数はどうするのか
• Eigen::VectorXdで置き換え

• Onesですべての要素を1で初期化しておく

• シリアライズとデシリアライズ

• std::vectorにコピーすればシリアライズできる
• std::vectorからEigen::Vectorへの変換でデシリアライズできる

MochiMochiの展望

• マルチクラス分類
• 良いアルゴリズム
• 高次元スパースベクトル
• まともなREADME

なぜEigenは早いのか

• 遅延評価を行っているから早いのでは？

JVMとか、参照とかなど

C++の参照をなんとなく勉強してて、Javaの参照とC++の参照は違うという話をしていたので、なんとなく調べてみる。

Javaではプリミティブ型以外の変数への代入はすべて「参照」と言われる。

なお、ScalaもJavaを間借りしているので、仕組みとしては一緒。

qiita.com

codezine.jp

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

Seastar

• OS開発 カーネル開発
• LinuxとかでC言語やってるけどC++やらされることになった。
• 半数の開発者はリモート開発で参加

• IaaS環境に特化したOS OSvを開発

• カーネルなのにboostが使える

• KVM開発者とか有名ドコロが多い

SeaStarとは

www.seastar-project.org

• 高スループットなサーバアプリケーションの為の新しいフレームワーク
• 非同期
• Apacheライセンス
• DB 分散ファイルシステムなどに使える

問題点

• CPUのクロック数があまり向上しない
• コア数は増えるけどソフトウェアが性能を出し切るのは難しい
• ロックの仕様はたとえ競合がなくてもコストが大きい

• あるコアでアロケートされたデータは別のコアで使用されたりコピーされたりする

• ので、ソフトウェアの性能を出し切れていない

シェアードナッシングにしよう

• リニアにスケールするSeaStarフレームワーク
• SeaStarのエンジンを各コアで実行
• データやステートはコア間で共有されず別々に動作
• 分散ファイルシステムとかをイメージ
• カーネルをバイパスして自前のネットワークスタックを使用
• ゼロコピー対応
• ファイル/ブロックIOはカーネルを使用
• スレッドなし、コンテキストスイッチなし、ロックもない
• 非同期！

SeaStarの性能

リニアにスケール

性能結果

• 20コア超までリニアにスケール
• 250,000 トランザクションコア(memcached)

SeaStarのプログラミングモデル

• C++14を使う
• Future/Promise/Contiuationを使う

Promise自体は他の言語とあまり変わらない(JSにもあるし)が、SeaStarの実装に特化された独自実装を用いている。

• ロックしない
• メモリアロケーションしない

など。

簡単なfuture/promiseの例

Chaining

SeaStaのrスケジューリング機構

• ラムダ式は実行される条件とペアにされてスケジューラのランキューに登録
• 実行可能になったものから実行されている
• ランキューもシェアードナッシング

ルール

• 非同期なのでブロックしてはいけない(ブロックが終わるまで何も実行できないから)
• future/promiseを使おう
• ファイルIOなどにもラッパーAPIが提供されている
• ポインタはスマートポインタも使わない
• コピーがふさわしくないときはstd:move()
• CPU間での共有データ ロックは使わず、CPU間で非同期通信を行う
• スケジューリング機構を使ってラムダ式とパラメータを渡す

提供されるAPI

• future/promise/continuation
• ネットワークIO
• ファイルIO
• タイマー
• HTTP
• JSON
• RPC
• Posix APIラッパー
• collectdクライアント

サンプルアプリ

• httpd
• memcached
• HTTP benchmark tool
• 各APIのテストコード

ネットワークスタック

• カーネルバイパスの必要性
• 従来のネットワークスタックだと…
• ソケットAPIとかだとゼロコピー出来ない
• パケットごとにコピーが発生して大きなオーバーヘッドに
• ソケット&プロセス側と、プロトコル側のコンテキストが別
• CPUが別のことも多い
• キャッシュ競合
• レイテンシが増大
• プロトコル・スタック内のロック競合
• システムコール、コンテキストスイッチのオーバーヘッド

DPDK

• カーネルをバイパスして高速に通信を行うフレームワーク
• ユーザランドドライバから直接ハードウェアアクセス
• ドライバでのパケット通信からアプリケーション処理まで同一プロセスの同一コンテキストで実行
• ゼロコピー
• ネットワークスタックは持たない
• これでアプリを書くのはつらい

SeaStarネットワークスタック

• ネットワークスタックを提供
• SeaStarのシェアードナッシングモデルで記述されており高性能
• ソケットAPIと同等のレベルに抽象化されたAPIを提供
• ゼロコピー可能なAPIを提供

余談

DPDKを有効化するとNICのドライバをアンロードされてネットワークが使えなくなる→NICが1つだとアクセスが一切できなくなるのでシリアルコンソールでごにょごにょするしかなくなるのでSSH接続すらできなくなる。

• IPはSeaStarと共有したい
• MACアドレスはSeaStarと共有したい

OSvハンズオン計画してます。

connpass.com

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

kbkz.connpass.com

boost 1.57.0 前提で話を進めよう

Asioを使うことになった理由

• 速度が要求されるサーバの案件
• マルチスレッド対応でAsioを使おう
• シングルスレッドでI/Oを非同期で処理する
• ラムダがネストしまくるので、コールバックまみれになる
• コールバック地獄になりがち
• 読みづらい

可読性を上げる

• コールバック
• コルーチン

• future/promise

• 今回はコルーチンを使おう。→シングルスレッドをマルチスレッドのように扱う

• 軽量スレッドのこと。
• 擬似並列化を行える
• 同期問題が起こりにくい

スタックレスコルーチン

• (簡単そうだった)
• asio::coroutineを継承
• couroutine関数はoperator()に
• continue部分はreenter()で囲む
• yield fork

header

• operator

• reenter

• reenterの中にコルーチンコードを書かないといけない

• コルーチンを書くと、多少可読性が上がったのではなかろうか。

スタックレスコルーチンのメリット デメリット

• 非情に手軽
• かなりかるい

• 読みやすい

• ローカル変数の扱いが制限

• ローカル変数が使えないのはきつい

スタックフルコルーチン

• 依存ライブラリあり
• コルーチンを行いたい関数を指定して、yield_contextを取得する
• spawnによりyield_context作成
• 非同期関数にyield contextを渡すことで、コルーチンに出来る

かなり可読性が上がったのでは？

Boost.MSM

• Transition Tableに上限
• plmplイディオムを使う
• 結構便利

shared_ptrキャプチャ

総括

• マルチスレッド型は大量クライアントをさばけない
• コールバック地獄になるので、コルーチンを使って非同期I/Oを使うべき
• ジェネリックラムダが来たらもっと快適になるのでは?

おまけ

お前らカーネル連中、いい加減に共通の非同期APIぐらい規格しろよといいたくなる。#kbkz_tech

— Ryou Ezoe (@EzoeRyou) 2015, 5月 17

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

kbkz.connpass.com

Boost.Sprit.Qi

LLVM API

github.com

Boost.Sprit.Qi

• Boostに含まれる構文解析のためのライブラリ
• 演算子オーバーロードを巧みに使い、構文解析器が出来上がる
• 楽に書ける

使い方

• 構文解析を2つの関数を使って行う phrase_parseとparse

コード例

解析が成功したらsuccessがtrue it == input.end()になる

ルール

• 文法は1つ以上のルールで構成
• boost::sprit::qi::ruleのインスタンス
• セマンティックアクションと呼ばれる。
• 渡すのは関数オブジェクトでも可

文字種

• いろいろある

ルール同士の結合

• 演算子をつかう
• leximで囲む

ルールの繰り返しと選択

• 正規表現みたいな感じで使えるよ。

Boost.Phoenixの概要

• プレースホルダーと組み合わせると、演算子オーバーロードを駆使して目的の関数オブジェクトをつくってくれる
• 基本的にプレースホルダーを使ってやりたいことを書けばおーけー
• 複数の処理を行いたい場合は、カンマで区切る
• しかし、一部の処理は記法が違うので注意

構造体やクラスへのアクセス 複雑な文法定義

複雑な文法の場合は、別途構造体等に定義してそこに入れたほうがよいかも

ASTを作る

ルールを書き、それにたいするセマンティックアクション内でルールに対応するASTのインスタンスを生成して返す

ASTをネイティブコードに変換しないといけない

LLVM APIをつかえば簡単なのでは？

LLVMとは

• オープンソースのコンパイラ基盤
• IRへの変換プログラムだけ書けばどんなコンパイラでも理論上は可能

LLVM IRを出力する

• LLVM IRはC++においてはクラスのインスタンスで表現されるが、インスタンスを作る方法もモノもまちまち
• IRBuilderを使う
• CreateAdd CreateCall

IRBuilder

ASTでなめていってIRを生成する

LLVM IRのファイルへの出力

• LLVM IRのC++による表現が出来上がったら、ファイルへ出力する

ネイティブコードへの変換

• llvm-asコマンドを使う

全体の流れ

• ソースコードを読み込む
• Boost.Sprit.QiによってAST作成
• ASTからLLVM IRをつくる
• LLVM IRをファイル出力
• ネイティブコード変換

まとめ

• LLVM APIとQiを組み合わせてプログラミングの処理系を作成できる
• IRの形にすればLLVMに所属している最適化が使えるので本質のみに集中
• この組み合わせでBFの派生じゃないネタ言語を作ろう

質疑

• lexとyacc使えばよいのでは

Q. lex/yaccのようなツールはC++にないの？あるいは言語内DSL的な外部ツールと比べてどうなの？ A. 外部ツールは、独自の記法と、セマンティックアクションのC++的なコードが混在するのがよくないと思う #kbkz_tech

— saka1 (@saka1_p) 2015, 5月 17

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

kbkz.connpass.com

@wx257osn2

タイトルは長い

• マンデリング
• constexprラムダ
• ラムダ式とは何か

みなさん本当に初心者なんですか

• 式
• 文
• 型
• 変数
• 関数
• 関数オーバーロード
• テンプレート (型や整数の抽象化して、コンパイル時にそれを解決)

constexprとはなんだ

• 巷では中3女子
• 変数につけるとコンパイル時定数
• 関数につけるとコンパイル時/実行時選べる

コンパイル時処理

• 実行時に走るプログラムを書く
• コンパイル時処理はコンパイル時にプログラムが走る
• 処理をした結果がバイナリに直接埋め込まれる
• 実行時コスト0なので速い。
• キャッシュに載り切らないことがあるので実行時のほうがはやい

constexpr関数

• 実行時にもコンパイル時にもよべる関数
• どちらでも同じ処理を行うのであるから、1回書いたらそれで終わりにしたい
• コンパイル時にでも普通に処理が書きたい

ラムダ式

• 関数のようなものを生成する式
• 式(オペランド)なので、式の途中に出現可能

• もともとは関数型プログラミングのほうから来てる機能
• 式レベルでしか扱えなかった
• 機能としてはC++03からライブラリとしては存在していたけど、11より言語機能として搭載

マングリング

• バイナリの話
• 関数オーバーロードってどうやってるの
• C言語だと関数名がそのまま関数を識別する
• name mangling(名前修飾 名前を複雑にして、関数名を識別しやすくする)
• コンパイラ(が使用しているABI)ごとに修飾の方法が違う
• コンパイラごとにバイナリ互換とれない主な原因

なぜ任意の文をマングリング出来ないのか

• 「マングリング」=「関数のシンボル名を決める」
• 文はプログラムの構成要素ほぼそのもの
• 名前がプログラム

その弊害

• 文をマングリング出来ないといったけど使うことあるのか
• 名前と型をマングリングする

decltype

• decltype(式)で式の型を取得できる

• 型はマングリングの対象

• ラムダ式はマングリングの対象ではない

• 関数の中身はマングリングの対象ではない

C++のラムダ式

• マングリングの対象ではないからコンパイルの対象にもならない

コンパイル時ラムダ式

• 使いたい。。。
• 文をマングリングすることは糞雑魚なので出来ない

使い方

中身の概要

• 基本はExpression Template
• ラッパークラスに含まれていれば中身を

• 含まれていなければvalで包む

• 基本関数はそれぞれ実装クラスが存在

• バックエンドで自作のconstexprTuple採用

実装のつらみ

• 型が長い
• C++14が使いたい人生だった
• Clangの無限再帰バグでC++14使えない
• Variadic Placeholderの実装のためにコード全域に変更
• Selfの実装のためにコード全域に変更
• 相互依存が激しいので実装が飛散している

Haskellを書きたい人生だった #kbkz_tech

kbkz.connpass.com

• 発表枠しかないから発表するしかなかった
• C++書きたくない C++でHaskellを書くしかない

結論

template

型が一部違っていても型が全部違っていても使える。 チューリング完全なのでなんでも組める

operator

• 独自クラスを返す
• ペア同士に対してoperatorクラスを定義する

式がそのまま型にあらわれる

即時解説

ゴールはココ。

• マクロ展開
• 型オブジェクトの先頭と最後に&を入れる
• ラムダ式(のようなもの)を書く

• map_(変数)のoperator()(関数適用)

• 正しい構文木をこの時点でアレするのは困難

• ラムダ式用の記号とか冪乗の記号とかそのままでは使えないのでトークンとして再構成

• 型が読みづらい

• SeqとSeqの間だけみてくれれば…

• parse 正しい構文木を組み直す

現状

あとはEvalだけ

このままだとつらい

諦めた。 * 型づけを行おうとするとつらい * 再帰 template上で再帰しようとすると止まらない * desugar * 適当に扱いにくいところを処理する

map(リスト全値にfを適用)

やったこと

HaskellSyntaxに基づいて構文解析など

余談

• 作ってたらClangが落ちた
• auto周りが不安
• Clang最新版のビルドが通らない
• operatorを組んでたらなぜか動かない
• C++からHaskellが使えるようになった
• HaskellからC++を使おうか

まとめ

• C++でHaskellぽく
• Templateは強い
• Haskellは書ける

C++メタプログラミングの本読むと良いよ。

ロボティクスとC++ #kbkz_tech

kbkz.connpass.com

ロボット界には2つの世界

知能系では計算効率のよい高級言語であるC++は人気

ROS ロボット用OS

ja - ROS Wiki

C++のよいところ

• ライブラリが結構多い
• GCがない
• 効率がよい

C++イメージ

• コンパイル遅い
• ヘッダファイル書くのめんどい
• むつかしすぎ

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

kbkz.connpass.com

cppcms

• テンプレートが使える
• JSONとかセッションで使える

crow

• CMAKEでビルド
• 高速なJSONパーサー
• goとかnettyより速い？

treefrog

• Qtベース
• DBサポートやテンプレートとか結構いろいろある
• ツール群を使って構築する
• 日本語ドキュメント
• 充実したチュートリアル

結論

D言語に逃げよう ビルドがだるい

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

kbkz.connpass.com

@tSU_RooT

cocoa2d-xでゲーム作ろうとしたら挫折した

大学(学部)におけるC++の教育

• C C++ Javaなどを主に教える
• そこで教えられるC++はC++03
• C++古いから挫折しちゃう

→これもったいなくね？

最近のC++はたぶん初心者に優しい

• スマートポインタ
• ユーティリティに多数の機能を追加した
• clangのエラーメッセージはGCCより分かりやすいので、初心者でも分かりやすい

初心者こそ知るべきC++11の便利な機能

• autoによる型推論

• コンパイルエラーはやる気を削ぐ

• スマートポインタ

• C++ではメモリ管理が難しい 確保したメモリを解放する必要あるからつらい
• unique_ptrを使えば自動解放される

• shared_ptrを用いる

• rand()ではなく

• 標準のrand()は線形合同法を使うのであまりよくない
• 分布クラスが多様で、科学技術計算に向いている

• マクロの置き換えとしてのconstexpr
• 指定するとコンパイル時に定数となる機能

おわりに

• C++をつかうなら最新のものを
• C++11普及したら良い

初心者向けOpenCV開発環境の話 #kbkz_tech

kbkz.connpass.com

アシアル株式会社 Windows向けC#アプリ

OpenCV

• コンピュータによる画像認識の話
• OSはWindows/Linux/Androidもつかえる

• C C++ Pythonなどにインターフェイス向け

• 画像処理

• 構造解析

など

• 機械学習との組み合わせが多いかも

kivantium.hateblo.jp

• NuGetをつかってOpenCV環境をつくる
• VisualStudioで使えるパッケージ = NuGet なんでも引っ張ってこれるパッケージマネージャ

Visual C++でのハマりどころ

• プロジェクトの種類がいっぱいある
• 謎フレームワーク

Mac

• OSXでは(homebrewから簡単 でも動画を動かすのはしんどいかも)
• 動画使いたいなら別パッケージを使わない溶けないかも

C++不要説

• そもそもC++は敷居が高い
• OpenCVには数学も必要

まとめ

• Windows Open CV はNuget
• Macは楽
• OpenCVを使う上で、C++と線形代数の知識は必要。

組み込み向けC++のやり方を探る mbedで楽しい組み込みプログラミング #kbkz_tech

kbkz.connpass.com

@ksyndo

ロボット研究してたWebエンジニア見習い

マイコン開発

• ハードウェアごとに異なる初期化処理
• 間違えずに書くのも一苦労

オープンソースマイコンボードの勃興

みんなで同じハードを使おうぜっていう気運。

• Arduino 人気っぽい
• mbed C++で開発する環境が整えられている

mbedでLED光らす

mbed開発環境

• ユーザーがどんどんあげていっているライブラリ
• 質問できるコミュニティ

• オンライン上でコンパイルできる環境

• USBからパソコンに挿すとダウンロードが始まる

• mbedとC++11/14
• mbedライブラリはオープンソース

• ライブラリ使うだけだとコミュニティに貢献できん

• C++11が使えると嬉しい

まとめ

• mbedはデータシート読まなくて良い
• mbedでもC++11を使いたかったら使ってみた

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

kbkz.connpass.com

@beepcap

• 組み込み系でごはんたべてる
• C++は98くらいまでしか知らない

LTの目的

• C++は優れた言語
• なぜ言語で使われないのか周知したい

ターゲット

• OSがなかったり、OSそのものやハードウェアドライバの開発をするとき

問題点

• C++は(Cに比べて)メモリ使用量が類推しにくい
• 例 構造体100個用意したプログラム 何バイト？
• C++は処理時間の類推も難しい
• operatorがオーバーライドされていたらもとのコードを追わなければならないのでつらい。
• C++はハードウェアやアセンブル言語との相性がよくない
• アセンブリでシンボル名を使ってリンクしにくい

まとめ

• 組み込み開発の一部ではC++固有の機能がとてもつかいづらい
• アプリケーションは大丈夫だけど、下回りではつらい
• ルネサスSH4でC++のコンパイラを使ったら変数が消滅する
• 今後解消する手段は今後に期待

C++でHello worldを書いてみました #kbkz_tech

kbkz.connpass.com

競プロ界隈で流行っている記号プログラミングでHello, Worldやってみよう。

• エントリポイント
• int型の配列
• ジェネレータ
• _で始めるテクニック
• これを生成するCのプログラムを書いた

2015年にC++プログラムを書いた

マクロからテンプレートに

• マクロ 値を用意する必要[0,1,2,3,4]
• テンプレート 簡潔に書ける[0..4]

C++でバイナリ生成といえば

• Xbyakを使おう

64bit対応

• ifdefいらないようにしよう

• 命令はほぼ共通なので、32/64で違いが出るところで実装をかえる
• x86とx86-64
• 逆アセンブルするとほぼ一緒。

慣れてくると読めるようになる。

ツール系で「BiiCodeとCLion」 #kbkz_tech

kbkz.connpass.com

@y_think

C++ 03が出来た頃から業務アプリケーションを使っていた

CLion (アシカ)

• VisualStudio以外で初心者にすすめやすい
• いけてるツールは古典的なmakeコマンドでビルド出来るものが存在しない
• ビルドツール
• ホスティングサービスのようなもの

www.jetbrains.com

www.biicode.com

CLion * 有料

VS2015 * 一応フリー

Eclipse * あんまり人に勧められない

不遇の標準ライブラリ #kbkz_tech

kbkz.connpass.com

@Ryosuke839

• 画像認識とか機械学習の研究
• C++初心者
• 規格書暗記していない

valarray

• 可変長配列を実現
• vectorと被るんじゃね…
• 使われていない… include数は…本当に少ない…

これを無理して使おう…

• かなり無理して使っている。
• res.resizeは可変長だけど可変長じゃない

• ちゃんとunsignedにしないと演算子オーバーロードが解決しない
• 内積とか外積とか出来るし、sin cos exp logなどの関数を使えるんだけど、他の型に変換することは出来なかったりする…

なぜこのライブラリが存在するのか

• ベクトル化最適化が実装されていたFortranに対抗するために入れたのでは
• 現在ではCPUでもSSEなどのベクトル命令が実装されてる

ベンチマーク

コードは適当な奴。iccでコンパイルするとvectorの数倍速い。

valarrayはユーザーの中ではなくライブラリの中で使われるもので、EigenとかOpenCVとか使ったほうがいいのでは?

標準委員会で推してた人がやめたのでvalarrayがなし崩し的に入れられた。 valarray単体では他にも使いやすいライブラリあるけど、 これを使っているライブラリがあったりするので簡単に消せない…

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

kbkz.connpass.com

スコープを抜けたら自動でdelete

unique_ptrは便利

リソースを自動で解放 デリータも設定できる

リソースハンドルがポインタでなくてもよいのでは？

GTUのメモリバッファのハンドルとかソケットとかコモンオブジェクトとか

ハンドルをリリースしないといけないが、単に置き換えただけではコンパイルできない。

デリータの中でpointer型を指定

intとnullptrの比較が出来ずエラーに。。

でもどうしようもない…

しょうがないのでユニークポインタを使うのをあきらめて自分で型を書く。

めんどう。

• 例外安全性
• ムーブ
• リソース漏れ

• ハンドルごとに毎回書かないといけないのか…

• 任意の型のリソースハンドルに

• スコープを抜けたら自動で指定したデリータを実行してくれて
• ムーブできて

unique_resource

• 次期標準ライブラリに備えたやつ
• いつつかえるようになるの？ N4189にサンプル実装あるからコピペすればつかえる
• N4189のunique_resourceは、C++14コンパイラで使えたりする

まとめ

• unique_ptrはデリータをカスタマイズできるが、ポインタ型のハンドルしかもてない
• unique_resourceが非ポインタ型ハンドルの自動リソース管理のために提案されている
• N4189からコピペしたら使える

effective modern C++ Item37

リファレンスコードを積極的にGitHubにあげてて、規格書もTexで書かれていたりする

デリータとしてラムダを渡すだけで良い。

C++14だと生のポインタを使う必要がなくって、newもdeleteも必要なくなってきている。

ezoeさんのはなし メモ #kbkz_tech

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

必読。

C++の歴史を読むあたり。

B. Stroustrup: A History of C++: 1979-1991. Proc ACM History of Programming Languages conference (HOPL-2).
B. Stroustrup: Evolving a language in and for the real world: C++ 1991-2006. ACM HOPL-III. June 2007. (incl. slides and videos).
B. Stroustrup: The Design and Evolution of C++. Addison Wesley, ISBN 0-201-54330-3.

改良点。

モジュールは#includeに代わる機能。