¿Lanzo el resultado de malloc?

En esta pregunta , alguien sugirió en un comentario que yo no emitir el resultado malloc, es decir,

int *sieve = malloc(sizeof(int) * length);

más bien que:

int *sieve = (int *) malloc(sizeof(int) * length);

Por qué sería este el caso?

No ; usted no emitir el resultado, ya que:

• Es innecesario, ya que void *se promociona de forma automática y segura a cualquier otro tipo de puntero en este caso.
• Agrega desorden al código, las conversiones no son muy fáciles de leer (especialmente si el tipo de puntero es largo).
• Te hace repetir, lo que generalmente es malo.
• Puede ocultar un error si olvidó incluirlo <stdlib.h>. Esto puede causar bloqueos (o, lo que es peor, no causar un bloqueo hasta más tarde en una parte totalmente diferente del código). Considere lo que sucede si los punteros y los enteros tienen tamaños diferentes; entonces está ocultando una advertencia al emitir y puede perder partes de su dirección devuelta. Nota: a partir de C99, las funciones implícitas han desaparecido de C, y este punto ya no es relevante ya que no existe un supuesto automático de que las funciones no declaradas vuelven int.

Como aclaración, tenga en cuenta que dije "usted no lanza", no "no necesita lanzar". En mi opinión, es un fracaso incluir el elenco, incluso si lo hiciste bien. Simplemente no hay beneficios al hacerlo, pero hay un montón de riesgos potenciales, e incluir el elenco indica que no conoce los riesgos.

También tenga en cuenta, como señalan los comentaristas, que lo anterior habla de C directo, no de C ++. Creo firmemente en C y C ++ como lenguajes separados.

Para agregar más, su código repite innecesariamente la información de tipo ( int) que puede causar errores. Es mejor desreferenciar el puntero que se utiliza para almacenar el valor de retorno, para "bloquear" los dos juntos:

int *sieve = malloc(length * sizeof *sieve);

Esto también mueve lengthal frente para una mayor visibilidad y elimina los paréntesis redundantes con sizeof; que sólo son necesarios cuando el argumento es un nombre de tipo. Muchas personas parecen no saber (o ignorar) esto, lo que hace que su código sea más detallado. Recuerde: ¡ sizeofno es una función! :)

Si bien moverse lengthhacia el frente puede aumentar la visibilidad en algunos casos raros, también se debe prestar atención a que, en el caso general, debería ser mejor escribir la expresión como:

int *sieve = malloc(sizeof *sieve * length);

Dado que mantener el sizeofprimero, en este caso, asegura que la multiplicación se realice con al menos size_tmatemáticas.

Comparar: malloc(sizeof *sieve * length * width)vs. malloc(length * width * sizeof *sieve)el segundo puede desbordar el length * widthcuándo widthy lengthson tipos más pequeños que size_t.

En C, no necesita emitir el valor de retorno de malloc. El puntero a vacío devuelto por mallocse convierte automáticamente al tipo correcto. Sin embargo, si desea que su código se compile con un compilador de C ++, se necesita un reparto. Una alternativa preferida entre la comunidad es usar lo siguiente:

int *sieve = malloc(sizeof *sieve * length);

lo que además te libera de tener que preocuparte por cambiar el lado derecho de la expresión si alguna vez cambias el tipo de sieve.

Los moldes son malos, como la gente ha señalado. Especialmente moldes de puntero.

Lo haces porque:

• Hace que su código sea más portátil entre C y C ++, y como lo demuestra la experiencia de SO, muchos programadores afirman que están escribiendo en C cuando realmente están escribiendo en C ++ (o C más extensiones de compilador local).
• No hacerlo puede ocultar un error : tenga en cuenta todos los ejemplos SO de confusión sobre cuándo escribir type *versustype ** .
• La idea de que te impide darte cuenta de que fallaste en #includeun archivo de encabezado apropiado pierde el bosque para los árboles . Es lo mismo que decir "no te preocupes por el hecho de que no pudiste pedirle al compilador que se quejara por no ver prototipos, ¡ese molesto stdlib.h es lo REAL realmente importante para recordar!"
• Fuerza una verificación cruzada cognitiva adicional . Pone el (deseado) tipo deseado justo al lado de la aritmética que está haciendo para el tamaño bruto de esa variable. Apuesto a que podrías hacer un estudio SO que muestre que los malloc()errores se detectan mucho más rápido cuando hay un elenco. Al igual que con las afirmaciones, las anotaciones que revelan la intención disminuyen los errores.
• Repetirse de una manera que la máquina pueda verificar es a menudo una gran idea. De hecho, eso es una afirmación, y este uso de cast es una afirmación. Las afirmaciones siguen siendo la técnica más general que tenemos para obtener el código correcto, ya que a Turing se le ocurrió la idea hace muchos años.

