本ページでは「new/delete によるメモリの動的管理」について解説する。 malloc/free によるメモリの動的管理 (C 言語) new/delete によるメモリ管理に触れる前に、 「第二回-04 : メモリとポインタ」で取り扱った malloc/free による動的メモリ管理の復習をしておこう。 この手法は C 言語で主に用いられるもので、実は C++ で使われることはあまりない。 ここでは new/delete への導入として malloc/free について触れる。 まず、char 型のポインタ *p を定義し、そのポインタの指す先に要素数 SIZE=255 個の char 型の配列を確保することを考えよう。 「第二回-04 : メモリとポインタ」で取り扱ったように、これは なる命令で実現出来る。この際、ヒープ領域というメモリ領域から領域が確保されるのであった。 なお、
C++で副作用のない無限ループを書くと未定義動作になります。 「未定義動作」というのは口に出すだけでC++プログラマーを震え上がらせる力を持った言葉です。「鼻から悪魔が出てくる」という言葉で説明されるように、未定義動作を含むコードを実行した結果は何も保証することができず、バグの発見やデバッグすら困難にさせます。未定義動作下においてはコンパイラの気分によってコード片が消え、trueとfalseが同時に成立し、タイムトラベルを引き起こします1。 そのためC++ではうっかり未定義動作が埋め込まれないよう注意が払われるのが普通です。 さて、以下のC++のコードは未定義動作を引き起こします。 下の例は実際にclang/LLVMで最適化を有効にしてコンパイルするとでたらめな値を返す関数ができました。 この話をしたところ、何人かに驚かれたり異論を受け取ったりしたので、この話題について少しまとめてみました
プログラミング言語であるC言語およびC++言語に関して、よく聞かれる125の質問（FAQ）と、その解答です。
とても賢いコンパイラーの逆襲
The Hacks of Life: The Dangers of Super Smart Compilers Clangの最適化が未定義の挙動を検出してコード片を消し去ってしまったことに引っかかった開発者の嘆き。 今日初めて、RenderFarmのDSF render(global scenaryを作成するのに使っている内部ツール)をClangで最適化コンパイルして実行した。 結果はsegfaultだった。これは驚きだ（そして自身消失だ）。というのも、最適化していないデバッグビルドは問題なく動くし、GCCでコンパイルされた最適化ビルドも正しく動く。-O0ではバグがない（つまり#if DEVコードのバグではない）ので、「最適化は何をやっているんだ」の時間だ。 大量のprintfと試行錯誤の結果、最適化は以下のようなコード片を丸ごとすっ飛ばしていることが判明した。 for(vector<me
2013-10-10 MSのあまりにもひどいマクロ maxとかminとかが使えないと思ったらminwindef.hとかいうところでマクロとして定義されていてキレそうっていうかこれは完全にブチギレ— 秋弦めい (@maytheplic) October 10, 2013 http://stackoverflow.com/questions/5004858/stdmin-gives-error StackOverflowにも同じような事言ってる人が居たので引用。 どうやら以下のようなコードがエラーになるらしいです #include <algorithm> #include <Windows.h> int main() { int k = std::min(3, 4); return 0; } error C2589: '(' : illegal token on right side of
gccとclangのC++0xサポートの比較
C++0xの規格はほぼ固まり、もはや変更されることはない。恐らく、このまま規格制定されるものと思われる。さて、今C++の主要なコンパイラーを上げるとすると、gccとclangをおいて他にはない。MSVCはオモチャだ。右の両コンパイラーは、C++0xの新機能を実装し始めている。もちろん、まだ不完全な実装も多いが、とりあえず遊べる程度には実装できている機能も多いので、比較してみることにする。 gccのC++0xサポート状況は、以下のページに簡易な一覧がある。 C++0x Support in GCC - GNU Project - Free Software Foundation (FSF) clangのC++サポート状況は、以下のページに簡易な一覧がある。 Clang - C++ and C++'0x Status 面白いことに、どちらか片方のコンパイラーでしか実装されていない機能が、結構あ
Clang: a C language family frontend for LLVM The Clang project provides a language front-end and tooling infrastructure for languages in the C language family (C, C++, Objective C/C++, OpenCL, CUDA, and RenderScript) for the LLVM project. Both a GCC-compatible compiler driver (clang) and an MSVC-compatible compiler driver (clang-cl.exe) are provided. You can get and build the source today. Feature
Clang ([ˈklæŋ]：クランのように発音[5]) は、プログラミング言語 C、C++、Objective-C、Objective-C++ 向けのコンパイラフロントエンド（英語版）である。OpenMPディレクティブ[6]や、OpenCL C/C++カーネル言語[7]も正式サポートしている。バックエンドにLLVMのコンパイラ基盤を使用しており、LLVM 2.6以降はLLVMのリリースサイクルに組み込まれている。 Clang/LLVMベースの派生プロジェクトとして、RenderScript（英語版）、CUDAのNVCC[8]、ROCm（英語版）のHIP-Clang[9]といった、Cライクなドメイン固有言語 (DSL) を組み込んだGPGPUフレームワークにおけるコンパイラフロントエンドとしても採用されている。 プロジェクトの目標は、GNUコンパイラコレクション (GCC) を置き換えるこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
