はてなブックマーク

c++の#include ディレクティブは、プリプロセスで解釈され、書かれたファイル名の内容を単にその場所に展開したものとして処理されます。

inline関数やconst変数を使ってもC言語時代に#defineマクロによって実現していたことの全てをカバーできるわけではありません。 今でもCPP(C Pre Processor)の力は偉大です。 特に、ビルドレベルに応じて違う挙動になるような処理を実現するには#defineによるマクロは有効な選択です。 以下のような要件を満たすマクロを考えてみましょう 開発中のみ有効 ある条件を与えて結果が偽ならログ出力 #ifdef _DEBUG #define DEBUG_LOG(exp, ...) do {if (!(exp)){std::printf(__VA_ARGS__);}} while(0) #else #define DEBUG_LOG(exp, ...) do {(void)(exp);} while(0) #endif以下のように使います。 int main() { int

プライベートは大切にしたいほうです。 このアーティクルを書いている今、個人的な話ですが仕事がデスマーチでプライベートなんてありません。 普段なら、この時期はプライベートジェットでサイパンに飛んで、プライベートビーチに寝転がってiPadでプライベートライアンを見ているはずです。 自分のプライベートが守られない今、他人のクラスのプライベートも守りません。積極的に攻めていくスタイルです。 // 従業員 class Employer { float time_for_game_; // ゲームの時間 float time_for_anime_; // アニメの時間 float time_for_family_; // 家族との時間 public: float time_for_work_; // 仕事の時間 };雇われサラリーマンにも生活があります。 仕事の時間の他に自分の時間も必要なのです。そし

継承には３つのレベルがあります。 public protected private オブジェクト指向的な考え方ではpublic継承はよくis-a関係を表すなどと言われたりしますね。 どら焼き is a 和菓子。 ベジータ is a サイヤ人。 B is a A（びーいずあえー）という関係なのでis-a関係です。 一方、private継承、protected継承はis-a関係ではありません。 is-a関係との対比でhas-a関係、またはis-implemented-in-terms-of関係なんて呼ばれたりします。 public継承以外はB is a Aの関係では無いため、AのポインタにBを代入することはできません。 class A {}; class B : A {}; int main() { A* = new B; // エラー！cannot cast 'B' to its priva

__asm int 3;これを見てピンと来た人は何人いるだろうか。 ああ、x86系CPU環境でブレークポイントと同じ効果をもたらすアセンブラコードだなーと思った人。正解ですが本質的ではありません。 ああ、闇夜のc++とか言いながらついにネタ切れでc++の話以外を書き始めたなーと思った人。正解だし本質的です。 xcodeやVisual Studioで以下のコードを実行してみましょう。 #include <cstdio> int main() { std::printf("abc"); __asm int 3; std::printf("def"); return 0; }int 3というアセンブラ命令はデバッガへのトラップ用の割り込みを発生させるので、5行目で勝手にデバッガがブレークします。 そこからステップトレースも、再実行も可能です。 マクロを作っておくと何かと便利です。 // 条件が成

C++言語の持つオシャレな機構の一つにADL(Argument Dependent Lookup)というものがあります。 和訳すると「実引数依存の名前検索」となり、読んで字の如く、「実引数」に依存した「名前検索」となります。なるほどわからん。 ADLの挙動 コードを見ながら順を追って理解してみましょう。

術者が高度に言語を理解している限りにおいては高度に最適化された術式を出力できる ＿＿アンサイクロペディア C++概要より [showwhatsnew] C++Language テンプレートの特殊化 共変型の戻り値とオーバーライドルールの緩和 非public継承の使いどころ virtualの伝播 禁忌の識別子 Plain Old Data Argument Dependent Lookup 最も速い数値型 ポータビリティの高い数値型 クラスの不定なメモリレイアウト newの実装 deleteの呼び出しと実装 真に安全なsafe_delete C++ Coding Technique privateメンバへ合法的にアクセス Pimplイディオム アクセス指定子の無効化 do-while(0)によるマクロラッピング インクルードガード レガシー環境でnullptr 配列の要素数の取得方法 ADL

符号付か否か、あとは型の持つbit数などを踏まえたエイリアスを用意することでタイピング数の削減と統一的な名前規則でコードを分かりやすくしようという意図が感じられます。 一定規模以上のプロジェクトになると、ほぼ必ず上記のような型の再定義ファイルがあるように感じます。既視感のある人も多いのではないでしょうか。 ただ、上記の例は非常にポータビリティに欠ける為、行うべきではありません。 ユーザーが「intの別名はs32」と定義したところで、実際にs32のサイズが32bitになる保証はどこにもありません。 サイズが保証された数値型を標準が用意してくれているので、そちらを使うようにしましょう。

オブジェクトの生成と破棄には莫大なコストがかかることがあります。 CPUによるメモリ割り当て、コンストラクタ・デストラクタの挙動等、オブジェクトが一つ生成され、破棄されるまでのコストは無視できません。あなたの目の届かないところで提供されたサードパーティ製のライブラリのクラスでは、コンストラクタ内で自分のメンバからCRC値を生成して勝手にツイートする実装になっているかもしれません。 コンパイラも、そんな我々の気持ちを汲んで、なるべく一時オブジェクトの生成を抑制＝最適化しようとしてくれます。 そんな最適化の一つが今回説明するRVO(Return Value Optimization)です。 関数の戻り値を値で返す時に発生する一時オブジェクトをコンパイラは可能な限り消し去ります。 #include <cstdio> class Hoge { public: Hoge() { std::print

後置インクリメントにはひと目で遅くなりそうな処理が見て取れますね。 前置インクリメントがインクリメント処理後、単純に自身の参照を返すのに対し、後置インクリメントではインクリメント前に一時オブジェクトの生成、そしてインクリメント後にはその前に生成した一時オブジェクトを値で返しています。 前置と後置では、単純にオブジェクトをコピーして返す分、普通に考えたら後置の方が遅いよね。というのが従来の認識でした。 「C++ Coding Standards -101のルール、ガイドライン、ベストプラクティス」の中でも、特に後置インクリメントの必然性が無い時は迷わず前置インクリメントを使うことが推奨されてきました。 元の値を必要としないときは前置形式の演算子を使おう ＿＿C++ Coding Standards (p50) 新たな主張 「ゲームエンジン・アーキテクチャ第二版」の中の一節を紹介します。 しか

順調に動いていたはずのプログラムが突然ダンプを吐いてクラッシュする・・・。 まさに悲劇としか言えません。 ある調査機関によると成人男性の約89％がこの不幸に出会っているという報告もあります。[要出典] 最も多く、そして最も簡単に発生する原因としてnullポインタアクセスが挙げられます。以下のコードを見てみましょう。 // アクセルしか無い車。　※リコールの対象になる恐れがある class Car { public: void accel() { speed_ += 1; // ガンガン加速する } private: int speed_; }; int main() { Car* car = nullptr; car->accel(); // nullptrに対してメソッドを呼ぶ。当然事故る return 0; }