Como otros han dicho, no es necesario para C, pero sí para C ++. Si cree que va a compilar su código C con un compilador de C ++, por cualquier motivo, puede usar una macro, como:

#ifdef __cplusplus
# define NEW(type, count) ((type *)calloc(count, sizeof(type)))
#else
# define NEW(type, count) (calloc(count, sizeof(type)))
#endif

De esa manera, aún puede escribirlo de una manera muy compacta:

int *sieve = NEW(int, 1);

y compilará para C y C ++.

De la Wikipedia :

Ventajas del casting

• La inclusión del elenco puede permitir que un programa o función C se compile como C ++.

• El elenco permite versiones anteriores a 1989 de malloc que originalmente devolvieron un char *.

• La conversión puede ayudar al desarrollador a identificar inconsistencias en el tamaño de los tipos si el tipo de puntero de destino cambia, particularmente si el puntero se declara lejos de la llamada malloc () (aunque los compiladores modernos y los analizadores estáticos pueden advertir sobre tal comportamiento sin requerir la conversión).

Desventajas de lanzar

• Según el estándar ANSI C, la conversión es redundante.

• Agregar el reparto puede enmascarar la falla al incluir el encabezado stdlib.h, en el que se encuentra el prototipo de malloc. En ausencia de un prototipo para malloc, el estándar requiere que el compilador de C suponga que malloc devuelve un int. Si no hay conversión, se emite una advertencia cuando este entero se asigna al puntero; sin embargo, con el reparto, esta advertencia no se produce, ocultando un error. En ciertas arquitecturas y modelos de datos (como LP64 en sistemas de 64 bits, donde long y punteros son de 64 bits e int es de 32 bits), este error puede dar lugar a un comportamiento indefinido, ya que el malloc declarado implícitamente devuelve un 32- valor de bit, mientras que la función realmente definida devuelve un valor de 64 bits. Dependiendo de las convenciones de llamadas y el diseño de la memoria, esto puede provocar la destrucción de la pila. Es menos probable que este problema pase desapercibido en los compiladores modernos, Como uniformemente producen advertencias de que se ha utilizado una función no declarada, aparecerá una advertencia. Por ejemplo, el comportamiento predeterminado de GCC es mostrar una advertencia que dice "declaración implícita incompatible de función incorporada" independientemente de si el elenco está presente o no.

• Si el tipo de puntero se cambia en su declaración, también puede ser necesario cambiar todas las líneas donde se llama y se lanza malloc.

Aunque malloc sin casting es el método preferido y los programadores más experimentados lo eligen , debe usar el que desee para conocer los problemas.

es decir: si necesita compilar el programa C como C ++ (aunque es un lenguaje separado), debe emitir el resultado del uso malloc.

En C, puede convertir implícitamente un voidpuntero a cualquier otro tipo de puntero, por lo que no es necesario un reparto. El uso de uno puede sugerir al observador casual que hay alguna razón por la que se necesita, lo que puede ser engañoso.

No emites el resultado de malloc, porque hacerlo agrega desorden inútil a tu código.

La razón más común por la cual las personas emiten el resultado de malloc es porque no están seguros de cómo funciona el lenguaje C. Esa es una señal de advertencia: si no sabes cómo funciona un mecanismo de lenguaje en particular, entonces no adivines. Búscalo o pregunta en Stack Overflow.

Algunos comentarios:

• Un puntero nulo se puede convertir a / desde cualquier otro tipo de puntero sin una conversión explícita (C11 6.3.2.3 y 6.5.16.1).

• Sin embargo, C ++ no permitirá una conversión implícita entre void*y otro tipo de puntero. Entonces, en C ++, el reparto habría sido correcto. Pero si programa en C ++, debería usarnew y no malloc (). Y nunca debe compilar código C usando un compilador de C ++.

  Si necesita admitir C y C ++ con el mismo código fuente, use modificadores de compilación para marcar las diferencias. No intente saciar ambos estándares de idioma con el mismo código, ya que no son compatibles.

