我很好奇为什么像CGRectMake和CGPointMake这样的函数存在并被广泛使用。 相反,你可以这样做:
(CGRect){{x, y}, {width, height}}
肯定这样做效率更高(虽然我猜的不多)因为没有函数调用?
您也可以设置原点和大小,如:
(CGRect){origin, size}
和作为混合物:
(CGRect){origin, {width, height}}
不使用此功能的原因是什么,更喜欢Make功能?
答案 0 :(得分: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个数字的结构,而不是使用对它有更多保证的函数。
答案 1 :(得分:8)
我认为这是旧的差异:
从数据结构的内部定义中添加代码中的依赖项;
使用封装该知识的函数,可以“屏蔽”基础数据结构中的任何更改。
原则上,CGRect
可能演变成一个成熟的课程,其origin
,size,
等,访问者等...我不是说这是明智的或那个很可能,只有你使用函数创建数据结构实例的原因才在于你的代码能够适应变化。
答案 2 :(得分:6)
C99的复合文字语法是有些模糊的功能。有些人发现Make函数更清晰,或者他们发现它更熟悉。在工具链支持的这个阶段,它只是偏好。
我很好奇为什么像CGRectMake和CGPointMake这样的函数存在......
CGRectMake
(10.0以后可用)在OS X的编译器支持复合文字之前。复合文字在GCC 3.1(2002年5月)正式完成。