社内LT#1 至高のイケメン言語C++について

Preview:

DESCRIPTION

12新卒同期向けの社内LTで発表した内容。5分の制限時間にも関わらずスライド作りすぎてgdgdでした。

Citation preview

菅原 源一郎

至高のイケメン言語 C++ について~ 最強伝説 ~

菅原 源一郎といいます

自己紹介

C++ 好き好き

この LT の目的

C++ 愛好派の拡大

実際に使わなくても良いので、「あー、 C++ ?良い言語だよねー」って

言ってください

詳しくは wikipedia で! http://ja.wikipedia.org/wiki/C++

C++ ってなんだ?

組み込み系ゲーム開発画像処理株や為替など、シビアなレイテンシが求められるシ

ステムWeb 系でも局所的にパフォーマンスが欲しい場面で

C++ を使うのは良くある話

どこで使われるの?

とにかく速いよ!効率的だよ!パフォーマンスの問題で「 C++ じゃなきゃダメ」

はあっても「 C++ 以外じゃなきゃダメ」はほぼない

有名なソフトウェア , システムに多数実績あり

なにがスゴいの?

ゼロオーバーヘッドの原則

使わない言語機能がパフォーマンスに悪い影響を及ぼすことはない

C 言語と同等以下のオーバーヘッドで動作可能というか C 言語とアセンブリレベルで一致する  ( 一部のコストの高い言語機能を除く )テンプレートを使っても最適化でゼロコストになる

ことも多い

ゼロオーバーヘッドの原則

とにかく、とってもコスト意識の高い言語だと

思っていてください

最適化がスゴい

例えばイテレータfor (std::vector<int>::iterator it = v.begin(); it !=

v.end(); ++it) { ... }

最適化されるとポインタ演算に成り下がる (=アドレス比較ループになる)つまり配列の添字アクセスより速くなる

なお、 debug_iterator では遅い代わりに エラーチェックが入ります

強力な静的型付けOOP ( 仮想関数 , 多重継承も可 )テンプレート演算子オーバーロード例外処理名前空間アロケータ強力なライブラリ群 (STL, Boost)

イケてる特徴

#include <iostream>

int main(){

std::cout << "Hello, World!" << std::endl;return 0;

}

Hello World ! !

「名前空間」

ostream という「クラス」

「演算子オーバーロード」「参照」「関数ポインタ」

「 const char* 」

…… ?

Q. 人気あるの?

A. あるよ (2012 年 04 月現在 )

http://www.tiobe.com/index.php/content/paperinfo/tpci/

Q. ライブラリはどんなもの

があるの?

A.STL と Boostこの 2 つで大体事足ります

STL は C++ の標準ライブラリ

Boost は C++ 標準化委員会のメンバーが立ち上げた、オープンソースライブラリ

STL文字列型動的配列キュー(両端 , 優先順位付)リスト(単方向 , 双方向)集合連想配列(二分木 , ハッシュ)スタックイテレータ(前方 , 双方向 , ランダムアクセス)ファンクタ

Boost スレッド マルチインデックスコンテ

ナ 文字列と数字の相互変換正規表現 , 構文解析 メモリプール スマートポインタ Flyweightネットワーク・非同期 IO ファイル・ディレクトリ操作 XML, INI, JSON の読み書

シリアライズ共有メモリ乱数 ベクトル・行列・線形代数無名関数・クロージャ タプル 双方向マップ循環バッファ侵入式コンテナ 単体テスト

なんでもあります

弱点?

嘘です。見栄張りました

ダメなとこもあります

テンプレートを使ったプログラムで、

コンパイル通らなかった時

/home/kik/include/boost/fusion/functional/invocation/invoke.hpp: In static member function ‘static typename boost::function_types::result_type<Function>::type boost::fusion::detail::invoke_mem_fn<Function, Sequence, 8, false>::call(F&, Sequence&) [with F = void (expr::*)(int_lit, peg::sor, open_paren, op, expr&, const expr&, close_paren), Function = void (expr::*)(int_lit, peg::sor, open_paren, op, expr&, const expr&, close_paren), Sequence = const boost::fusion::joint_view<const boost::fusion::single_view<expr*>, const boost::fusion::vector<token<int_lit_s>, peg::sor, token<peg::chr<peg::chr_range_constraint<'(', '('> > >, token<op_s>, expr, expr, token<peg::chr<peg::chr_range_constraint<')', ')'> > >, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >]’:

