19

CGRectMake や CGPointMake などの関数が存在し、広く使用されている理由に興味があります。代わりに、次のことができます。

(CGRect){{x, y}, {width, height}}

関数呼び出しがないので、確かにこれはより効率的です (私はあまり推測していませんが)。

また、次のように原点とサイズを設定できます。

 (CGRect){origin, size}

および混合物として：

 (CGRect){origin, {width, height}}

これを使用せず、Make 関数を優先する理由は何ですか?

4

3 に答える 3

13

実際には、より効率的ではありません。CGRectMake関数 (およびその他) は として宣言されています。static inlineこれは、コンパイラが関数コードを、それが使用されているすべての場所に直接貼り付けることを意味します。

CG_INLINE CGRect
CGRectMake(CGFloat x, CGFloat y, CGFloat width, CGFloat height)

どこ

#  define CG_INLINE static inline

あなたはから行きます

// code
CGRect myRect = CGRectMake(1,2,3,4);
// code

に

// code
CGRect myRect;
myRect.origin.x = 1; myRect.origin.y = 2;
myRect.size.width = 3; myRect.size.height = 4;

原則として、

CGRect myRect = (CGRect){1,2,3,4};

コンパイラの最適化などの後。

上記のように、CGRectより確実な関数を使用するのではなく、特定の方法で整列された4つの数値の構造体であることに依存関係を追加します。

于 2012-10-07T07:22:01.950 に答える
8

私はそれが同じ古い違いだと思います：

  1. データ構造の内部定義からコードに依存関係を追加する。

  2. その知識をカプセル化し、基礎となるデータ構造の変更を「マスク」できる関数を使用します。

原則として、は、CGRectその など、アクセサなどを備えた本格的なクラスに進化する可能性があります...これが賢明である、またはその可能性が高いと言っているわけではありません。関数を使用してインスタンスを作成する理由はデータ構造は、変更に対するコードの回復力に関係しています。originsize,

于 2012-07-28T11:28:29.103 に答える
6

C99 の複合リテラル構文は、ややあいまいな機能です。Make 関数の方が読みやすい、または親しみやすいと感じる人もいます。ツールチェーン サポートのこの段階では、それは単なる好みです。

CGRectMake や CGPointMake などの関数が存在する理由が気になります…</p>

CGRectMake(10.0 以降で利用可能) は、OS X のコンパイラが複合リテラルをサポートする前に使用されました。複合リテラルは、GCC 3.1 (2002 年 5 月) で正式に完成しました。

于 2012-10-07T07:58:17.740 に答える