• Si un compilador de C no puede encontrar una función porque olvidó incluir el encabezado, obtendrá un error de compilador / enlazador al respecto. Entonces, si olvidó incluir <stdlib.h>eso no es gran cosa, no podrá construir su programa.

• En los compiladores antiguos que siguen una versión del estándar que tiene más de 25 años, olvidarse de incluirlos <stdlib.h>resultaría en un comportamiento peligroso. Porque en ese antiguo estándar, las funciones sin un prototipo visible convirtieron implícitamente el tipo de retorno aint . Lanzar el resultado de malloc explícitamente escondería este error.

  Pero eso no es realmente un problema. No estás usando una computadora de 25 años, entonces ¿por qué usarías un compilador de 25 años?

En C obtienes una conversión implícita de void *cualquier otro puntero (de datos).

Transmitir el valor devuelto por malloc()Ahora no es necesario , pero me gustaría agregar un punto que parece que nadie ha señalado:

En la antigüedad, es decir, antes de que ANSI C proporcione el void *tipo genérico de punteros, char *es el tipo para dicho uso. En ese caso, el elenco puede cerrar las advertencias del compilador.

Referencia: C Preguntas frecuentes

Solo agregando mi experiencia, estudiando ingeniería informática, veo que los dos o tres profesores que he visto escribir en C siempre emiten malloc, sin embargo, el que le pregunté (con un inmenso CV y ​​comprensión de C) me dijo que es absolutamente innecesario, pero solía ser absolutamente específico y hacer que los estudiantes tuvieran la mentalidad de ser absolutamente específicos. Esencialmente, el lanzamiento no cambiará nada en su funcionamiento, hace exactamente lo que dice, asigna memoria y el lanzamiento no lo afecta, obtienes la misma memoria e incluso si lo lanzas a otra cosa por error (y de alguna manera evades el compilador errores) C accederá de la misma manera.

Editar: El casting tiene un cierto punto. Cuando utiliza la notación de matriz, el código generado tiene que saber cuántos lugares de memoria tiene que avanzar para alcanzar el comienzo del siguiente elemento, esto se logra mediante la conversión. De esta manera, usted sabe que para un doble va 8 bytes adelante, mientras que para un int va 4, y así sucesivamente. Por lo tanto, no tiene ningún efecto si utiliza la notación de puntero, en notación de matriz se hace necesario.

No es obligatorio emitir los resultados de malloc, ya que regresa void*, y void*puede apuntar a cualquier tipo de datos.

Un puntero vacío es un puntero de objeto genérico y C admite la conversión implícita de un tipo de puntero vacío a otros tipos, por lo que no hay necesidad de convertirlo explícitamente.

Sin embargo, si desea que el mismo código funcione perfectamente compatible en una plataforma C ++, que no admite la conversión implícita, debe realizar la conversión de texto, por lo que todo depende de la usabilidad.

Esto es lo que dice el manual de referencia de la biblioteca GNU C :

Puede almacenar el resultado mallocen cualquier variable de puntero sin conversión, porque ISO C convierte automáticamente el tipo void *a otro tipo de puntero cuando sea necesario. Pero la conversión es necesaria en contextos distintos de los operadores de asignación o si desea que su código se ejecute en C. tradicional

Y, de hecho, el estándar ISO C11 (p347) lo dice así:

El puntero que se devuelve si la asignación se realiza correctamente se alinea adecuadamente para que pueda asignarse a un puntero a cualquier tipo de objeto con un requisito fundamental de alineación y luego usarse para acceder a dicho objeto o a una matriz de dichos objetos en el espacio asignado (hasta que el espacio está explícitamente desasignado)

El tipo devuelto es nulo *, que se puede convertir al tipo deseado de puntero de datos para que no se pueda hacer referencia.

En el lenguaje C, se puede asignar un puntero nulo a cualquier puntero, por lo que no debe usar un tipo de conversión. Si desea una asignación de "tipo seguro", puedo recomendar las siguientes funciones de macro, que siempre uso en mis proyectos en C:

#include <stdlib.h>
#define NEW_ARRAY(ptr, n) (ptr) = malloc((n) * sizeof *(ptr))
#define NEW(ptr) NEW_ARRAY((ptr), 1)

Con estos en su lugar, simplemente puede decir

NEW_ARRAY(sieve, length);

Para matrices no dinámicas, la tercera macro de función imprescindible es