/home/kik/include/boost/fusion/functional/invocation/invoke.hpp:178: instantiated from ‘typename boost::fusion::result_of::invoke<Function, const Sequence>::type boost::fusion::invoke(Function, const Sequence&) [with Function = void (expr::*)(int_lit, peg::sor, open_paren, op, expr&, const expr&, close_paren), Sequence = boost::fusion::joint_view<const boost::fusion::single_view<expr*>, const boost::fusion::vector<token<int_lit_s>, peg::sor, token<peg::chr<peg::chr_range_constraint<'(', '('> > >, token<op_s>, expr, expr, token<peg::chr<peg::chr_range_constraint<')', ')'> > >, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_> >]’

peg.hpp:228: instantiated from ‘bool peg::pi::parse_fun(Fun, T&, Input&, Input) [with Fun = void (expr::*)(int_lit, peg::sor, open_paren, op, expr&, const expr&, close_paren), T = expr, Input = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]’

エラーメッセージが意味不明

…… ?

よく心が折れます

あと、基本的に

C++ とは忌み子であり仇花でありレガシーでありそしてやはり、そこから生み出される物もまた、クソの山になりがちであるというのはどうやら確からしい。学習という側面においても、数百ページにも及ぶ経典を何巻も読破し、膨大な量の術式を自ら書き、疲れ、疲れ果て、目は乾き、指は震え、他の言語に浮気をし、その素晴らしさに震え、打ちのめされ、しかしまた不屈の怨念により C++ の場に舞い戻りというような試練

を乗り越えることでようやく、最低限は使えるという段階になるのである。

学習コストが高め

アンサイクロペディア「 C++ 」よりhttp://ja.uncyclopedia.info/wiki/C++

メモリリーク

この言葉自体最近のライトな言語にはない……?

GC がないので、うっかり解放忘れするとどんどんメモリにゴミが溜まっていく

もちろん多重解放でも死ぬ即死はせずに、しばらく稼働した後にゆるやかに死ぬケースが多いので原因を探るのに苦労する

違うコンパイラでビルドしたライブラリをリンクしようとするとエラーが出る

よって、新しいライブラリを使おうと思ったら自分でソースからビルドする必要がある

コンパイラがアップデートするたびにアプリケーションとライブラリ全体を再コンパイルする羽目に

コンパイル済コードを使う ABI がない

褒めて褒めて褒めまくるはずだった

のに……

そんな感じで色々問題はありますが

速さには犠牲がつきものです

実際のところ、C++ もどんどん進化してるので

メモリ管理はかなり楽になってます

今時、生のポインタでメモリ管理する C++er

は悪い C++er です

スマートポインタstd::unique_ptr, boost::shared_ptr などstd::unique_ptr<int> ptr( new int() ); のように

使う

new したものを必ず手動で delete する、なんて前時代的

むしろ手動の delete が含まれているコードは、その時点で既に間違ってると思って良いくらい

これで、使われなくなった領域は自動解放されます

しかも GC より遥かに効率的

進化する C++

C++11

2011 年時点での ISO 標準C++0x なんて呼ばれてましたさっきの std::unique_ptr も C++11 から導入型推論 , foreach, move, ラムダ式 , 標準ライブラ

リの拡張など

ただ、その仕様全てにキチンと対応したコンパイラが 2012 年 4 月現在でまだ存在しなかったりする

「 C++ の連中は他の全てをなげうって性能に取り憑かれている」

なんて言われる

大体あってる

それでも性能が欲しいんだ!

VM 言語 , スクリプト言語派との戦争は続く……

何度も言うけど C++ オススメですよ

最後に書籍紹介

書籍紹介 (1)

ロベールの C++ 入門講座 Effective C++ 原著第 3版

書籍紹介 (2)

C++ の設計と進化 C++ Coding Standards―101 のルール、ガイドライン、ベストプラクティス

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

Recommended