19

我很好奇爲什麼像CGRectMake和CGPointMake這樣的函數存在並被廣泛使用。 的時候,相反,你可以這樣做:爲什麼使用像CGRectMake這樣的函數?

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

這肯定是更有效的(雖然我猜得不多),因爲沒有函數調用?

您也可以設置起點和大小,如:

(CGRect){origin, size} 

,並作爲混合物:

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

什麼是不使用這一點,寧願美顏功能的原因是什麼?

回答

8

我想是間同舊差:

  1. 添加在從一個數據結構的內部定義你代碼的依賴關係;

  2. 使用封裝知識的功能,可以「掩蓋」底層數據結構中的任何更改。

原則,CGRect可能演變成一場全面的類及其originsize,等,存取等...我不是說這將是明智的,或者它是可能的,只是原因爲什麼使用函數來創建數據結構的實例與代碼對變化的彈性有關。

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個數字的結構,而不是使用對其有更多保證的函數。

6

C99的複合文字語法是有些難以理解的特徵。有些人發現Make功能更清晰,或者他們覺得更熟悉。在工具鏈支持的這個階段,這只是優先選擇。

我很好奇,爲什麼像CGRectMake和CGPointMake功能存在...

CGRectMake(可用自10.0)之前OS X的編譯器的支持複合文字的。 GCC 3.1(2002年5月)正式完成了複合文字。

相關問題