| | 276 | |
| | 277 | == C++の悪口を言う == |
| | 278 | |
| | 279 | === Discriminating hackers が選ぶ言語 === |
| | 280 | |
| | 281 | * ICFP 関数プログラミング学会が毎年プログラミングコンテストを開催 |
| | 282 | * 前回の優勝者 shinh &言語 C++ |
| | 283 | * よりにもよって手続き型の C++ が関数プログラミングの学会主催のコンテストで (ry |
| | 284 | * 今回は C++ & Haskell & Python だたーよ |
| | 285 | * C++ 担当して他のが tanakh さ |
| | 286 | * 俺だけは悪口を言う権利がある!! (tanakh さ) |
| | 287 | |
| | 288 | === 型 === |
| | 289 | |
| | 290 | * 同じ型を何度も書かされる。 |
| | 291 | * typedef 使え → 意味のない名前を考えなきゃいけない、名前空間も無駄に汚れる |
| | 292 | * 0x 使え (auto) → 0x 使わせて (゛;ω;`) |
| | 293 | * 読ませる気のないコンパイルエラー |
| | 294 | * 行番号しか参考にならん |
| | 295 | * gcc4.5 デフォルト型引数の省略などが入ったが… |
| | 296 | * そも型が大きいと意味がない |
| | 297 | * そも構造上の問題? |
| | 298 | * 型推論が非力 |
| | 299 | * そも型推論とは Type Reconstruction である |
| | 300 | * C++0x では、すべての型を推論できるわけではない |
| | 301 | * ○ローカル変数 (auto) |
| | 302 | * ○ラムダ式の返値 |
| | 303 | * ×関数の引数 |
| | 304 | * ×クラスメンバ |
| | 305 | * Hindly-Milner型の型推論が出来ない |
| | 306 | |
| | 307 | === テンプレート === |
| | 308 | |
| | 309 | * template の型パラメータは forall ではない |
| | 310 | {{{ |
| | 311 | template <class T> |
| | 312 | T id(T v) { return v; } |
| | 313 | }}} |
| | 314 | * 引数に対して任意の操作が可能 |
| | 315 | {{{ |
| | 316 | template<class T> |
| | 317 | void id(T v){ v.foo{}; } |
| | 318 | }}} |
| | 319 | * どういう型がつくのが妥当なのだろうか? |
| | 320 | * 実際には C++ ではテンプレート関数自体には型はつかない |
| | 321 | * C++ のテンプレートは何なの? |
| | 322 | * 見た目 structual な sub typing を実現している |
| | 323 | * sub type relation の解決をインスタンス時に各々行う |
| | 324 | * コンパイル時に型レベルでコードを実行するようなもの |
| | 325 | * その代償 |
| | 326 | * テンプレート関数を宣言時ではなく使用時にインスタンス化、それに対して型つけ |
| | 327 | * つまり |
| | 328 | * テンプレート関数を分割コンパイルできない |
| | 329 | * テンプレート関数自体には型がつかない |
| | 330 | * コンパイルエラーが意味不明に… |
| | 331 | * 分割コンパイルできない |
| | 332 | * コンパイル速度 ... 最悪の倍、コンパイル時間がファイル数の二乗のオーダーに |
| | 333 | * ファイル感の依存性 |
| | 334 | * pinpl のようなバッドノウハウ |
| | 335 | * 実行速度低下 |
| | 336 | * コードがまどろっこしい |
| | 337 | * ヘッダに書くことによる問題 |
| | 338 | * namespace地獄 |
| | 339 | * using namespace させて… |
| | 340 | * テンプレートに型がつかない |
| | 341 | * 型は非常によいドキュメントになるんだが… |
| | 342 | * 人がある程度注釈することは出来るが… |
| | 343 | * 今は亡きコンセプトさん… |
| | 344 | * テンプレート引数への要件の明示によるドキュメント性の改善 |
| | 345 | * インスタンス化->型チェックによらずに型チェックが出来るようになり、コンパイルエラーの改善 |
| | 346 | * コンセプトさえあれば… |
| | 347 | |
| | 348 | === 関数プログラミング === |
| | 349 | |
| | 350 | * オブジェクト指向+関数型 |
| | 351 | * すべてのものはオブジェクトであるべき |
| | 352 | * すべてのものは関数であるべき |
| | 353 | * 関数がオブジェクトであると言うこと |
| | 354 | * 関数につく型が凄くいびつに |
| | 355 | * 関数型ならシンプルなのに… |
| | 356 | * ラムダ式 |
| | 357 | * [](int x){ ... }(); ... とにかくキモイw |
| | 358 | * ラムダ式の型がいけてない |
| | 359 | * 関数の型 |
| | 360 | * function クラスを用いると簡単 |
| | 361 | * しかしパフォーマンス低下 |
| | 362 | * inline 展開されない |
| | 363 | * 単なるテンプレートパラメータが好まれている |
| | 364 | * たそう関数 |
| | 365 | * テンプレート関数の値 |
| | 366 | * 総称型がない |
| | 367 | * Boost.Lambda でのラムダ式 |
| | 368 | * 非常に分かりにくい型になってしまう… |
| | 369 | * パターンマッチ |
| | 370 | * カリー化 |
| | 371 | * 純粋関数的に状態を持ち回るのがとてもやりやすくなる |
| | 372 | * オブジェクト vs 関数 |
| | 373 | * 関数プログラミングでは次の状態として関数を返すことがよくある |
| | 374 | |
| | 375 | === まとめ === |
| | 376 | |
| | 377 | * まだまだ言いたいことはあるが… |
| | 378 | * C++ にも良いところはあるよ |
| | 379 | * 適当に書いてもそれなりに速い |
| | 380 | * 0x でそれなりに改善 |