文字列取得バッファとしてのstd::string リターンズ - yohhoyの日記
C++1z(C++17)標準ライブラリの文字列型std::basic_string<charT>クラステンプレートでは、ポインタ型charT*を返す 非const版 dataメンバ関数が追加される。（ポインタ型const charT*を返すconst版dataメンバ関数はC++98から存在している。） まとめ： C++98/03標準ライブラリでは仕様による保証が無いものの、実用上は&buf[0]を利用できる。*1 C++11/14標準ライブラリでは&buf[0]を利用する。 C++1z標準ライブラリでは&buf[0]またはbuf.data()を利用する。 下記例のようなレガシーAPIに対して、配列の代わりにstd::stringオブジェクトを文字列取得バッファとして渡す方法。 // バッファsにNUL終端文字列を取得（size＝バッファ長） // 戻り値：バッファに格納された文字数(NUL
文字列取得バッファとしてのstd::string - yohhoyの日記
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/C++のStrict Aliasingを理解する または - どうして#$@##@^%コンパイラは僕がしたい事をさせてくれないの！ - yohhoyの日記
元記事：Understanding C/C++ Strict Aliasing, or - Why won't the #$@##@^% compiler let me do what I need to do!, Patrick Horgan氏 訳出メモ： 自分自身の理解のために日本語訳を行ったStrict Aliasing Rules解説記事。 訳文中では "aliasing/alias", "strict aliasing rules", "type punning" をそのまま表記する。直訳すれば "別名（エイリアシング）", "厳密な別名規則", "型もじり（言い換え）" となる。 ところで、何が問題なの？ strict aliasing rulesに関しては多くの混乱が見られます。人々を混乱させる主要因となっているのは、aliasingに言及する2種類の異なるグループ; コンパ
条件変数とspurious wakeup - yohhoyの日記
条件変数(condition variable)同期プリミティブにまつわる "spurious wakeup" についてメモ。 安定した対訳語が存在しないようなので、本記事ではそのまま英語表記とする*1。spurious は “偽の; 疑似; 似非” といった意味の単語であり*2、wakeup は “条件変数で待機していたスレッドがブロック解除されて実行再開する”（＝寝ていたスレッドが起きる）ことを意味する。 まとめ： spurious wakeup は、「条件変数での待機(wait)処理において、何もしていないのにブロック解除される現象」を指す。ライブラリ内部実装やハードウェア／OSの都合といった、同期プリミティブの利用者から関与できない原因によって生じる。その発生頻度は特に言及されないが、一般的には低確率でしか生じないはず。 spurious wakeup に対応するため、条件変数での
タイムアウト付き待機関数とspurious wakeupの微妙な関係 - yohhoyの日記
C++11標準ライブラリの条件変数std::condition_variableおよびstd::condition_variable_anyは仕様上 spurious wakeup を許容する（→id:yohhoy:20120326）。このため条件変数のタイムアウト付き待機関数wait_until, wait_forの動作において、「通知を受けていないしタイムアウトもしていないがスレッドのブロックが解除される」という、プログラマの望まない（しかし規格に準拠した）状況が発生しうる。 #include <mutex> #include <condition_variable> int user_cond = 0; std::mutex mtx; // 変数user_condの保護 std::condition_variable cv; // 待機条件の達成(user_cond!=0)を通知 /
本当は怖いfuture+promiseの話 - yohhoyの日記
C++11標準ライブラリのstd::future＋std::promiseクラス利用に関して、不適切な使用パターンに起因するやっかいな不具合についてメモ。 この不具合はマルチスレッドプログラムの未定義動作(undefined behavior)により引き起こされる。下記例のように一見関係ないコード箇所のバグとして検出される場合もあるが、試験等でバグ検出されずに潜在化することも十分ありえる（実運用でデータ破損や突発クラッシュなどを引き起こす）。 c++ - race-condition in pthread_once()? - Stack Overflow c++ - Non-obvious lifetime issue with std::promise and std::future - Stack Overflow まとめ： （future/promiseに限らず）オブジェクトのライフ
（翻訳）良性データ競合は有害である - yohhoyの日記
元記事：Benign Data Races Considered Harmful | Corensic, Bartosz Milewski氏, 2011/6/7 自分自身の理解のために日本語訳を行ったC++11でのデータ競合に関する記事。（タイトルはいわゆる"〜 Considered Harmful"ネタ） 良性データ競合は有害である 最近、本ブログで大いに論争を巻き起こした良性データ競合（訳注：同記事の拙訳）に関する一連の投稿があり、また多数のディスカッションが行われました。2つの陣営が形成され、一方はデータ競合は良性たりえないと主張し、他方はデータ競合はパフォーマンスを得るために必要だと主張しています。そしてデータ競合の定義すらも合意できていないと分かりました。特に、C++11での定義は従来の概念からは逸しているようです。 データ競合っていったい何？ まず初めに、議論の対象を明確にしま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
