サイボウズ・ラボの光成です。 今年の1月から『Effective Modern C++』（Scott Meyers）の読書会を社外の人を含めて月1回のペースで始め、先月末に無事最後まで終わりました。 その感想をざっと紹介いたします。 『Effective Modern C++』（以下EMCと略）はC++11/C++14で追加された様々な新しい機能について紹介する本です。 従って、C++の全くの初心者が読むには少々難しいと思います。以前のC++にある程度習熟した人が、新機能の注意点を勉強したいというときに使うとよいでしょう。 本には重要な間違いもいくつか指摘されていますので正誤表の確認はしておきましょう。 なおこの9月には日本語版（千住治郎訳）も登場しています。こちらは7月時点で原書に見つかっている正誤表が反映されていてうれしいですね。 C++11ではautoの型推論、typedefより高機

OpenCVで画像サイズを変更する方法２つ 直接比率を指定する方法 #include <iostream> #include <opencv2/highgui.hpp> #include <opencv2/imgproc/imgproc.hpp> int main(int argc, const char* argv[]) { // 入力画像 cv::Mat src = cv::imread("src.jpg", 1); if(src.empty()) std::cout << "not found" << std::endl; // 出力画像 cv::Mat dst; // 画像リサイズ cv::resize(src, dst, cv::Size(), 0.4, 0.4); cv::namedWindow("RESIZE", cv::WINDOW_AUTOSIZE); cv::imsho

C++14は、C++11に対するマイナーアップデートです。仕様のバグ修正や、C++11の比較的小さめな機能不足を補うバージョンになっています。 細かすぎる変更はさすがに書きませんが、ある程度大きめの変更を以下にまとめます。 この内容は、正式に策定されるまでに変更される可能性があります。 コア言語 2進数リテラル 変数テンプレート 通常の関数の戻り値型を推論 ジェネリックラムダ 一般化されたラムダキャプチャ constexpr関数の制限緩和 どこからともなく現れる結果の規定(前半, 後半) [[deprecated]]属性 数値リテラルの桁区切り文字 サイズ付きのデアロケーション initializer-listによるaggregate初期化の制約緩和 ロックフリーの定義 シグナルハンドラでできることの制限緩和と明確化 ライブラリ make_unique() コンパイル時整数シーケンス tu

が面白かったので書いてみた。 目的は、 one や twenty one をソースコードに直接書けるようにすること。 twenty one / three を 21/3 と解釈すること。 辺り。 念の為に書いておくと、何の役にも立たない。 version 1 -- operator() #include <iostream> struct numbase { int m; numbase( int m_ ): m(m_){} int value() const { return m; } virtual ~numbase(){} }; struct num : public numbase { num( int m_ ): numbase(m_){} }; struct ten : public numbase { ten( int m_ ): numbase(m_){} num oper