#define LEN(arr) (sizeof (arr) / sizeof (arr)[0])

lo que hace que los bucles de matriz sean más seguros y convenientes:

int i, a[100];

for (i = 0; i < LEN(a); i++) {
   ...
}

Depende del lenguaje de programación y el compilador. Si lo usa mallocen C, no es necesario escribir cast, ya que escribirá automáticamente cast. Sin embargo, si está utilizando C ++, debe escribir cast porque mallocdevolverá un void*tipo.

Las personas acostumbradas a GCC y Clang están en mal estado. No es tan bueno por ahí.

A lo largo de los años, he estado bastante horrorizado por los compiladores asombrosamente viejos que me han requerido usar. A menudo, las empresas y los gerentes adoptan un enfoque ultraconservador para cambiar los compiladores y ni siquiera lo harán prueban si un nuevo compilador (con mejor cumplimiento de estándares y optimización de código) funcionará en su sistema. La realidad práctica para los desarrolladores que trabajan es que cuando estás codificando necesitas cubrir tus bases y, desafortunadamente, lanzar mallocs es un buen hábito si no puedes controlar qué compilador puede aplicarse a tu código.

También sugeriría que muchas organizaciones apliquen un estándar de codificación propio y que debería ser el método que la gente siga si se define. En ausencia de una guía explícita, tiendo a ir con mayor probabilidad de compilar en todas partes, en lugar de una servil adhesión a un estándar.

El argumento de que no es necesario según los estándares actuales es bastante válido. Pero ese argumento omite los aspectos prácticos del mundo real. No codificamos en un mundo regido exclusivamente por el estándar del día, sino por los aspectos prácticos de lo que me gusta llamar "el campo de la realidad de la gestión local". Y eso está doblado y retorcido más de lo que nunca estuvo el tiempo espacial. :-)

YMMV.

Tiendo a pensar en lanzar Malloc como una operación defensiva. No es bonito, no es perfecto, pero generalmente es seguro. (En serio, si no ha incluido stdlib.h entonces tienes manera más problemas que la fundición malloc!).

Puse el elenco simplemente para mostrar la desaprobación del agujero feo en el sistema de tipos, que permite que el código como el siguiente fragmento se compile sin diagnóstico, a pesar de que no se utilizan moldes para provocar la conversión incorrecta:

double d;
void *p = &d;
int *q = p;

Desearía que no existiera (y no existe en C ++) y, por lo tanto, lancé. Representa mi gusto y mi política de programación. No solo estoy lanzando un puntero, sino efectivamente, votando y expulsando demonios de estupidez . Si no puedo realmente echar fuera la estupidez , a continuación, al menos permítanme expresar el deseo de hacerlo con un gesto de protesta.

De hecho, una buena práctica es envolver malloc(y amigos) con funciones que regresan unsigned char *, y básicamente nunca usarlas void *en su código. Si necesita un puntero genérico a cualquier objeto, use un char *o unsigned char *, y tenga conversiones en ambas direcciones. La única relajación que puede permitirse, tal vez, es usar funciones como memsety memcpysin yesos.

Sobre el tema de la compatibilidad de conversión y C ++, si escribe su código para que se compile como C y C ++ (en cuyo caso debe emitir el valor de retorno mallocal asignarlo a otra cosa que no sea void *), puede hacer algo muy útil cosa para usted: puede usar macros para la conversión que se traducen en conversiones de estilo C ++ cuando se compila como C ++, pero se reducen a una conversión C cuando se compila como C:

/* In a header somewhere */
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif

Si se adhiere a estas macros, una simple grepbúsqueda en su base de código para estos identificadores le mostrará dónde están todos sus moldes, para que pueda revisar si alguno de ellos es incorrecto.

Luego, en el futuro, si compila regularmente el código con C ++, impondrá el uso de un reparto apropiado. Por ejemplo, si usa strip_qualsolo para eliminar a consto volatile, pero el programa cambia de tal manera que ahora se trata de una conversión de tipo, obtendrá un diagnóstico y tendrá que usar una combinación de conversiones para obtener la conversión deseada.

