問題タブ [c-preprocessor]

C/C++ プリプロセッサまたはテンプレートなどを取得して、__FILE__ と __LINE__、およびビルド番号などの他の外部入力を、ログまたはエラー メッセージで引用できる単一の短い番号にマングル/ハッシュする方法はありますか?

(意図は、顧客がバグレポートでそれを引用したときに、必要に応じてそれを元に戻すことができるようにすることです (損失がある場合は候補のリストに)。)

コードがコンパイルされるオペレーティングシステムに基づいて、さまざまなことを実行するためのコードが必要です。私はこのようなものを探しています：

これを行う方法はありますか？同じことをするより良い方法はありますか？

私は非常に大きなコードベース (読み取り: 数千のモジュール) を持っており、さまざまな C++ コンパイラを使用してさまざまなオペレーティング システムで実行される多数のプロジェクト間でコードが共有されています。言うまでもなく、ビルド プロセスを維持するのは非常に面倒です。

#includesファイルが現在のフォルダーに存在しないかどうかをプリプロセッサに確実に無視させる方法があれば、コードを大幅にクリーンアップできるコードベースの場所がいくつかあります。誰もそれを達成する方法を知っていますか?

現在、共有ファイル内で を使用して#ifdefおり、プロジェクトにが存在する#includeかどうかを #define する 2 番目のプロジェクト固有のファイルを使用しています。#includeこれは機能しますが、醜いです。プロジェクトにファイルを追加または削除するときに、定義を適切に更新することを忘れがちです。このファイルを最新の状態に保つためにビルド前のツールを作成することを検討しましたが、プリプロセッサでこれを行うプラットフォームに依存しない方法がある場合は、代わりにその方法を使用したいと思います。何か案は？

これが私がやろうとしていることです:

次のようなスイッチケースを実行する関数を作成しようとしています:

すべてのケースで定義する代わりに、上記のように enum 変数を使用して設定する方法はありますか?

C++プリプロセッサ#defineはまったく異なります。

PHPは、define()単に変数を作成するのと何か違いがありますか？

vs

多くの C/C++ マクロで、マクロのコードが無意味なdo whileループに包まれているのを目にします。以下に例を示します。

が何をしているのか見えませんdo while。それなしでこれを書いてみませんか？

C++ 関数では、64 ビット アーキテクチャ用にコンパイルする場合、コンパイラが別のブロックを選択する必要があります。

MSVC ++とg ++でそれを行う方法を知っているので、回答として投稿します。ただし、より良い方法があるかどうかを知りたいです（すべてのコンパイラ/すべての64ビットアーキテクチャで機能するよりエレガントな方法）。より良い方法がない場合、他のコンパイラ/アーキテクチャと互換性を持たせるために、他にどの定義済みマクロを探す必要がありますか?

何らかの理由でマクロを作成する必要があるとしましょうMACRO(X,Y)。 （インライン関数を使用できない正当な理由があると仮定しましょう。） このマクロで、戻り値のない関数の呼び出しをエミュレートする必要があります。

例1：これは期待どおりに機能するはずです。

例2：これによってコンパイラエラーが発生することはありません。

例3：これはコンパイルされるべきではありません。

マクロを書くための素朴な方法は次のようなものです。

これは3つの例すべてに失敗する非常に悪い解決策であり、その理由を説明する必要はありません。

マクロが実際に何をするかは無視してください。それは重要ではありません。

さて、私が最もよく書くマクロを見る方法は、次のように中かっこで囲むことです。

これは、マクロが1つのステートメントブロックにあるため、例1を解決します。ただし、マクロの呼び出しの後にセミコロンを付けるため、例2は壊れています。これにより、コンパイラはセミコロン自体がステートメントであると見なします。つまり、elseステートメントはifステートメントに対応しません。最後に、例3は、セミコロンがない場合でも、コードブロックにセミコロンが必要ないため、正常にコンパイルされます。

3つの例すべてに合格するようにマクロを作成する方法はありますか？

注：私はヒントを共有するための受け入れられた方法の一部として自分の回答を提出していますが、誰かがより良い解決策を持っている場合は、ここに投稿してください。私の方法よりも多くの票を獲得する可能性があります。:)

#warningディレクティブが標準のC /C ++ではないことは知っていますが、gcc /g++を含むいくつかのコンパイラがそれをサポートしています。しかし、それをサポートしていない人にとって、彼らはそれを黙って無視するのでしょうか、それともコンパイルの失敗につながるのでしょうか？言い換えれば、それをサポートしていないコンパイラのビルドを壊すことなく、プロジェクトで安全に使用できますか？

これは、同じ前処理命令に対する複数の質問です。

1 - <> または "" ?

MSDN にある情報とは別に:

#include ディレクティブ (C-C++)

1.a: 2 つの表記法の違いは何ですか?
1.b: すべてのコンパイラが同じように実装していますか?
1.c: いつ <> を使用し、いつ "" を使用しますか?

2 - #include {TheProject/TheHeader.hpp} または {TheHeader.hpp} ?

私は、自分のプロジェクト ヘッダーのインクルードを記述する方法を少なくとも 2 つ見てきました。少なくとも 4 種類のヘッダーがあることを考慮すると、次のようになります。

• あなたのプロジェクトのプライベートヘッダー？
• プロジェクトのヘッダーですが、シンボルをエクスポートしています（したがって、「パブリック」）
• モジュールがリンクする別のプロジェクトのヘッダー
• コンパイラまたは標準ライブラリのヘッダー

ヘッダーの種類ごとに:

2.a: <> または "" のどちらを使用しますか?
2.b: {TheProject/TheHeader.hpp} と一緒に含めますか、それとも {TheHeader.hpp} のみと一緒に含めますか?

3 - ボーナス

3.a: ツリーのような組織 (つまり、「1 つのディレクトリ内のすべてのファイル」ではなく、ディレクトリ内のディレクトリ) 内のソースおよび/またはヘッダーを使用してプロジェクトに取り組んでいますか? また、長所/短所は何ですか?