例外安全なコピー代入演算子を定義しようとしたとき， C++11 では Copy して Swap する方法 Copy して Move 代入する方法 の二通りが存在するので，それぞれのメリットとデメリットを比べてみた． Copy して Swap 昨日の記事で説明した方法． struct Hoge { std::vector<int> x, y; Hoge() = default; Hoge(std::vector<int> x_, std::vector<int> y_) : x(std::move(x_)), y(std::move(y_)) {} Hoge(Hoge const&) = default; Hoge(Hoge &&) = default; Hoge& operator=(Hoge rhs /*pass by val*/) noexcept { this->swap(rhs);

メモリリークに悩まされている技術者は多いだろう。メモリリークが嫌でGCという技術が開発されたといっても過言ではないし、歴史的にはC++からJavaへシフトが起きた大きな理由のひとつといっていい。Unix系の簡単な定義でいえば、ヒープ領域を指すポインタ（アドレス）をロストしてしまえばそのメモリはもう漏れたといってよい。たとえばこういったコードだ。 struct { int i; char c; } spam; int main(){ void* p; int i; for(i=0; i<1024; ++i){ p = malloc(sizeof(struct spam)); } pause(); } このコードではpause(3)の時点で約5KBのメモリが漏れている。free(3)を使えばメモリをOSに返却できるが、アドレスが分からないので返却できない。 ところが、ここでいいたいのは、メモリ

はじめに ちょっと、高次元特徴空間での2つの文字列の像の内積である文字列カーネルで遊んでみる。 文字列カーネルを類似度として使いたい。遊びなので、数式はちゃんと追ってない、、、 文字列カーネル 文字列に対するカーネル カーネルKは、入力空間Xから特徴空間Fへの写像φについて、x,y∈Xに対してK(x,y)=<φ(x),φ(y)>を満たす関数のこと 2つの文字列の距離的なものを考えるのに、共通する部分列や部分文字列を考えたもの いろんな考え方ができるので、いろんなものが存在する 部分列と部分文字列の違い 部分列(Subsequence) 記号列に対して、「並び」だけを保持した部分的な記号列 「abcde」に対して、「abd」や「be」や「bcde」など 長さがkの部分列は「k-merの部分列」という 部分文字列(Substring) 記号列に対して、「隣接性」と「並び」を保持した部分的な記号

はじめに 巨大な文字列でも高速にクエリ処理できる噂の木を、挙動を確認するため作ってみた。 コード アルファベット(a〜z)の文字列を扱う場合 完備辞書の操作が愚直、ビット列がvector 本を参考にしたけど、2か所間違ってる？ #include <iostream> #include <vector> #include <queue> #include <cmath> //top_kのためのタプル struct ST { int t; size_t st, en; ST(int t, size_t st, size_t en):t(t),st(st),en(en){} }; bool operator<(const ST& a, const ST& b){ return (a.en-a.st) < (b.en-b.st); } //アルファベット([a-z]+)用のウェーブレット木 cla

この記事は、C++ Advent Calendar 2012: 17日目の記事になります。 お題は「Google Test ユーザーが Boost.Test を使ってみた」です。 (2012/12/27: 補足記事を書きました。) これまで、C++ の testing framework には Google Test を使ってきたのですが、 この機会に Boost.Test に挑戦したいと思います。 今年２月に行われた「Boost.勉強会 #8 大阪」の参加報告で Boost.Test 使うぜ！っと意気込んでおいて今更かという感じではありますが・・・ では、なぜ今まで使わなかったのかというと boost の導入がめんどくさそう 日本語情報が少ない Google Test が使いやすかった と、いう勝手なイメージがあったからです。最後のが一番大きな理由でした。 でも、他のフレームワークのこと

高次元の特徴量を持ったベクトルの集合に対して，与えられたクエリベクトルに似ているものを探し出すという問題を，近傍探索とかいう．旧来のkd-treeあたりを使った探索ではなく，近似的に近いベクトルを探す近似近傍探索が流行っている（らしい）．近似近傍探索のひとつ，LSHの説明を読んでたら「これ案外簡単に実装できるんじゃね？」と思い至ったので，C++11で書いてみた． LSHについては以下の説明がとても分かりやすい． 060108 Locality-Sensitive Hashingの実装が一段落 - 飛行船通信 - Seesaa Wiki（ウィキ） 他には以下を実装の参考にした． lsh p-stable 最近のバイナリハッシングをいくつかJavaで実装してみた - るびゅ備忘録 Locality Sensitive Hashing - (setf yaruki nil) - nlpyutor

C++標準のIOStreamには、std::unitbufフラグというのがあります。これを出力ストリームに設定することで、繰り返し出力を行う処理で、出力するたびにフラッシュが行われるようになります。 #include <fstream> int main() { std::ofstream file("a.txt"); file << std::unitbuf; for (int i = 0; i < 10; ++i) { file << i; // 出力するたびにフラッシュされる } } これは、以下のコードと同じ意味になります： #include <fstream> int main() { std::ofstream file("a.txt"); for (int i = 0; i < 10; ++i) { file << i; file.flush(); // 自分でフラッシュする

はじめに 前回（Node.js で C++ アドオンから EventEmitter のイベントリスナを呼ぶ - 凹みTips）、C++ のネイティブモジュールから EventEmitter を利用して JavaScript 側で定義したイベントリスナを呼ぶ方法を紹介しました。ただ Node.js はシングルスレッドベースの非同期処理を行っているため、このイベントリスナを呼ぶ過程のどこかで重い処理を行うと、全体の処理がブロックされてしまいます。また、これを避けるために、子スレッドを作成して処理が終了したら JavaScript のイベントリスナを呼ぶ、としようとしても、別スレッド内から Node.js の走るスレッドの v8 の世界へ直接アクセスすることが出来ないため、イベントリスナを呼ぶことができません*1。 そこで、libeio / libev に代わって Node.js のコアとして置

C++11 async tutorial Posted on October 17, 2012 by Paul For a few years now, we live in a multiprocessor world, starting from the phone in my pocket to the parallel quad-core beast I have on my table. Today, you could easily buy a six or twelve core machine that is several orders of magnitude more powerful than the super computers from a decade ago. As programmers, we need to be able to use at ful