Cpp Libraries

最近のC++ライブラリを使ってみた

XP祭り 2008 ライトニングトークス2008-09-06 (Sat)

伊藤 浩一株式会社 永和システムマネジメント

自己紹介

伊藤 浩一 (http://www.edit.ne.jp/~koic)

株式会社 永和システムマネジメント

Computer Programmer

Guitarist, Composer, Arranger

話題に残ることは最初に

北米デビューを果たしました

http://www.slideshare.net/fkino/practices-of-an-agile-team-542565

http://www.slideshare.net/fkino/practices-of-an-agile-team-542565

ちょwwwww おまwwwwww

北米アジャイル界デビュー

fkinoからは何も聞いてませんでした

話題に残らないけど最初に

Web 2.0 ビギナーズバイブル

エンジニアマインド vol.5

開発の現場 vol.011

これまでに書いたもの

お買い求めはお早めに

過去のドラ強制終了率勝ち 負け

1勝5敗 圧倒的敗率

過去のトークス

敗北

1勝5敗 圧倒的敗率敗北 敗北

敗北 敗北

勝利

まとめ

いまGoogleとIntelが熱い

ご清聴ありがとうございました

表題の件についてくわしく

最近のC++ライブラリを使ってみた

XP祭り 2008 ライトニングトークス2008-09-06 (Sat)

伊藤 浩一株式会社 永和システムマネジメント

TDD (Be Agile that my attitude)

Google Test

Intel (次世代コア)

Intel Threading Building Blocks

a.k.a TBB

お品書き

TDDerははじめにテストありき

「テストを受け入れて、天国でリファクタリングを待つか。」

「テストを受け入れず、デバッガの中で彷徨い続けるか。」

「現世のコードを呪い殺し、地獄へ逝くか。」

人間とコンピュータの狭間テストの門

Which do you Choose?

「テストを受け入れて、天国でリファクタリングを待つか。」

「テストを受け入れず、デバッガの中で彷徨い続けるか。」

「現世のコードを呪い殺し、地獄へ逝くか。」

我々が選んだ道

C++テスティングフレームワーク探し

決定への道のり

探索、判断、決定

テスティングフレームワークの比較

素振りは大事

三角測量

探索の視点

少ないコード量

不必要に高くない学習曲線

簡潔な記述

読みやすさ

ツールとしてのカッコよさ

比較材料C++ Java Ruby

standard

alternative

CppUnit JUnit Test::Unit

Google Test

RSpec

まず標準を素振った 記述することが多くてつらいなあ。。。

リフレクションやGCのない制約はでかい

ゆとり育ちには、動的言語プラットフォームと同じリズムでレッド、グリーン、リファクタリングができる自信が持てない ><

プログラマの三大美徳

怠惰短気傲慢

ここはクリアしたい

少ないコード量

不必要に高くない学習曲線

簡潔な記述

読みやすさ

ツールとしてのカッコよさ

2008年7月Google Testリリース

喰い付いた

Google Test

2008年7月発表 (http://google-opensource.blogspot.com/2008/07/google-test-come-try-our-google-c.html)

New BSD Licence (http://www.opensource.org/licenses/bsd-license.php)

xUnitアーキテクチャをベースとする

素振った感想

テストを書く量が、(C++にしては)比較的少ない

比較的、xUnitと同じリズムでレッド、グリーン、リファクタリングができる

精神的なLOC

0

17.5

35.0

52.5

70.0

Example1 Example2 Example3

CppUnit Google Test

ここはクリア

少ないコード量

不必要に高くない学習曲線

簡潔な記述

読みやすさ

ツールとしてのカッコよさ

押しの一手

少ないコード量

不必要に高くない学習曲線

簡潔な記述

読みやすさ

ツールとしてのカッコよさ

カッコよさ属性はヤバい

生産性3倍伝説

生産性10倍伝説

カッコいい

カッコいい道具は使っていて楽しい

Dave “達人” Thomasも云ってたよ

http://jp.rubyist.net/RubyKaigi2007/?c=plugin;plugin=attach_download;p=Program0610;file_name=the_island_of_ruby_j.pdf

今回採択したものC++ Java Ruby

standard

alternative

CppUnit JUnit Test::Unit

Google Test

RSpec

Standardとオルタナティブ Standard

xUnit

枯れた思考法

Google TestはxUnit Architecture Base

オルタナティブ

xSpec (GTestはこちらの思考法も行ける!?)

Google Testhttp://code.google.com/p/googletest/

Based on the xUnit architecture

Example Codes

class QueueTest : public testing::Test {protected: virtual void SetUp() { q1_.Enqueue(1); }

Queue<int> q1_;};

TEST_F(QueueTest, DefaultConstructor) { EXPECT_EQ(1, q1_.Size());}

TEST_F(QueueTest, Map) { MapTester(&q1_);}

テストケースとマクロ

テストメソッドはマクロ テストケースには、SetUp/TearDownの他フィ

クスチャや便利メソッドのみ用意

テストメソッドはTESTマクロとして提供

TESTマクロはテストケースの外に書く

テストメソッドの追加、変更がある場合はcppファイルのTESTマクロのみ変更

ヘッダファイルは変更不要！

テストのFixtureを複数コンテキストに分けれる

xUnit?

むしろxSpec?

ちょっと妄想の世界に

従来型思考法

プロダクトコードとテストコードが1対1

テストコードの振る舞いごとにフィクスチャを用意しようとすると涙目

xUnitアプローチ

コンテキスト

プロダクトコード

test_*が異なる状態を期待する場合コンテキストの分別にひと工夫

test_x

test_ytest_z

テストケース

1対1

先進型思考法 振る舞いの種類毎に、オブジェクトの状態

(Fixture, Context) を用意できる

TestCaseクラス（フィクスチャ）と振る舞いを検証するメソッド（test_*）の分離

これからの時流？

xSpecアプローチ

コンテキスト

コンテキスト

振る舞いの種類毎に、オブジェクトの状態 (Fixture, Context) を用意できる

プロダクトコード

1対多

フィクスチャ

フィクスチャ

色々と妄想中

Google Test中心となる構成要素をざっくりと一巡り

includeファイル Google Testを使う宣言“gtest.h”

#include <gtest/gtest.h>

Test Runner testing::InitGoogleTest

RUN_ALL_TESTS()

実行のエントリポイントとしてリンク#include <iostream>

#include <gtest/gtest.h>

int main(int argc, char **argv) { std::cout << "Running main() from gtest_main.cc\n"; testing::InitGoogleTest(&argc, argv); return RUN_ALL_TESTS();}

Test Fixture Class testing::Testクラスを継承

メンバ変数をTEST_Fマクロで直接利用できる

Setup/TearDown #include <gtest/gtest.h>

class QueueTest : public testing::Test {protected: virtual void SetUp() { q.Enqueue(1); }// (中略) Queue<int> q;};

Test Method (1/2) TEST

testing::Testクラスに非依存

TEST(MyString, ConstructorFromCString) { const MyString s(kHelloString); EXPECT_TRUE(strcmp(s.c_string(), kHelloString) == 0); EXPECT_EQ(sizeof(kHelloString)/sizeof(kHelloString[0]) - 1, s.Length());}

Test Method (2/2) TEST_F

testing::Testクラスに依存

TEST_Fマクロの第一引数に指定

testing::Testクラスのメンバ変数をマクロ内で直接利用できる

TEST_F(QueueTest, DefaultConstructor) { EXPECT_EQ(0, q.Size());}

Assertion (1/2) EXPECT_*マクロ

非致命的なアサーションアサーションに失敗してもTEST続行 (実績のあるアサーションから迅速なレポートを得る)

EXPECT_EQやEXPECT_TRUEなどなど

TEST_F(QueueTest, DefaultConstructor) { EXPECT_EQ(0, q.Size());}

Assertion (2/2) ASSERT_*マクロ

致命的なアサーション

アサーションに失敗するとそのTESTは中止 (他のTESTは実行)

EXPECT_*と同じバラエティ

TEST_F(QueueTest, DefaultConstructor) { ASSERT_EQ(0, q.Size());}

Advanced Predicate Assertion

Death Tests

Assertions in Sub-routines

Logging Additional Informationなどなど

百聞は一見にしかず

人生は一瞬の連続なのだだから歩みなさい

誰の足だ？ てめえの足だろ̶大槻 ケンヂ

インストール ${srcdir}/configure

make

make check

sudo make install

アンインストール

道を引き返すのも大事

間違いに気づいたなら、やり直せばいい

sudo make uninstall

状況を開始せよ 我々はプログラマである

ストレスの少ないツールを

プログラマの美徳に合ったツールを探し

状況を開始せよ

xSpec的なテスティングの思考法も身に付けておくといいよ

さて、まだ時間はありますね？

IntelThreading Blocking Blocks

http://www.threadingbuildingblocks.org/

TBBについて話すよ

コアの変革

マルチコア利用の速度比較

TBBを使った一例

今また、コアの変革期 シングルコア

マルチコア

Many Core

ホモジニアス・コア

ヘテロジニアス・コア

マルチコア利用の速度比較

Core 2/Duoを使ったデータの処理

STL

TBB

1.169秒

0.810335秒

サンプル

#include "tbb/parallel_sort"#include <math.h>

using namespace tbb;

const int N = 100000;float a[N];float b[N];

void SortExample() { for (int i = 0; i < N; i++) { a[i] = sin((double)i); b[i] = cos((double)i); } parallel_sort(a, a + N); parallel_sort(b, b + N, std::greater<float>());}

サンプルでは割愛してますがTBB利用のスレッドでは、task_scheduler_init宣言を忘れずに

parallel_*など

詳しくは公式ドキュメント参照

おわりに

プログラマの三大美学

継続できる道具選び

状況を開始せよ

今、CPUに変革期がきているみたいですよ

ご清聴ありがとうございました