Para ayudarlo a adherirse a estas macros, el compilador GNU C ++ (¡no C!) Tiene una hermosa característica: un diagnóstico opcional que se produce para todas las apariciones de modelos de estilo C.

     -Wold-style-cast (solo C ++ y Objective-C ++)
         Avisar si se utiliza una conversión de estilo antiguo (estilo C) a un tipo no vacío
         dentro de un programa C ++. Los lanzamientos de estilo nuevo (dynamic_cast,
         static_cast, reinterpret_cast y const_cast) son menos vulnerables
         a efectos no deseados y mucho más fácil de buscar.

Si su código C se compila como C ++, puede usar esta -Wold-style-castopción para averiguar todas las apariciones de la (type)sintaxis de conversión que pueden aparecer en el código, y hacer un seguimiento de estos diagnósticos reemplazándolo con una elección adecuada entre las macros anteriores (o un combinación, si es necesario).

Este tratamiento de conversiones es la justificación técnica independiente más grande para trabajar en una "C limpia": el dialecto combinado de C y C ++, que a su vez técnicamente justifica emitir el valor de retorno de malloc.

Lo mejor que se puede hacer al programar en C siempre que sea posible:

1. Haga que su programa se compile a través de un compilador de C con todas las advertencias activadas -Wally corrija todos los errores y advertencias
2. Asegúrese de que no haya variables declaradas como auto
3. Luego compílelo usando un compilador de C ++ con -Wally -std=c++11. Solucione todos los errores y advertencias.
4. Ahora compile usando el compilador de C nuevamente. Su programa ahora debe compilarse sin previo aviso y contener menos errores.

Este procedimiento le permite aprovechar la estricta verificación de tipos de C ++, reduciendo así la cantidad de errores. En particular, este procedimiento te obliga a incluir stdlib.ho obtendrás

malloc no fue declarado dentro de este alcance

y también te obliga a lanzar el resultado malloco obtendrás

conversión no válida de void*aT*

o cual sea tu tipo de objetivo.

Los únicos beneficios de escribir en C en lugar de C ++ que puedo encontrar son

1. C tiene un ABI bien especificado
2. C ++ puede generar más código [excepciones, RTTI, plantillas, polimorfismo de tiempo de ejecución ]

Tenga en cuenta que los segundos inconvenientes deberían desaparecer en el caso ideal cuando se usa el subconjunto común a C junto con la característica polimórfica estática .

Para aquellos que encuentran inconvenientes las reglas estrictas de C ++, podemos usar la función C ++ 11 con tipo inferido

auto memblock=static_cast<T*>(malloc(n*sizeof(T))); //Mult may overflow...

No, no emites el resultado de malloc().

En general, no lanzas hacia o desdevoid * .

Una razón típica dada para no hacerlo es que el no #include <stdlib.h>poder pasar desapercibido. Esto ya no es un problema desde hace mucho tiempo ya que C99 hizo ilegales las declaraciones de funciones implícitas , por lo que si su compilador cumple al menos con C99, recibirá un mensaje de diagnóstico.

Pero hay un razón mucho más fuerte para no introducir lanzamientos de puntero innecesarios:

En C, una conversión de puntero casi siempre es un error . Esto se debe a la siguiente regla ( §6.5 p7 en N1570, el último borrador para C11):

Un objeto tendrá acceso a su valor almacenado solo mediante una expresión lvalue que tenga uno de los siguientes tipos:
- un tipo compatible con el tipo efectivo del objeto,
- una versión calificada de un tipo compatible con el tipo efectivo del objeto,
- un tipo que es el tipo con signo o sin signo correspondiente al tipo efectivo del objeto,
- un tipo que es el tipo con signo o sin signo correspondiente a una versión calificada del tipo efectivo del objeto,
- un tipo agregado o de unión que incluye uno de los tipos antes mencionados entre sus miembros (incluido, recursivamente, un miembro de una unión agregada o contenida), o
- un tipo de carácter.

Esto también se conoce como la estricta regla de alias . Entonces el siguiente código es un comportamiento indefinido :

long x = 5;
double *p = (double *)&x;
double y = *p;

Y, a veces sorprendentemente, lo siguiente también es:

struct foo { int x; };
struct bar { int x; int y; };
struct bar b = { 1, 2};
struct foo *p = (struct foo *)&b;
int z = p->x;

A veces, usted no necesita punteros elenco, pero teniendo en cuenta la regla de alias estricto , hay que tener mucho cuidado con él. Por lo tanto, cualquier aparición de un puntero emitido en su código es un lugar donde debe verificar su validez . Por lo tanto, nunca escribe un molde de puntero innecesario.

tl; dr

