cpp libraries
DESCRIPTION
XP Festa 2008 Lightning TalksTRANSCRIPT
最近の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はこちらの思考法も行ける!?)
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に変革期がきているみたいですよ
ご清聴ありがとうございました