iphone - rapido - ¿Por qué usar funciones como CGRectMake?

me olvide la contraseña de acceso guiado

Question

Tengo curiosidad por las funciones como CGRectMake y CGPointMake que existen y se utilizan ampliamente. cuando, en cambio, puedes hacer:

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

seguramente esto es más eficiente (aunque supongo que no mucho) ya que no hay una llamada de función?

También puedes configurar el origen y tamaño como:

 (CGRect){origin, size}

y como mezcla:

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

¿Cuál es la razón para no usar esto y preferir las funciones Make?

Answer 1

La sintaxis literal compuesta de C99 es una característica un tanto oscura. Algunas personas encuentran que las funciones de Hacer más claras para leer, o las encuentran más familiares. En esta etapa del soporte de la cadena de herramientas, es simplemente una preferencia.

Tengo curiosidad de por qué existen funciones como CGRectMake y CGPointMake ...

CGRectMake (disponible desde 10.0) precedió al soporte de compilación de literales compuestos de OS X. Los literales compuestos se completaron oficialmente en GCC 3.1 (mayo de 2002).

Answer 2

No es más eficiente, en realidad. La función CGRectMake (y otras) se declaran como en static inline , lo que significa que la copia del compilador pega el código de la función directamente en cada lugar donde se usa:

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

dónde

# define CG_INLINE static inline

Vas de

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

a

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

que en principio no es diferente de

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

Después de las optimizaciones del compilador y tal.

Como se dijo anteriormente, agrega una dependencia de que CGRect es una estructura de 4 números alineados de cierta manera en lugar de usar una función que tiene más garantía de ello.

Answer 3

Supongo que es la misma vieja diferencia entre:

1. agregando una dependencia en su código desde la definición interna de una estructura de datos;

2. usando una función que encapsula ese conocimiento y que podría "enmascarar" cualquier cambio en la estructura de datos subyacente.

En principio, CGRect podría evolucionar hacia una clase completa con su origin , size, etc., accesores, etc. No estoy diciendo que esto sea sensato o probable, solo que la razón por la que usa una función para Crear instancias de una estructura de datos tiene que ver con la resistencia de su código a los cambios.