C++11: Syntax and Feature
C++11の文法と機能(C++11: Syntax and Feature) Copyright (C) 2013 江添亮. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GN
C++11 スマートポインタの話 - ここは匣
C++にはガーベジコレクタが言語的には存在しないので、動的に確保したオブジェクトのメモリの管理はプログラマが責任を持って管理しなければ、メモリリーク・リソースリークなどの問題を生じてしまいます。 今時のプログラマはこうした問題を引き起こすリスクを減らす為に、記述ミスの起こりやすい生のポインタを使い自力でnewとdeleteを記述する事を避けて、安全なスマートポインタ、即ちオブジェクトの寿命により自動的にメモリ解放を行う便利なポインタを利用するべきです。 しかし、スマートポインタと言っても種類が幾つかあり、落とし穴も存在するのでどういった状況でどれを利用するのが良いのかを考察してみます。 Dynamic memory managementを見てみても C++11から随分増えていますね http://en.cppreference.com/w/cpp/memory std::auto_ptr
C++プログラマのレベル10
レベル0 C++とかいう、Cにヘンテコな機能を付け加えた言語があることはしっているが、ワケ分からんので勉強する気にならない。 Cの何が不足なのか分からない。 C++についてググったり、入門書を読んだりしてみる。文法はCに後から無理やり付け加えた感じだ。 でも文法がわかりにくすぎる。 レベル2 vectorとか便利すぎて涙がでる。もういちいちrealloc()を呼び出さなくてもいいんだ。でもイテレーターとかいうのが、ワケ分からんので、ポインタを使っている。 構造体の中に関数を書けるのは便利かもしれない。すくなくとも、わざわざ構造体のポインタを引数に渡さなくてもいいわけだ。 レベル3 テンプレートが分からなくて挫折中。テンプレートがわかれば、STLがもっと分かるようになる気がする。でも、いい参考書が見つからない。 継承とか仮想関数も便利だと気がつく。namespaceも地味に便利だ。 レベル4
C++コミュニティーの中心でC++をDISる
Boost.勉強会4にて発表した内容です。http://atnd.org/events/11551Read less
たのしいHaskellのツールチェインとC++ - 純粋関数空間
というタイトルで、先日、社内の公開セミナーで話しました。 発表資料はこちら。 Haskellのテストフレームワークとベンチマークフレームワークがよくできているので、 これをC++でも使えるんじゃないかという内容です。 概要 背景として、QuickCheck をもっと多くの人に知って/使って貰いたいというのがあります。 QuickCheckは、普段から使っている人間からすると、よくいろいろなバグを拾ってくれるとても便利なものなのですが、 残念ながら普段開発に利用しているC++には相当のもので完成度の高いものが見当たりません。 だからといって、そこから作るためにC++のテンプレートをいじくりまわすには、私はもう老いてしまいました （与えられた関数にランダムな入力を与えるだけなら簡単なのですが、ジェネレータを自由にいじれる機能がやはり欲しいところで）。 そう思った時に、FFIを使えてQuickC
C++03 と C++11 の互換性 - melpon日記 - HaskellもC++もまともに扱えないへたれのページ
C++03 と C++11 ってどれぐらい互換性があるのかなーと気になっていたんだけど、仕様書の §C.2 を見てみたらずばりなものが載っていたので、一通り読んでみた。 C++03 のコードを C++11 として動かそうとしたときにコンパイルエラーやランタイムエラーが発生したら、これを確認してみるといいかも。 新しい文字列リテラル R, u8, u8R, u, uR, U, UR, LR という新しい文字列リテラルが追加されたため、文字列と一緒にこれらのマクロを使った場合、互換性の無いコードになる可能性がある。 例えば以下のコードは互換性の無いコードである。 #define u8 "abc" const char* s = u8"def"; // C++03 なら "abcdef"、C++11 なら "def" になる ユーザはこの手の短いマクロをよく使うため、この問題はよく発生しそうに見
Compiling OpenCV code on a 64-bit mac
I recently inherited some OpenCV code. I installed openCV on my mac, built in in XCode, and then compiled and successfully ran my first openCV "hello world"-ish program. Now I'm trying to run the code I was given, but I get errors that lead me to believe it's an issue with the original code being run on a 32-bit Windows system and mine being on a 64-bit Mac. When I run the Makefile by entering "ma
StringPiece というライブラリの話 - 兼雑記
例えばこう、ディレクトリの名前とその中のファイル名を / でくぎって結合する関数を書くとします。引数が std::string でも使いたいし const char* でも使いたい、ということで、たいていは void JoinFilePathStr(const string& dir, const string& base, string* out) { out->clear(); out->append(dir); out->push_back('/'); out->append(base); }なんてのを書くんじゃないかと思います。この関数で問題になるのは const char* を渡すと不要な string object が一度できることで、敬虔な C++ 屋さんだと、 void JoinFilePathStr(const string& dir, const char* base,
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cppreference.com
map vs. hash_map in C++
http://atnd.org/events/21936