C++メモリモデルにおける フェンス(fence) とatomic変数／非atomic変数の関係についてメモ。 まとめ： C++11標準ライブラリが提供するstd::atomic_thread_fence関数*1は、atomic変数アクセスに対してのみ意味をもつ。通常の非atomic変数には直接的な影響を与えない（間接的には影響を与えうる）。 C++の文脈における「フェンス(fence)」は、言語仕様を記述する仮想機械(abstract machine)上の同期プリミティブにすぎない。フェンス同士またはフェンス＋atomic変数操作間で「happens before関係」が定義され、直接的にはそれ以上の効果を持たない*2。 上記より、具体的なアーキテクチャ／コンパイラが提供するメモリバリア(memory barrier)*3とは解釈が異なる（ことが一般的なはず）。例：gcc/x86アーキテ
プログラミング言語Javaでは const をキーワードとして予約しているが、Java SE 7現在でも何ら特定の機能を持たない*1。（恐らく将来に渡って現状のままと予測される） 1999年時点でJDK 1.2.0に対する機能拡張要求 BugID:4211070 Java should support const parameters (like C++) for code maintainence が挙がったが、この要望は 対応意向なし(Won't Fix) としてクローズされた。 It's possible, but I would rather hold the line on creaping featurism. One can design around this (using interfaces, wrappers etc.). There are no current p
C++11標準ライブラリやBoost.Threadライブラリで提供されるcondition_variable_anyとrecursive_mutexの組み合わせについてメモ。 まとめ：condition_variable_anyとrecursive_mutexの組み合わせ利用は避けること。*1 *2 条件変数condition_variable_anyのwaitメンバ関数仕様では、指定されたロックオブジェクトに対して1度だけunlock操作を行う。同関数に対して2回以上lock操作されている(ロックカウント > 1)再帰ロックオブジェクトを指定した場合、該当ロックは解放されない(ロックカウント != 0)まま関数を呼び出したスレッドAはブロック状態に遷移する。この状況では別スレッドBでのロック獲得要求もブロックされるため、プログラム全体としてはデッドロックに陥る。 condition_va
2012年現在のC言語コンパイラでもK&R Cソースコードを扱えるか試したのでメモ。*1 結論：gccとMSVCはK&R Cソースコードでもコンパイル可能。 /* K&R style C */ int printf(); int add(); main(argc, argv) int argc; char** argv; { printf("1+2=%d\n", add(1, 2)); return 0; } add(x, y) { return x + y; } gcc系 gcc 4.7.1, 4.6.3にて正常にコンパイル＆実行可能なことを確認*2。 $ gcc input.c -fno-builtin$ gcc input.c -fno-builtin -Wall -W -Wextra input.c:5:1: warning: return type defaults to 'in
C99で追加された浮動小数点数比較マクロについてメモ。同機能はC++11においても提供される。 比較マクロとそれに対応する比較演算の一覧。組込みの比較演算子では浮動小数点数例外(floating-point exception)が発生する可能性があるが、比較マクロでは決して浮動小数点数例外が発生しない。 マクロ 比較演算 isgreater(x,y) x > y isgreaterequal(x,y) x >= y isless(x,y) x < y islessequal(x,y) x <= y islessgreater(x,y) x < y || x > y isunordered(x,y) 少なくとも一方がNaN C99 JTC1/SC22/WG14 N1256 7.12.14より引用（下線部は強調）。 The relational and equality operators s
標準入出力ストリーム(cin, cout等)の入出力先を一時的に変更するヘルパクラス。 std::ifstream("input.txt"); ioredirector rd0(std::cin, ifs); std::string s; while (std::getline(std::cin, s)) /* input.txtから1行読込 */; // coutへ出力... 標準出力へ // cerrへ出力... 標準エラー出力へ { std::ofstream ofs("log.txt"); ioredirector rd1(std::cout, ofs), rd2(std::cerr, ofs); // cout/cerrへ出力... "log.txt"へ } // cout/cerrの出力先は元通り 実装： #include <ios> template <class E, cl
C11標準ライブラリ、C++11標準ライブラリ、POSIXスレッドのスレッドライブラリ(Pthreads) API比較。 各スレッドライブラリAPIを、“スレッド”、“CallOnce”、“排他制御(mutex)”、“条件変数(condition variable)”、“TLS(Thread Local Storage)”、その他機能に分類して比較する。表記簡略化のためC++11標準ライブラリは名前空間stdを省略している。 概略： C11はISO/IEC JTC1/SC22/WG14 N1570、C++11はISO/IEC JTC1/SC22/WG21 N3337、POSIXはIEEE Std 1003.1-2008に基づく。 C11標準ライブラリとPOSIXスレッドライブラリのAPI体系はほぼ同一。*1 C++11標準ライブラリはC11標準ライブラリ提供のスレッドサポート機能を包含し、
プログラミング言語CおよびC++の標準規格（ドラフト）に存在していたジョーク文。 atomic操作ライブラリ記述箇所に下記脚注あり。*1 Atomic objects are neither active nor radioactive. Among other implications, atomic variables shall not decay. 関連URL JTC1/SC22/WG21 N2427 C++ Atomic Types and Operations JTC1/SC22/WG21 N3118 C++ FCD Comment Status, CA16 JTC1/SC22/WG14 Defect Report #404 *1:おまけ：atomic=原子力の, radioactive=放射性の, decay=放射性崩壊
Javaプログラム上で高機密性情報（パスワード文字列など）を扱う場合、セキュリティ的にはjava.lang.Stringクラスよりchar型の配列char[]の方が好ましい。 Java言語の文字列Stringインスタンスは不変(Immutable)なオブジェクトであり、メモリ上からデータ破棄されるタイミングはGCに依存する。一方char[]ならばプログラマがメモリ上でのデータ存在期間を制御できる。 関連URL java - Why is char[] preferred over String for passwords? - Stack Overflow Java Cryptography Architecture(JCA) Reference Guide: Using Password-Based Encryption, パスワードベース暗号化の使用
C++11で導入されたautoによる型推論とrvalue参照(T&&）に関するメモ。 auto&&による型推論の結果が常にrvalue参照型となるとは限らない。 int x; auto t0 = x; // t0はint型 auto& t1 = x; // t1はint&型 auto&& t2 = x; // t2はint&型（int&&型ではない） auto&& t3 = std::move(x); // t3はint&&型 auto v0 = 42; // v0はint型 auto& v1 = 42; // v1はint&型 → 42はprvalueのためill-formed auto&& v2 = 42; // v2はint&&型 変数t2では “reference collapsing” によって int& && → int& 型となる。 関連URL Session Topic:
GCC 4.7から実験的サポートが始まったTransactional Memory(TM)についてメモ。 主に "Draft Specification of Transactional Language Constructs for C++, Version 1.1"*1 で定義される拡張キーワードのsyntaxサポート確認を行った。 TMサポートの有効化 GCC 4.7.0でTMサポートを有効にするには、オプション -fgun-tm を指定する。またTMサポートはC++11／C11メモリモデルを前提とする機能であり、旧来のC++03／C90モードでTMを利用することは無い（はず）。 $ g++ -std=c++11 -fgnu-tm input.cpp $ gcc -std=c11 -fgnu-tm input.cTMサポートを有効化した生成バイナリは、ランタイムライブラリ libit
C++言語における引数を取らない関数のパラメータリスト。f1とf2の関数シグネチャは同一。 int f1(); int f2(void); int (*pf)(void) = f1; // OK int (&rf)() = f2; // OK パラメータリスト中でvoid型を使えるのは“空のパラメータリスト”を表す場合のみ。 int h(int, void); // NG: void int g(int, void*); // OK: void* N3337 8.3.5/p4, C.1.7より該当箇所を引用。 If the parameter-declaration-clause is empty, the function takes no arguments. The parameter list (void) is equivalent to the empty parameter
C++11でムーブもコピーもできないオブジェクトを扱う方法についてメモ。（エッセンスのみ。詳説は元記事を） 実は C++0x では、こういう「コピーもムーブも出来ないオブジェクト」であっても、 uniform initialization を使えば、関数から返すことができるようになったのです： person make_charactor() { return { "Chiffon Schroedinger", 14 }; } これを行うには、「該当するコンストラクタが explicit 指定されていないこと」という条件こそありますが、コピー出来る／出来ない、ということに関しては、特に条件はありません。 http://d.hatena.ne.jp/gintenlabo/20101211/1292088788 Uniform initialization＠return文＋rvalue refe
C++11メモリモデルと、atomic変数relaxedメモリ操作で起こりえる "Thin-air read" への対策について。 注意：本記事は内容を理解して書いたわけでなく、関連情報の単なるメモ。 "Thin-air read"（または "out-of-thin-air value"）は定式化されたメモリモデルで起こりえる、存在しない値*1のreadを許容する動作。（後述N3132のサンプルコードが分かり易い） C++11メモリモデルやJavaメモリモデルでは共に "Thin-air read" を禁止している。Javaでは複雑なメモリモデル定義によって対処し、C++11では（Javaに比べて）単純なメモリモデル定義＋禁止条項の追加にて対処している。 (PDF)N3132 Mathematizing C++ Concurrency: The Post-Rapperswil Modelよ
C++11で新たに追加されたnullptrキーワード（→id:yohhoy:20120503）利用促進のため、gcc 4.7から新しい警告オプション -Wzero-as-null-pointer-constant が追加された。 C++ A new command-line option -Wzero-as-null-pointer-constant has been added to warn when a literal '0' is used as null pointer constant. It can be useful to facilitate the conversion to nullptr in C++11. http://gcc.gnu.org/gcc-4.7/changes.html
C++11言語仕様において、どのようなコンストラクタが “コピーコンストラクタ”／“ムーブコンストラクタ” とみなされるのかについてメモ。 コピーコンストラクタ 第1引数にX&, const X&, volatile X&, const volatile X&のいずれかをとる非テンプレートなコンストラクタ。第2引数以降が存在する場合はそれらにデフォルト引数指定がなされていること。一般的にはX::X(const X&&)とする*1。 ムーブコンストラクタ 第1引数にX&&, const X&&, volatile X&&, const volatile X&&のいずれかをとる非テンプレートなコンストラクタ。第2引数以降が存在する場合はそれらにデフォルト引数指定がなされていること。一般的にはX::X(X&&)とする*2。 N3337 12.8/p2-4より引用。 2 A non-templat
条件変数(condition variable)同期プリミティブに対する待機／通知で発生する現象と回避策のメモ。 条件変数とミューテックスを使ったコードにおいて次のような現象が生じる。 スレッドAが条件変数cvに対して通知を行う。 条件変数cvに対してブロックされていたスレッドBのブロックが解除される。ただし、ミューテックスmtxはスレッドAにロック保持されたままのため、再びスレッドBはミューテックスmtxに対してブロックされる*1。 スレッドAがミューテックスmtxのロックを解放する。 ミューテックスmtxに対してブロックされていたスレッドBがブロック解除され、同ミューテックスのロック獲得に成功する。 #include <pthread.h> int data = 0; // 待機条件: 非0になるまで待機 pthread_mutex_t mtx; pthread_cond_t cv;
C++11で新たに導入されたnullptrキーワードおよびstd::nullptr_t型に関するメモ。 まとめ： nullptrキーワードはヌルポインタ定数を表すポインタリテラル。C++03以前の値0, マクロNULLとは別に新たに追加された。 nullptrの型はstd::nullptr_t型と定義されるが、ユーザプログラム中でstd::nullptr_tを直接利用することはまず無い。 おまけ：C/C++言語の両者においてマクロNULLは処理系定義のヌルポインタ定数。 C++03以前からある特例ルール「値0はヌルポインタ定数としても扱う」に起因するオーバーロード問題を解消するために導入された。 void f(int); // [A] int型 void f(char*); // [B] char*型 // C++98/03 f(0); // 0はint型リテラルとみなされ[A]が呼ばれる
C++11標準ライブラリで新たに追加された排他制御ライブラリ／標準ヘッダ<mutex>と、Boost.Threadライブラリ 1.49.0の比較一覧表。 C++11とBoost.Threadライブラリでは、いくつかのLockable要件(requirements)*1を定義し、各種Mutex型およびLockオブジェクトを提供する。 Lockable要件 排他制御(mutual exclusion)として機能する型に対する要件。特定の型を指すわけではない。例えば「ロック獲得操作を行うlockメンバ関数とロック解放操作を行うunlockメンバ関数を有する」など。 Mutex型 Lockable要件を満たす、実際に排他制御として機能する型。どのLockable要件を満たすかに応じて異なる型が提供される。 Lockオブジェクト RAIIイディオムによって確実にロック解放操作を行うためのオブジェクト
局所的に「スレッド開始を遅延させる」ネタが盛り上がっていたので、C++とBoostライブラリを用いた色々な実装方法をまとめてみました。 この記事で対象とするのは、下記コードにある2つの要件を満たす実装方法です。 (1) スレッドを管理するオブジェクトXのコンストラクト時ではなく、その後の任意タイミングで新スレッド処理を開始する。 (2) オブジェクトXのデストラクト時に、上記(1)の別スレッドがまだ実行中ならそのスレッド処理完了を待機する。 class X { // threadオブジェクトを保持するメンバ変数 void do_() { /* 別スレッド処理 */ } public: ~X() { // (2) 別スレッドがまだ実行中なら完了を待機する } void start() { // (1) 新しいスレッドを開始して関数do_を実行する } }; int main() { X x;
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く