我很好奇为什么像 CGRectMake 和 CGPointMake 这样的函数存在并且被广泛使用。相反,您可以这样做:
(CGRect){{x, y}, {width, height}}
由于没有函数调用,这肯定会更有效(尽管我猜不是很多)?
您还可以设置原点和大小,如:
(CGRect){origin, size}
并作为混合物:
(CGRect){origin, {width, height}}
不使用它并更喜欢 Make 功能的原因是什么?
我很好奇为什么像 CGRectMake 和 CGPointMake 这样的函数存在并且被广泛使用。相反,您可以这样做:
(CGRect){{x, y}, {width, height}}
由于没有函数调用,这肯定会更有效(尽管我猜不是很多)?
您还可以设置原点和大小,如:
(CGRect){origin, size}
并作为混合物:
(CGRect){origin, {width, height}}
不使用它并更喜欢 Make 功能的原因是什么?
实际上,它并没有更有效。该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 个数字的结构的依赖,而不是使用对其有更多保证的函数。
我想这是相同的旧区别:
从数据结构的内部定义中在代码中添加依赖项;
使用封装该知识并且可以“掩盖”底层数据结构中的任何更改的函数。
原则上,CGRect
可能会演变成一个成熟的类,它origin
的size,
等,访问器等......我并不是说这会是明智的或很可能,只是你使用函数创建实例的原因数据结构与代码对更改的弹性有关。
C99 的复合文字语法是一个有点晦涩的特性。有些人发现 Make 函数更易于阅读,或者他们发现它更熟悉。在工具链支持的这个阶段,它只是偏好。
我很好奇为什么存在像 CGRectMake 和 CGPointMake 这样的函数……</p>
CGRectMake
(自 10.0 起可用)在 OS X 的编译器支持复合文字之前。复合文字在 GCC 3.1(2002 年 5 月)中正式完成。