C90, C99, C11, C++98, C++11で異なる動作をするコード | POSTD
(訳注：2016/9/28、頂きましたフィードバックを元に記事を修正いたしました。) C言語の規格のリビジョン間には微妙な違いがありますが、このことを利用して「C90、C99、C11のどれとしてコンパイルされたかどうかにより、違う挙動をする」というプログラムを作ることが可能です。同様に、C++はほぼC言語の上位互換ですが、C言語とC++で違った結果を生み出すプログラムも存在します。 これは2015年の International Obfuscated C Code Contest (難読Cコード・国際コンテスト)への Don Yangの投稿 において、 C89、C99、C11、C++98、C11のどれとしてコンパイルされるかによって異なる出力を生成するプログラムを作成するのに使われています。C90の場合は、以下のような星形を出力します。 **************************
C++11での自作アロケータに必要な最小コード - Faith and Brave - C++で遊ぼう
C++11では、std::allocator_traitsというアロケータアクセスの中間インタフェースが用意されたおかげで、自作アロケータに必要な実装がだいぶ減りました。 自作アロケータに必要な最小コードは、以下のようになります。 要素型value_type 特殊関数(デフォルトコンストラクタ、コピーコンストラクタ、ムーブコンストラクタ) 別な要素型のアロケータを受け取るコンストラクタ allocate()メンバ関数。(hintパラメータはあってもなくてもいい) deallocate()メンバ関数 operator==とoperator!= サンプルコード： #include <new> template <class T> struct MyAllocator { // 要素の型 using value_type = T; // 特殊関数 // (デフォルトコンストラクタ、コピーコンスト
C++11ですみやかにプログラムの実行を終了する方法
結論：C++11で新しく追加されたstd::quick_exitを使え。 プログラムの終了は、すみやかに行われるべきである。なにしろ、終了なのだ。終了にもたついていてはストレスがたまる。とくに、多くの実行環境では、プログラムの外部から、プログラムを強制終了させる方法がある。強制終了は大抵、プログラムの意志を無視して、強制的に一瞬で行われる。外部からできるのであれば、内部からできてしかるべきである。 なぜプログラムは終了時にもたつくのか。それは、終了時に特別な処理を必要とする場合もあろう。たとえば、数GBものデータを遅いHDDに書きださねばならない場合もあるだろう。これは妥当な理由である。では、確保したメモリやその他のリソースの解放処理はどうか。これは、疑問である。というのも、多くの近代的なOSでは、プログラムは個々に独立している。プログラムには独自の仮想メモリ空間が与えられ、必要に応じて物
C++11時代のthreading - fjnlの生存記録のような何か
始めに 本記事は C++11 Advent Calendar 2011 : ATND の6日目です。 std::thread C++11時代のthreadの基本は std::thread です。おもむろに #include をしましょう。std::threadはコンストラクタで渡された関数オブジェクトを別スレッドで実行します。 #include <iostream> #include <thread> void f() { std::cout << "f()" << std::endl; } int main() { std::thread thr(f); thr.join(); return 0; } このプログラムを実行すると f() と表示されるはずです。コンパイルして実行してみます。 $ g++ -o thr thr.cpp -std=c++0x $ ./thr f() $ 確かに
本の虫: decltypeの訓練
こんにちは、脳内に優れたC++0xコンパイラをインストール済みのみなさん。今回は、あなたの脳内コンパイラが規格準拠かどうかを、さらにテストしてみましょう。 まずは、decltypeの決まりごとからです。優秀なみなさんのことですから、decltypeの決まりごとぐらい、当然暗記しているのは分かっていますが、念のために引用しておきます。 The type denoted by decltype(e) is defined as follows: — if e is an unparenthesized id-expression or a class member access (5.2.5), decltype(e) is the type of the entity named by e. If there is no such entity, or if e names a set of
Elements of Modern C++ Style
“C++11 feels like a new language.” – Bjarne Stroustrup The C++11 standard offers many useful new features. This page focuses specifically and only on those features that make C++11 really feel like a new language compared to C++98, because: They change the styles and idioms you’ll use when writing C++ code, often including the way you’ll design C++ libraries. For example, you’ll see more smart poi
本の虫: なぜC++0xの正規表現は、ECMAScript準拠なのか
Boostの正規表現ライブラリで使われている正規表現の文法は、Perl 5を参考としている。一方、C++0xに入る、正規表現の標準ライブラリは、ECMAScript準拠（プラスちいさな拡張機能）である。 オプションで、POSIXのbasic、またはexntended、それに加えて、grepの拡張機能に準拠した文法を使うこともできるが、POSIX規格は、常にLeftmost Longest ruleであり、Non greedy repeatsができないので、grepのようなツールならともかく、プログラミング言語の中で使う正規表現としては、貧弱である。 しかし、TR1は、Boostを参考に作られたはずである。なぜ、違うのか。 Perlの正規表現は、Javascriptプログラマから見ると、少々羨ましい機能がある。特に、independent sub-expressions, zero widt
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" になる ユーザはこの手の短いマクロをよく使うため、この問題はよく発生しそうに見
C++0x in programming competition
Presented at Open Source Conference 2011 Nagoya on 2011/8/20.
C++0xが国際標準C++11へ。 - Faith and Brave - C++で遊ぼう
cppllとboostjpに送ったメールですが、こちらにも再掲します： == ついに ねんがんの 国際標準をてにいれたぞ!： C++0x、全会一致で承認される C++0xが満場一致で国際標準として承認されました。 やりました！ 日本からも全員が賛成票を出していました。 さて、C++11の仕様が固まってこれから大きな変更はないでしょうから、 そろそろC++11の解説サイトやリファレンスを整備していかなくてはいけません。 cppll, boostjpのコミュニティで集合知としてのリファレンスサイトを作っていきたいと考えています。 私の方でGoogle Sitesのcpprefjpを作成し進めているのですが、人手不足でなかなか進んでいない状況です。 cpprefjp - C++日本語リファレンス この活動に興味を持ち、コアメンバとなってくれる方を募集しています。 C++11が広く使われて欲しいと
We have an international standard: C++0x is unanimously approved Sutter’s Mill
[Update: “C++11” is now the confirmed name — Geneva informs me that they plan to have it published in a matter of weeks, and then we’ll have ISO/IEC 14882:2011(E) Programming Languages — C++, Third Edition. The second edition was C++03, a Technical Corrigendum, or bug patch, that contained no new features. This is the first major revision with new features.] The final ISO ballot on C++0x closed on
C++0xの落とし穴を埋める改良
聡明なC++0xプログラマである読者諸君ならば、もう、以下のコードは、C++0xでは、疑いようもなくwell-formedであることを知っているだろう。 // C++03ではill-formed // C++0xではwell-formed vector<vector<int>> v ; 従来、連続した>は、>>演算子と、文法上曖昧であるので、かならず>>演算子だと解釈されるようになっていた。C++0xでは、このような場合、演算子と解釈されることはなくなった。もちろん、分かりやすさから言えば、空白文字を挟んだ方が分かりやすいだろう。 vector< vector< int > > v ; 何にしても、このようなちょっとした落とし穴は、初心者を無用に混乱させる。、C++0xでは、このようなちょっとした落とし穴がいくつも塞がれている。 さて、ここまでが前振りで、ここからが本番である。以下のコード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - neobrain/cftf: Clang from the Future: A C++17 to C++11 source-to-source compiler
http://japan.internet.com/column/developer/20081209/26.html