Boost.勉強会#19東京 Effective Modern C++とC++ Core GuidelinesShintarou Okada
![クソザコ鳥頭が非順序連想コンテナに入門してみた](https://cdn-ak-scissors.b.st-hatena.com/image/square/bc0b3473cb53dece21f000434a0c71b40008b99c/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Frandom-151205062202-lva1-app6892-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
#include <thread> #include <chrono> #include <string> #include <iostream> /* * フツーの関数 */ void global_fun(int n) { using namespace std; cout << "global_fun: " + to_string(n) + " 秒後に終了します...\n"; this_thread::sleep_for(chrono::seconds(n)); cout << "global_fun: おしまい\n"; } /* * ラムダ式 */ auto lambda_exp = [](int n) { using namespace std; cout << "lambda_exp: " + to_string(n) + " 秒後に終了します...\n"; this_thre
を作りました。 http://github.com/tanakh/cmdline 何か コマンドライン引き数の解析を助けるライブラリです。同じ目的のライブラリに、Cの標準関数であるgetoptやgoogleのgflagsなどがありますが、cmdlineは適当に使えてそこそこ便利というのを目指しています。getoptは使いにくいし、usageも自分で書く必要がある。gflagsはライブラリをインストールしたり、リンクしたりちょっと大掛かり。cmdlineは、1ヘッダファイルで、コピーするだけで使えて、修正BSDライセンスで公開しているので、自由にプログラムに取り込んでいただけます。 コードサンプル #include "cmdline.h" int main(int argc, char *argv[]) { cmdline::parser p; p.add("hoge", 'h', "hog
C++ Advent Calendar 2015の5日目です。 前C++時代から近代C++に至るまで、ヘッダファイルの重複インクルード排除のために通称インクルードガードというものが使われてきました。 #ifndef YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H #define YOUR_VERY_VERY_AWESOME_LlBRARY_HEADER_H #endif // YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H しかしこれはファイルの前後に書かないといけないという制約や、他のヘッダとトークン列が一致してしまうと意図せずヘッダがインクルードされないという問題がありました。 これに対してたった1行で書いて終わりの#pragma onceは、標準化を求める声も多く、目的が明確で、実装もあるにも関わらず、標準に入る気配すら
Appleマクロの恐怖 - Faith and Brave - C++で遊ぼう Appleのクソヘッダーがcheckとかrequireとかverifyなどといった、あまりにも一般的すぎる単語をプリプロセッサーマクロで定義している問題。MSも、あの悪名高いminやmaxマクロを定義している。 最良の解決策は、そんなクソマクロを定義したヘッダーを使わないこと。 ところで、#2115 (Avoid bad Apple macros) – Boost C++ Librariesをみると、BOOST_PREVENT_MACRO_SUBSTITUTIONというものがあり、これを使えば、この問題を解決できるらしい。何と、そんな便利なものがあるのか。早く言ってよね。しかし、なぜか、"Perhaps sadly, I have to agree."と言われている。何故そんなに落ち込んでいるのだろうか。気にな
以前,トライと STL コンテナの比較をした際,std::map, std::tr1::unordered_map についてはメモリ使用量をちゃんと測っていなかったが,都合により,コンテナ本体のメモリ使用量を見積もる必要が出てきたので gcc 4.7 の実装を眺めてみた. 結論から言うと,gcc では std::map <_Key, _Tp> のメモリ使用量は, template<typename _Val> struct _Rb_tree_node { _Rb_tree_color; // ノードの色 (enum; int) _Base_ptr; // 親ノードへのポインタ _Base_ptr; // 左ノードへのポインタ _Base_ptr; // 右ノードへのポインタ _Val; // value_type (std::pair <const _Key, _Tp>) }; -> si
15. Visual Studio は 着実に C++11/14 に対応 2010. 4 2010 auto, move, nullptr lamdas, <random> 2012. 9 2012 Range-based for, enum class <chrono> , <ratio>. <thread> 2013. 6 2013 Preview Variadic templates initializer_lists, C++14 libs 2013. 9 2013 RC Non-static data member init defaulted / deleted functions 2013. 11 2013 2013 Q4 2013 + CTP constexpr, noexcept C++14 generic lamdas
目下手を入れているコードも相当古く、ビギナさんにオブジェクト指向を教えるべく継承と多態を"わざと"多用したサンプルです。C++での動的束縛(dynamic-binding)を説明するため、あちこちにポインタが現れあちこちでnew/deleteしています。多態を使いまくるコードでポインタの利用が増えてしまうのはある程度仕方のないことなのですが、決してnew/deleteしまくりたいわけじゃありません。ガベージ・コレクションをサポートしたC#/Javaの類ならnewしっぱなしで構わんけれど、C++ではnewしたものは必ず/明示的に/ただ一度だけ/確実にdeleteしてやらにゃなりません。ヒトは間違う生きもの、忘れる生きものなんだから、できることならnew/deleteしたくない。特にdeleteはやらずに済むならそれに越したことはないわけで...マクラが長くなりました、unique_ptrのお
C++標準ライブラリの文字列型 std::string*1 を、C言語インタフェースへの文字列取得バッファとして使う方法についてメモ。本記事の内容はStack Overflowで見つけた質問と回答に基づく。 2016-03-27追記:C++17(C++1z)対応版はこちら→文字列取得バッファとしてのstd::string リターンズ - yohhoyの日記 2013-08-30追記:C++03以前でも事実上「std::string 内の文字列バッファは連続したメモリ領域」といえる?C++ Standard Library Defect Report List #530 Must elements of a string be contiguous?、Cringe not: Vectors are guaranteed to be contiguousコメントも参照のこと。 まとめ: C++
はじめに これはC++ Advent Calendar 2012の21日目の記事です。 本当はスパコン環境でのC++とかODEintについて書こうかと思っていたのですが、時間がなくなってしまったので予定よりも軽めの内容にします。もしかしたらODEintについて追記するかもしれません。しないかもしれません。 ...というか書いてる途中で時間切れになったのでまた後で修正します(申し訳ない) さてこのCEANというのは何かというと、C/C++ Extensions for Array Notationsのことです。Array Notation。つまり配列の記述方法です。残念ながらC++標準では使えません。Intel Compilerでのみ利用できる拡張機能です。Intel Compiler 13で使えることは確認してます。 拡張機能、しかも文法上の拡張なので使うと他コンパイラとの互換性が無くなり
この記事は,C++プログラマであるかを見分ける10の質問 - Life like a clown の「抽象クラスとテンプレートクラスの使い分けについてインターフェースと言う観点から述べよ」に対する回答的な記事です. インターフェース的な基底クラスは,テンプレートで代替できる場合があります.例えば, class interface { public: virtual ~interface() {} virtual void do_something() = 0; }; void func(interface& x) { x.do_something(); } と言うインターフェース(的な)クラスを引数に取る関数 func() は,以下のように書く事でも実現できます. template <class T> void func(T& x) { x.do_something(); } さて.この
C++にはクラス内で自分の型を取得する直接的な方法がないという問題があり、そのためにtypedef X this_type;のようなことが行われていました。 C++11にはdecltypeがあるので、decltype(*this);で自分の型を取得できます。 ただし、decltype(*this)で導出される型はXではなくX&のため、std::remove_referenceしないといけないのであまり便利ではないのでした。 #include <iostream> #include <type_traits> struct X { void foo() { // decltype(*this)::bar(); // エラー!X&::bar()はできない std::remove_reference<decltype(*this)>::type::bar(); } static void bar
配列操作の比較表: Ruby, Python, JavaScript, Perl, C++ プログラムを書いていると、他のプログラミング言語の記憶とごっちゃになって、「配列の後ろに要素を追加するのは push だっけ、 append だっけ」などと混乱することがあります。特に Ruby, Python, JavaScript はコードの書き方が似ているので、この問題が起きがちです。 そこで、備忘録として、 Ruby, Python, JavaScript, Perl, C++ の配列操作の比較表を作りました。一番慣れている Ruby を基準にしています。間違いなどがあったらご指摘いただけると助かります。他の言語のもあるといいなあ。 Ruby (Array) Python (list) JavaScript (Array) Perl (@) C++ (std::vector)
文字列のハッシュをconstexprで計算できればC++で文字列を使ったswitchができるんだけどなあと思ったけど,mpl::stringならコンパイル時にハッシュ値の計算できたりしないだろうか. 2011-01-14 19:48:06 via P3:PeraPeraPrv 「なるほどー」と思ったので文字列のハッシュを使う実験。 #include<string> #include<iostream> constexpr int hash(char const * s) { return *s ? *s + hash(s + 1) : 0; // 超絶てけとーハッシュ } int main() { for(std::string s; std::cin >> s;) switch(hash(s.c_str())) { case hash("foo"): std::cout << "case
(2011/12/12 01:12) 副題: 「どうして char** を const char** に 代入できないの?」というFAQの無駄な深掘り 目次 char* は、const char* に代入できる。 char** は、const char** に代入できない。 char** は、const char* const * に代入できる。 char** は、char* const * に代入できる。 一般化してみよう。 (残念な)結論。 char* は、const char* に代入できる。 const char* x; char* y = 0; x = y; // OK ここまでは、直観どおり。 char** は、const char** に代入できない。 const char** x; char** y = 0; x = y; // NG: キャストが必要 VC++2010:
Boost.Optional Must Go - 野良C++erの雑記帳 Boost.Optional Must Go (2) - 野良C++erの雑記帳 最近、何回かに分けて、 Boost.Optional について、(細かい)不満を日記に書いてきました。 これは別に Boost.Optional が嫌いだから不満を書いた訳ではなく、むしろ その逆、 Boost.Optional が便利な分、逆に不満点が目立つので書いていたわけですが、 よく考えたら、 Boost.Optional の便利さを、纏まった記事で書いていないなー、 と、そう思い至ったので、この辺で Boost.Optional を徹底的に推奨する記事でも書いてみようかな、 というわけで、さんざん既出なネタばかりですが、折角なので書いてみることにしましたよ。 冒頭に挙げた以外で参考になるような記事は、この辺でしょうか: C++
マルチプラットホームライブラリを作ってみた。 ※リンク先pdf 有名なSEGA本の著者、平山さんによる今年のCEDECでの講演内容である。 ゲームプログラマになる前に覚えておきたい技術 作者: 平山尚出版社/メーカー: 秀和システム発売日: 2008/11/14メディア: 単行本購入: 112人 クリック: 3,473回この商品を含むブログ (193件) を見る 内容的には十分読み応えのあるのだが、一部釈然としないところもある。 主に4.9章の「標準ライブラリや言語機能について」というところから。 何故標準が嫌なのか ゲームプログラマはなぜかC++標準ライブラリを使わない。 いや、使おうとする人もいるが何かと理由をつけて使わない。 その理由が大体困ったような内容が多い。 リンク先でも書かれているが、vectorにはpush_back()やerase()がある。 そしてこれは安全性と性能の両
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" になる ユーザはこの手の短いマクロをよく使うため、この問題はよく発生しそうに見
札幌C++勉強会#2を開催しました。 OSCの時にも宣伝させていただいたこともあってか、多くの方に来ていただくことが出来ました。 参加された方々、ありがとうございます。 13:00〜13:15 準備 13:15〜13:45 開始、参加者自己紹介 13:45〜13:55 休憩(10分) 13:55〜14:25 セッション(Lapis)「Digest C++(仮)」 14:25〜14:45 休憩(20分) 14:45〜15:35 セッション(hotwatermorning)「例外安全入門」 15:35〜15:45 休憩(10分) 15:45〜16:15 セッション(H.Hiro)「C++のマクロはどこまで関数をいじれるのか(仮)」 16:15〜16:25 休憩(10分) 16:25〜16:45 LT、今後についての打ち合わせ 16:45〜17:00 片付け という予定でしたが、自己紹介の時間を
セミナーとか ・WebMatrix を使ってライブで作ろう! スマートフォン対応モバイル ASP.NET Web アプリ @jsakamotoさん。「オレのぐっときた」スマホアプリをライブコーディングでサクっと作る!坂本さんがとても輝いていました。 ・テスト駆動開発による安心開発 ー「もう何も怖くない」 @shuji_w6eさん。マミられないように注意したい。田舎からの参戦はなかなか難しいけど、TDDBootCamp行ってみたいなー http://www.slideshare.net/shuji_w6e/osc2011-hokkaido-tdd ・これからの「言語」の話をしよう ―― 未来を生きるためのツール @nobuhisa_kさん。ミスチル&DBネタを散りばめつつ、初級者向けの内容でF#の魅力(主に並列処理推し)について語る。終盤は質問コーナーも。そしてあのドンちゃんも反応。F#ファ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く