2010-06-14 34 views
5

Recientemente encontré una convención de codificación bastante inusual en la que la llamada para una función que devuelve "vacío" se antepone con (vacío).Necesidad de prefijar una función con (vacío)

p. Ej.

(void) MyFunction(); 

¿Es diferente de la llamada a la función como:

MyFunction(); 

tiene eso alguna ventaja o se trata de otra innecesaria pero hay convención de codificación de algún tipo?

Respuesta

12

Algunas funciones como printf() devuelven un valor que casi nunca se utiliza en código real (en el caso de printf, el número de caracteres impresos). Sin embargo, algunas herramientas, como pelusa, esperan que si una función devuelve un valor que debe ser utilizado, y se quejará a menos que escribir algo como:

int n = printf("hello"); 

utilizando el vacío reparto:

(void) printf("hello"); 

es una forma de decirle a esas herramientas que realmente no desea usar el valor de retorno, manteniéndolo en silencio. Si no utiliza tales herramientas, no necesita molestarse, y en cualquier caso, la mayoría de las herramientas le permiten configurarlas para ignorar los valores de retorno de funciones específicas.

+0

Ya veo. Pero entonces, ¿por qué alguien querría hacer esto para una función que ya está volviendo vacía? – puffadder

+0

Claro, pero dijo que el reparto se hizo para funciones que vuelven vacías. – Artefacto

+4

@puffadder Supongo que el tipo de devolución de la función cambió en algún momento, pero el código de llamada no. –

2

No, no hay ninguna diferencia: lo que se lanza al vacío es el valor de retorno de la función.

Yo diría que podría dar sentido a que quisiera hacer explícito que no está utilizando el valor de retorno (lo está llamando para los efectos secundarios), pero como la función ya tiene retorno nulo, no lo hace Tiene mucho sentido.

0

Si la función devuelve algo, el vacío podría evitar (!) Una advertencia (de hecho, de ninguna manera pude hacer que gcc me advirtiera que el valor de retorno se pierde) en algunos compiladores (o herramientas de pelusa); pero más importante aún, deja en claro que un valor de retorno es "arrojado" a propósito (y no por error).

0

acedemically: una "función" siempre devuelve algo, de lo contrario sería un procedimiento. Por lo que el autor de este código quiere decir "sé que este nombramiento está mal, pero lo haré ningún cambio el nombre, así que hago esta perturbación visible"

0

tiene eso alguna ventaja o se trata de otra innecesaria pero hay alguna convención de codificación de algún tipo?

Sin diferencia. Es una convención bastante común, p. en pruebas de software para resaltar el hecho de que, en contexto, el retorno de la función, si existe, es seguro para descartar.

0

En las páginas de manual de HPUX es bastante común en el código de ejemplo para ver un lanzamiento para anular las advertencias de pelusa.

fprintf(mystream, "%s\n", "foo"); 

vs

(void)fprintf(mystream, "%s\n", "foo"); 

que puede ser que el autor del código está viniendo. OMI, esta no es una gran idea porque la mayoría de los miembros de la familia sprintf, por ejemplo, llaman malloc. malloc fallará cuando no haya suficiente memoria.SIGINT también hace que el syscall write() subyacente interrumpa y no escriba todo el búfer, para los miembros de la familia printf().

Cuestiones relacionadas