メモリモデル？なにそれ？おいしいの？ - yohhoyの日記（別館）
この記事はC++ Advent Calendar 2014の21日目にエントリしています。 内容はC++メモリモデルと逐次一貫性についての概説記事となっています。 flickr / nomadic_lass もくじ 忙しい人のための「C++メモリモデル」 C++メモリモデル一問一答 ソフトウェアからみた「C++メモリモデル」 “メモリ”という共有リソース C++ソースコードが実行されるまで メモリの一貫性と整合性 逐次一貫性モデル is Easy ハードウェアからみた「C++メモリモデル」 ハードウェア・メモリ一貫性モデル C++コンパイラの責任と自由 強いメモリモデル vs. 弱いメモリモデル 逐次一貫性モデル is Hard （本文のみ約9600字） まえがき When your hammer is C++, everything begins to look like a thumb
C/C++11 mappings to processors
This document summarises some known mappings of C/C++11 atomic operations to x86, PowerPC, ARMv7, ARMv8, and Itanium instruction sequences. These are collected for discussion, not as a definitive source. At the moment, we do not include mappings for all atomic operations - for example, atomic increment is missing. We would be grateful for any suggestions. ARMv8 has additional instructions: stores
Faith and Brave - C++で遊ぼう
cppmix.connpass.com 2025/07/18(金)に開催します。 これまで2ヶ月ごとの開催でしたが、3ヶ月ごとに変更になっています。 cppmix.connpass.com 次回のC++ MIXは2025/04/25(金) 19:00〜21:00に開催します。発表、ご参加お待ちしております。 cppmix.connpass.com 次回のC++ MIXは、2025/02/21(金) 19:00-21:00に開催します。 発表、ご参加お待ちしております。 www.boost.org boostjp.github.io Boost 1.87.0がリリースされました。 リリースノートはいつものように日本語訳したものをboostjpサイトで公開しています。 cppmix.connpass.com 2024年12月20日 (金) に、C++ MIX #12 を開催します。 会場都合で
テンプレートの実体化の実装方法とODR違反について
問題 以下のC++コードを考える。 int plus( int a, int b ) { return a + b ; } double plus( double a, double b ) { return a + b ; } このC++コードは、int型とdouble型以外、コードはほぼ同じである。 しかし、ほとんどのコンピューターではint型とdouble型は操作方法が異なるため、この2つの関数は、全く別のコンピューターが処理できるコードに変換される。 ところで、古典的なC言語やC++コンパイラーの実装方法として、ソースコードのファイルをそれぞれ、一つ一つの翻訳単位としてコンパイルし、翻訳単位ごとにオブジェクトファイルを生成し、リンカーで複数のオブジェクトファイルを結合（リンク）して、単一のプログラムを生成するというものがある。 よくある実装では、オブジェクトファイルは、その翻訳単位
C++ Name Mangling/Demangling
C++ Name Mangling/Demangling Archived Document This document is no longer current. For an excellent, more recent discussion, see Agner Fog's Calling Conventions for different C++ compilers and operating systems. Standard C++ Example The Annotated C++ Reference Manual documents one name mangling scheme. Gnu C++ The name mangling scheme seems to be based on the one in the C++ Reference Manual, and i
C++ sequenced-before graphs
17th September 2014 i = i++ This expression, and many like it, demonstrate the sequencing rules of C++ and how they can cause your program to behave in ways you might not expect. What should the result of this expression be given some initial value for i? Questions like this are extremely frequent on Stack Overflow. In this case, the answer is that this code is completely undefined — it could do a
分割コンパイルとリンケージ
| 分割コンパイルと翻訳単位 | extern記憶クラス指定子 | リンケージ | オブジェクトモジュールとライブラリ | 演習問題 | ［付録］nmコマンド | 分割コンパイルと翻訳単位 だんだん複雑なプログラムを開発するようになると ソーステキストが長くなり，一つのソースファイルで作成していると 全体を見通すのが難しくなってきます． またほんの一部だけを修正をしたときにも 全体をコンパイルし直さなければならないので， コンパイルに時間がかかるようになります． よって，プログラムをいくつかの部分に分けて 別々に開発したいという要求が自然に起こってきます． このような考えからプログラミング言語には 一つのプログラムを複数に分割できる機能が提供されることが多く， そのような各部分のことを一般にはモジュールと呼びます． C言語ではモジュールは翻訳単位と呼ばれ， おおまかには一つのソースファイル
constexprとrvalue参照問題 - とくにあぶなくないRiSKのブログ
constexprとメンバ関数の呼び分け問題 小ネタ - constexpr の文脈でconstメンバ関数と非constメンバ関数を呼び分ける - ボレロ村上 - ENiyGmaA Code このエントリで指摘されているように、constexprとメンバ関数の呼び分け問題があります。一時オブジェクトはconst修飾されていないために、constexprであるconst修飾メンバ関数が呼ばれないのが原因です。 template<typename T> struct X { T t; T& get() { /* 非const版 */ return t; } constexpr T const& get() const { /* const版 */ return t; } }; template<typename T> constexpr auto get(T&& t) -> decltype(
C++11 tuple implementation details (Part 1)
In his "Variadic Templates are Funadic" talk at GoingNative 2012 Andrei Alexandrescu outlines a "recursive" implementation of std::tuple. He also notes that most implementations arrange tuple members in memory in the "wrong" order, that is, std::tuple<int, double, std::string> will have a memory layout where the std::string comes first and the int comes last. The straightforward recursive implemen
C++勉強会in広島プレゼン資料
Pythonの処理系はどのように実装され，どのように動いているのか？ 我々はその実態を調査すべくアマゾンへと飛んだ．
本の虫: 邪悪なC形式のキャストにしかできないこと
注意：邪悪で汚らわしいC形式のキャストは、いやしくもC++プログラマたる者は、使うべからず C++では、玉虫色のC形式のキャストの機能を、三つに分割した。static_cast、reinterpret_cast、const_castである。しかし、この三種のキャストでは、C形式のキャストを完全に代替できないという声をよく聞く。曰く、「どうしても書けないキャストがある」と。 それはよく聞く話だが、では実際にどのようなキャストなのかということは、誰も審らかにしない。誰も知らないキャストであれば、特に使えなくても問題ないはずだ。ただし、「C形式のキャストならばできるキャストが、新しいキャストを組み合わせてもできない。どんなキャストかは知らないが、とにかくできないと聞いている。故に新しいキャストはクソだ」などという論調で、C++の改良されたキャストを使わぬC畑の外道がしゃしゃり出てくるのも困る。そ
C++0xの新機能、finalとoverride
gcc 4.7は、finalとoverrideを実装している。 finalとは、クラスの派生と、virtual関数のオーバーライドを禁止するための機能である。 struct B final { } ; struct D : B { } ; // エラー struct C { virtual void f() final { } } ; struct D : C { void f() { } // エラー、C::fはオーバーライドできない } ; これ以上説明する必要がないくらいに分かりやすい機能だ。現実的には、最底辺の基本クラスのvirtual関数のオーバーライドを禁止にするということはない。なぜならば、それは普通の関数とほぼかわりないからだ。あえて言えば、派生クラスで、同じシグネチャの関数を定義できなくする程度の意味しかない。大方、以下のような目的に使われるだろう。 struct A {
constexpr アルゴリズムの実装イディオム その１ - ボレロ村上 - ENiyGmaA Code
中３女子です。 今回は、constexpr におけるアルゴリズムの実装法について考える。 よく知られているように、constexpr 関数には言語規格上の制約が多くある。 ローカル変数が使えない、if や for などの制御構文が使えないなどは、C++11 に触れた者なら誰でも知っているだろう。 だが、それらは条件演算子や再帰によって、単純に代替できる問題である。 つまり、非 constexpr な実装に対して、処理の流れを本質的に変えることなく constexpr に書き換えることができる。 単純に書き換えられる例: template<typename T> T const& runtime_min(T const& a, T const& b) { if (b < a) return b; return a; } template<typename T> constexpr T con
C++11 時代のクラス設計に関する提案 - 野良C++erの雑記帳
先日，ついに C++11 の主要な機能を一通り実装した GCC-4.8.1 がリリースされた． もう一方の主要な C++ コンパイラである Clang++ でも C++11 の機能は既に全て実装されており， 来る 6/05 に最新版の Clang-3.3 がリリースされ， C++11 対応が完了する見通しだ．*1 このような状況においては， C++11 への乗り換えを検討し始めているプロジェクトも多いことだろう． さて， C++11 では， C++98/03 との互換性を保ちつつ，クラス設計に大きな影響を齎す変化が採用された． すなわち， Move Semantics である． この登場により， C++11 で「良い」とされるクラス設計は， C++98/03 時代とは若干 異なったものとなる． そこで，この記事では，筆者が C++11 において「良い」と考えているクラス設計を提案してみたい
代入演算子のエレガントな定義方法と，その不満点 - 野良C++erの雑記帳
ユーザ定義されたクラスに対して 代入演算子を定義する場合， コンパイラの生成するデフォルトの代入演算子では，例外安全の強い保証を満たせない場合がある． struct Hoge { std::vector<int> x, y; Hoge() = default; Hoge(std::vector<int> x_, std::vector<int> y_) : x(std::move(x_)), y(std::move(y_)) {} }; int main() { Hoge a = {{1, 2, 3}, {4, 5}}; Hoge b; try { b = a; // 例外安全の強い保証を満たせない // なぜなら，この操作は // b.x = a.x; // b.y = a.y; // と同じであり， b.y = a.y; で例外が投げられた場合 // b.x は代入されたが b.y は
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
uguu...
o m o i k a n e s e r i k a g a l l e r y 2025-04-19 omoikane@uguu.org
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Is gcc wrong not diagnose narrowing conversions in non-type template arguments?
カスタムメモリマネージャと高速なメモリアロケータについて
WIESS Paper