マクロには、どのプログラミング言語でも長所しかないのではないかと思います。マクロを作成できるのは限界があるはずなので、使用頻度も限られています。
クラスに100個のマクロを作成し、それをアプリケーションプロジェクトの100個のクラスにインポートするとします。これは正しいアプローチですか?
マクロには、どのプログラミング言語でも長所しかないのではないかと思います。マクロを作成できるのは限界があるはずなので、使用頻度も限られています。
クラスに100個のマクロを作成し、それをアプリケーションプロジェクトの100個のクラスにインポートするとします。これは正しいアプローチですか?
#define
プリプロセッサマクロです。マクロは使用時にテキストで展開されるため、クラスでマクロを作成しませんが、クラス内で字句的に記述した場合でも、その定義はクラスの一部ではありません。
import
また、他のクラスのクラスではなく、import
クラス宣言ヘッダーです。複数回指定した場合でも、インポートはコンパイル単位ごとに1回だけ行われます。したがって、各コンパイルユニットには最大で1つのマクロの宣言があり、マクロはプリプロセッサのみであるため、コンパイルの初期段階でのみ存在します。
マクロを何に使用したいかを正確に言っているわけではないので、マクロがあなたにとって最良の解決策であるかどうか、またはより良い代替案があるかどうかを判断するのは困難です。しかし、私は彼らの数については心配しません。標準のヘッダーファイルは、何百ものマクロを定義します。
#define
次の場合に役立ちます。
#include
CおよびC ++ヘッダー、#import
ObjCヘッダー)UIKIT_EXTERN
前処理中に解決する必要がある言語互換性(例)の条件付きコンパイル。NS_AVAILABLE_IOS()
前処理中に解決する必要があるプラットフォーム/コンパイラ/バージョン固有の宣言(例)の条件付きコンパイル。他のすべてについては、途中であなたの頭痛を救う代替手段があります。
クラスに100個のマクロを作成し、それをアプリケーションプロジェクトの100個のクラスにインポートするとします。これは正しいアプローチですか?
いいえ-それは恐ろしいです:)
短所
沢山あります。多くの場合、プログラムは人間とプログラム(コンパイラー、パーサー、インデクサー)が同様に理解するのが難しいでしょう。これは、バグを導入し、無関係なプログラムのテキストを(単純な方法で)完全に置き換える良い方法#import
です。ほとんどすべて(関数、インライン、typedef、定数、列挙型など)の最新の代替品があります-コンパイラーがあなたの生活を楽にしてくれるようにしてください!