En pocas palabras: debido a que en C, cualquier aparición de un puntero debe levantar una bandera roja para el código que requiere atención especial, nunca debe escribir innecesariamente puntero .

Notas al margen:

• Hay casos en los que realmente necesita una conversión void *, por ejemplo, si desea imprimir un puntero:

  int x = 5;
  printf("%p\n", (void *)&x);

  El reparto es necesario aquí, porque printf()es una función variada, por lo que las conversiones implícitas no funcionan.

• En C ++, la situación es diferente. La conversión de tipos de puntero es algo común (y correcto) cuando se trata de objetos de clases derivadas. Por lo tanto, tiene sentido que en C ++, la conversión hacia y desde void *es no implícita. C ++ tiene un conjunto completo de diferentes sabores de fundición.

Prefiero hacer el reparto, pero no manualmente. Mi favorito es usar g_newy g_new0macros de glib. Si no se usa glib, agregaría macros similares. Esas macros reducen la duplicación de código sin comprometer la seguridad del tipo. Si obtiene el tipo incorrecto, obtendría una conversión implícita entre punteros no vacíos, lo que provocaría una advertencia (error en C ++). Si olvida incluir el encabezado que define g_newy g_new0, obtendrá un error. g_newy g_new0ambos toman los mismos argumentos, a diferencia de malloceso toma menos argumentos que calloc. Simplemente agregue 0para obtener memoria de inicialización cero. El código se puede compilar con un compilador de C ++ sin cambios.

La transmisión es solo para C ++ no C. En caso de que esté utilizando un compilador de C ++, es mejor que lo cambie a compilador de C.

El concepto detrás del puntero void es que se puede convertir a cualquier tipo de datos, por eso malloc devuelve void. También debe tener en cuenta el encasillado automático. Por lo tanto, no es obligatorio lanzar el puntero, aunque debe hacerlo. Ayuda a mantener limpio el código y ayuda a depurar

Un puntero vacío es un puntero genérico y C admite la conversión implícita de un tipo de puntero vacío a otros tipos, por lo que no hay necesidad de convertirlo explícitamente.

Sin embargo, si desea que el mismo código funcione perfectamente compatible en una plataforma C ++, que no admite la conversión implícita, debe realizar la conversión de texto, por lo que todo depende de la usabilidad.

1. Como se indicó, no es necesario para C, sino para C ++.

2. La inclusión del elenco puede permitir que un programa o función C se compile como C ++.

3. En C es innecesario, ya que void * se promociona de forma automática y segura a cualquier otro tipo de puntero.

4. Pero si lanza, puede ocultar un error si olvidó incluir stdlib.h . Esto puede causar bloqueos (o, lo que es peor, no causar un bloqueo hasta más tarde en una parte totalmente diferente del código).

   Porque stdlib.h contiene el prototipo para malloc se encuentra. En ausencia de un prototipo para malloc, el estándar requiere que el compilador de C asuma que malloc devuelve un int. Si no hay conversión, se emite una advertencia cuando este entero se asigna al puntero; sin embargo, con el reparto, esta advertencia no se produce, ocultando un error.

La conversión de malloc es innecesaria en C pero obligatoria en C ++.

La fundición es innecesaria en C debido a:

• void * se promociona de forma automática y segura a cualquier otro tipo de puntero en el caso de C.
• Puede ocultar un error si olvidó incluirlo <stdlib.h>. Esto puede causar accidentes.
• Si los punteros y los enteros tienen un tamaño diferente, entonces está ocultando una advertencia al emitir y puede perder fragmentos de su dirección devuelta.
• Si el tipo del puntero se cambia en su declaración, también es posible que deba cambiar todas las líneas donde mallocse llama y se lanza.

Por otro lado, la transmisión puede aumentar la portabilidad de su programa. es decir, permite que un programa o función C se compile como C ++.

Para mí, la conclusión y la conclusión aquí es que el lanzamiento mallocen C NO es totalmente necesario, pero si lo hace, no afectará, mallocya mallocque aún le asignará el espacio de memoria bendita solicitado. Otra razón para llevar a casa es la razón o una de las razones por las que las personas hacen casting y esto es para permitirles compilar el mismo programa en C o C ++.

Puede haber otras razones, pero otras razones, casi con certeza, lo llevarían a serios problemas tarde o temprano.

Puede, pero no necesita convertir en C. Debe emitir si ese código se compila como C ++.