Dois-je lancer le résultat de malloc?

Dans cette question , quelqu'un a suggéré dans un commentaire que je ne jeter le résultat de malloc, à savoir

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

plutôt que:

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

Pourquoi en serait-il ainsi?

Non ; vous ne lancez pas le résultat, car:

• Il est inutile, car void * est automatiquement et en toute sécurité promu vers tout autre type de pointeur dans ce cas.
• Il ajoute de l'encombrement au code, les transtypages ne sont pas très faciles à lire (surtout si le type de pointeur est long).
• Cela vous fait vous répéter, ce qui est généralement mauvais.
• Il peut masquer une erreur si vous avez oublié de l'inclure <stdlib.h>. Cela peut provoquer des plantages (ou pire, ne pas provoquer de plantages jusqu'à bien plus tard dans une partie totalement différente du code). Considérez ce qui se passe si les pointeurs et les entiers sont de tailles différentes; alors vous cachez un avertissement en castant et risquez de perdre des morceaux de votre adresse retournée. Remarque: à partir de C99, les fonctions implicites ont disparu de C, et ce point n'est plus pertinent car il n'y a pas d'hypothèse automatique que les fonctions non déclarées reviennent int.

À titre de clarification, notez que j'ai dit "vous ne lancez pas", pas "vous n'avez pas besoin de lancer". À mon avis, c'est un échec à inclure le casting, même si vous avez bien compris. Il n'y a tout simplement aucun avantage à le faire, mais un tas de risques potentiels, et l'inclusion de la distribution indique que vous ne connaissez pas les risques.

Notez également, comme le soulignent les commentateurs, que ce qui précède parle de C droit, pas de C ++. Je crois très fermement au C et au C ++ en tant que langages séparés.

Pour ajouter plus, votre code répète inutilement les informations de type ( int) qui peuvent provoquer des erreurs. Il vaut mieux dé-référencer le pointeur utilisé pour stocker la valeur de retour, pour "verrouiller" les deux ensemble:

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

Cela déplace également lengthl'avant vers l'avant pour une visibilité accrue et supprime les parenthèses redondantes avec sizeof; ils ne sont nécessaires que lorsque l'argument est un nom de type. Beaucoup de gens semblent ne pas le savoir (ou l'ignorer), ce qui rend leur code plus verbeux. N'oubliez pas: ce sizeofn'est pas une fonction! :)

Bien que le déplacement lengthvers l'avant puisse augmenter la visibilité dans certains cas rares, il convient également de faire attention au fait que dans le cas général, il devrait être préférable d'écrire l'expression comme suit:

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

Depuis garder le sizeofpremier, dans ce cas, assure la multiplication se fait avec au moins les size_tmathématiques.

Comparer: malloc(sizeof *sieve * length * width)vs malloc(length * width * sizeof *sieve)le second peut déborder le length * widthquand widthet lengthsont de plus petits types que size_t.

En C, vous n'avez pas besoin de transtyper la valeur de retour de malloc. Le pointeur vers void retourné par mallocest automatiquement converti au type correct. Cependant, si vous voulez que votre code compile avec un compilateur C ++, une conversion est nécessaire. Une alternative préférée au sein de la communauté est d'utiliser les éléments suivants:

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

ce qui vous évite également d'avoir à vous soucier de changer le côté droit de l'expression si jamais vous changez le type de sieve.

Les lancers sont mauvais, comme les gens l'ont souligné. Surtout les lancers de pointeurs

Vous avez jeté, parce que:

• Il rend votre code plus portable entre C et C ++, et comme le montre l'expérience SO, un grand nombre de programmeurs affirment qu'ils écrivent en C lorsqu'ils écrivent vraiment en C ++ (ou C plus des extensions de compilateur local).
• Ne pas le faire peut masquer une erreur : notez tous les exemples SO de confusion quand écrire type *par rapport àtype ** .
• L'idée qu'il vous empêche de remarquer que vous avez échoué dans #includeun fichier d'en-tête approprié manque la forêt pour les arbres . C'est la même chose que de dire "ne vous inquiétez pas du fait que vous n'ayez pas demandé au compilateur de se plaindre de ne pas voir de prototypes - ce stdlib.h embêtant est la VRAIE chose importante à retenir!"
• Il oblige à une contre-vérification cognitive supplémentaire . Il place le type souhaité (présumé) juste à côté de l'arithmétique que vous faites pour la taille brute de cette variable. Je parie que vous pourriez faire une étude SO qui montre que les malloc()bugs sont détectés beaucoup plus rapidement quand il y a un casting. Comme pour les assertions, les annotations qui révèlent une intention réduisent les bogues.
• Se répéter d'une manière que la machine peut vérifier est souvent un excellente idée. En fait, c'est ce qu'est une assertion, et cette utilisation de cast est une assertion. Les assertions sont toujours la technique la plus générale que nous ayons pour obtenir un code correct, depuis que Turing a eu l'idée il y a tant d'années.

Comme d'autres l'ont dit, ce n'est pas nécessaire pour C, mais nécessaire pour C ++. Si vous pensez que vous allez compiler votre code C avec un compilateur C ++, pour quelque raison que ce soit, vous pouvez utiliser une macro à la place, comme:

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

De cette façon, vous pouvez toujours l'écrire de manière très compacte:

int *sieve = NEW(int, 1);

et il compilera pour C et C ++.

De Wikipédia :

Avantages de la coulée

• L'inclusion de la distribution peut permettre à un programme ou une fonction C de se compiler en C ++.

• La distribution permet des versions antérieures à 1989 de malloc qui renvoyaient à l'origine un caractère *.

• La conversion peut aider le développeur à identifier les incohérences de dimensionnement de type si le type de pointeur de destination change, en particulier si le pointeur est déclaré loin de l'appel malloc () (bien que les compilateurs modernes et les analyseurs statiques puissent avertir d'un tel comportement sans nécessiter la conversion).

Inconvénients du casting

• Selon la norme ANSI C, la distribution est redondante.

• L'ajout de la distribution peut masquer l'échec de l'inclusion de l'en-tête stdlib.h, dans lequel se trouve le prototype de malloc. En l'absence de prototype pour malloc, la norme exige que le compilateur C suppose que malloc renvoie un int. S'il n'y a pas de transtypage, un avertissement est émis lorsque cet entier est affecté au pointeur; cependant, avec le casting, cet avertissement n'est pas produit, cachant un bug. Sur certaines architectures et modèles de données (tels que LP64 sur les systèmes 64 bits, où long et les pointeurs sont 64 bits et int 32 bits), cette erreur peut en fait entraîner un comportement indéfini, car le malloc implicitement déclaré renvoie un 32- valeur binaire alors que la fonction réellement définie renvoie une valeur 64 bits. Selon les conventions d'appel et la disposition de la mémoire, cela peut entraîner un écrasement de la pile. Ce problème est moins susceptible de passer inaperçu dans les compilateurs modernes, car ils produisent uniformément des avertissements qu'une fonction non déclarée a été utilisée, donc un avertissement apparaîtra toujours. Par exemple, le comportement par défaut de GCC consiste à afficher un avertissement qui lit "déclaration implicite incompatible de fonction intégrée", que le transtypage soit présent ou non.

• Si le type du pointeur est modifié lors de sa déclaration, on peut également avoir besoin de changer toutes les lignes où malloc est appelé et cast.

Bien que malloc sans casting soit la méthode préférée et la plupart des programmeurs expérimentés la choisissent , vous devez utiliser celui que vous aimez avoir connaissance des problèmes.

ie: Si vous avez besoin de compiler un programme C en C ++ (bien qu'il s'agisse d'un langage séparé), vous devez transtyper le résultat de l'utilisation malloc.

En C, vous pouvez implicitement convertir un voidpointeur en tout autre type de pointeur, donc une conversion n'est pas nécessaire. En utiliser un peut suggérer à l'observateur occasionnel qu'il y a une raison pour laquelle il en faut un, ce qui peut être trompeur.

Vous ne lancez pas le résultat de malloc, car cela ajoute un encombrement inutile à votre code.

La raison la plus courante pour laquelle les gens lancent le résultat de malloc est qu'ils ne sont pas sûrs du fonctionnement du langage C. C'est un signe d'avertissement: si vous ne savez pas comment fonctionne un mécanisme de langage particulier, alors ne devinez pas. Cherchez ou demandez sur Stack Overflow.

Certains commentaires:

• Un pointeur vide peut être converti en / à partir de tout autre type de pointeur sans transtypage explicite (C11 6.3.2.3 et 6.5.16.1).

• C ++ n'autorisera cependant pas une conversion implicite entre void*et un autre type de pointeur. Donc, en C ++, la conversion aurait été correcte. Mais si vous programmez en C ++, vous devez utiliser newet non malloc (). Et vous ne devez jamais compiler de code C à l'aide d'un compilateur C ++.

  Si vous devez prendre en charge C et C ++ avec le même code source, utilisez les commutateurs du compilateur pour marquer les différences. N'essayez pas de rassasier les deux normes linguistiques avec le même code, car elles ne sont pas compatibles.

• Si un compilateur C ne peut pas trouver une fonction parce que vous avez oublié d'inclure l'en-tête, vous obtiendrez une erreur de compilateur / éditeur de liens à ce sujet. Donc, si vous avez oublié d'inclure<stdlib.h> ce n'est pas grave, vous ne pourrez pas créer votre programme.

• Sur les anciens compilateurs qui suivent une version de la norme qui a plus de 25 ans, en oubliant d'inclure <stdlib.h> entraînerait un comportement dangereux. Parce que dans cette ancienne norme, les fonctions sans prototype visible ont implicitement converti le type de retour en int. Le cast explicite du résultat de malloc cacherait alors ce bug.

  Mais ce n'est vraiment pas un problème. Vous n'utilisez pas un ordinateur de 25 ans, alors pourquoi utiliser un compilateur de 25 ans?

En C, vous obtenez une conversion implicite de void *vers tout autre pointeur (de données).

Cast de la valeur retournée par malloc() n'est plus nécessaire maintenant, mais je voudrais ajouter un point qui semble n'avoir été signalé par personne:

Dans les temps anciens, c'est-à-dire avant que l' ANSI C fournisse le void *type générique de pointeurs, char *c'est le type pour une telle utilisation. Dans ce cas, le cast peut fermer les avertissements du compilateur.

Référence: C FAQ

En ajoutant simplement mon expérience, en étudiant l'ingénierie informatique, je vois que les deux ou trois professeurs que j'ai vus écrire en C ont toujours fait du malloc, mais celui que j'ai demandé (avec un immense CV et une compréhension de C) m'a dit que c'était absolument inutile mais seulement utilisé pour être absolument spécifique, et pour amener les étudiants dans la mentalité d'être absolument spécifique. Fondamentalement, la conversion ne changera rien à son fonctionnement, elle fait exactement ce qu'elle dit, alloue de la mémoire et la diffusion ne l'affecte pas, vous obtenez la même mémoire, et même si vous la convertissez en autre chose par erreur (et en quelque sorte éludez le compilateur erreurs) C y accédera de la même manière.

Edit: Casting a un certain point. Lorsque vous utilisez la notation de tableau, le code généré doit savoir combien de mémoire il doit avancer pour atteindre le début de l'élément suivant, ceci est réalisé grâce à la conversion. De cette façon, vous savez que pour un double, vous avancez de 8 octets tandis que pour un int, vous passez 4, et ainsi de suite. Ainsi, cela n'a aucun effet si vous utilisez la notation de pointeur, en notation de tableau cela devient nécessaire.

Il n'est pas obligatoire de transtyper les résultats de malloc, car il renvoie void*, et a void*peut être pointé vers n'importe quel type de données.

Un pointeur vide est un pointeur d'objet générique et C prend en charge la conversion implicite d'un type de pointeur vide vers d'autres types, il n'est donc pas nécessaire de le transtyper explicitement.

Cependant, si vous voulez que le même code fonctionne parfaitement compatible sur une plate-forme C ++, qui ne prend pas en charge la conversion implicite, vous devez effectuer le transtypage, donc tout dépend de la convivialité.

Voici ce que dit le manuel de référence de la bibliothèque GNU C :

Vous pouvez stocker le résultat de mallocdans n'importe quelle variable de pointeur sans transtypage, car ISO C convertit automatiquement le type void *en un autre type de pointeur si nécessaire. Mais la conversion est nécessaire dans des contextes autres que les opérateurs d'affectation ou si vous souhaitez que votre code s'exécute en C. traditionnel

Et en effet, la norme ISO C11 (p347) le dit:

Le pointeur renvoyé si l'allocation réussit est correctement aligné de sorte qu'il peut être affecté à un pointeur sur n'importe quel type d'objet avec une exigence d'alignement fondamentale, puis utilisé pour accéder à un tel objet ou à un tableau de ces objets dans l'espace alloué (jusqu'à ce que le l'espace est explicitement désalloué)

Le type renvoyé est void *, qui peut être converti en le type de pointeur de données souhaité afin d'être déréférencable.

Dans le langage C, un pointeur void peut être affecté à n'importe quel pointeur, c'est pourquoi vous ne devez pas utiliser de transtypage de type. Si vous voulez une allocation "type sûr", je peux recommander les fonctions de macro suivantes, que j'utilise toujours dans mes projets C:

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

Avec ceux-ci en place, vous pouvez simplement dire

NEW_ARRAY(sieve, length);

Pour les tableaux non dynamiques, la troisième macro de fonction indispensable est

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

ce qui rend les boucles de tableau plus sûres et plus pratiques:

int i, a[100];

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

Cela dépend du langage de programmation et du compilateur. Si vous utilisez mallocen C, il n'est pas nécessaire de taper cast, car il saisira automatiquement cast. Cependant, si vous utilisez C ++, vous devez taper cast car mallocretournera un void*type.

Les gens habitués à GCC et Clang sont gâtés. Ce n'est pas si bon que ça.

J'ai été assez horrifié au fil des ans par les compilateurs incroyablement âgés que je devais utiliser. Souvent, les entreprises et les gestionnaires adoptent une approche ultra-conservatrice pour changer les compilateurs et ne testent même pas si un nouveau compilateur (avec une meilleure conformité aux normes et une optimisation du code) fonctionnera dans leur système. La réalité pratique pour les développeurs qui travaillent est que lorsque vous codez, vous devez couvrir vos bases et, malheureusement, la diffusion de mallocs est une bonne habitude si vous ne pouvez pas contrôler quel compilateur peut être appliqué à votre code.

Je suggérerais également que de nombreuses organisations appliquent leur propre norme de codage et que ce devrait être la méthode que les gens suivent si elle est définie. En l'absence de directives explicites, j'ai tendance à opter pour la compilation la plus probable partout, plutôt que l'adhésion servile à une norme.

L'argument selon lequel ce n'est pas nécessaire en vertu des normes actuelles est tout à fait valable. Mais cet argument omet les aspects pratiques du monde réel. Nous ne codons pas dans un monde régi exclusivement par la norme du jour, mais par les aspects pratiques de ce que j'aime appeler "le champ de réalité de la gestion locale". Et c'est plus courbé et tordu que l'espace-temps ne l'a jamais été. :-)

YMMV.

J'ai tendance à penser à lancer du malloc comme une opération défensive. Pas joli, pas parfait, mais généralement sûr. (Honnêtement, si vous n'avez pas inclus stdlib.h, vous avez bien plus de problèmes que de lancer malloc!).

J'ai mis le casting simplement pour montrer la désapprobation du trou laid dans le système de type, ce qui permet à du code tel que l'extrait suivant de compiler sans diagnostic, même si aucune conversion n'est utilisée pour provoquer la mauvaise conversion:

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

Je souhaite que cela n'existe pas (et ce n'est pas le cas en C ++) et j'ai donc casté. Il représente mon goût et ma politique de programmation. Non seulement je jette un pointeur, mais effectivement, je vote et je chasse les démons de la stupidité . Si je ne peux pas vraiment chasser la bêtise , au moins laissez - moi exprimer le souhait de le faire avec un geste de protestation.

En fait, une bonne pratique consiste à encapsuler malloc(et à vos amis) les fonctions qui reviennent unsigned char *, et à ne jamais utiliser void *dans votre code. Si vous avez besoin d'un pointeur générique vers n'importe quel objet, utilisez un char *ou unsigned char *et avez des transtypages dans les deux directions. La seule relaxation à laquelle on peut s'adonner, peut-être, est d'utiliser des fonctions comme memsetet memcpysans transtypage.

Sur le sujet de la conversion et de la compatibilité C ++, si vous écrivez votre code de sorte qu'il se compile à la fois en C et C ++ (auquel cas vous devez convertir la valeur de retour de malloclors de son affectation à autre chose que void *), vous pouvez faire une très utile chose pour vous: vous pouvez utiliser des macros pour la conversion qui se traduisent par des transtypages de style C ++ lors de la compilation en C ++, mais réduisent à une conversion C lors de la compilation en 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 vous adhérez à ces macros, une simple greprecherche dans votre base de code pour ces identifiants vous montrera où se trouvent toutes vos conversions, afin que vous puissiez vérifier si certaines d'entre elles sont incorrectes.

Ensuite, si vous compilez régulièrement le code avec C ++, cela imposera l'utilisation d'une conversion appropriée. Par exemple, si vous utilisez strip_qualsimplement pour supprimer un constou volatile, mais que le programme change de telle manière qu'une conversion de type est maintenant impliquée, vous obtiendrez un diagnostic et vous devrez utiliser une combinaison de transtypages pour obtenir la conversion souhaitée.

Pour vous aider à adhérer à ces macros, le compilateur GNU C ++ (pas C!) A une belle fonctionnalité: un diagnostic optionnel qui est produit pour toutes les occurrences de transtypages de style C.

     -Wold-style-cast (C ++ et Objective-C ++ uniquement)
         Avertir si une conversion à l'ancienne (style C) vers un type non nul est utilisée
         au sein d'un programme C ++. Les transtypages de nouveau style (dynamic_cast,
         static_cast, reinterpret_cast et const_cast) sont moins vulnérables
         aux effets inattendus et beaucoup plus facile à rechercher.

Si votre code C se compile en C ++, vous pouvez utiliser cette -Wold-style-castoption pour trouver toutes les occurrences de la (type)syntaxe de transtypage qui peuvent se glisser dans le code, et poursuivre ces diagnostics en le remplaçant par un choix approprié parmi les macros ci-dessus (ou un combinaison, si nécessaire).

Ce traitement des conversions est la plus grande justification technique autonome pour travailler dans un "Clean C": le dialecte combiné C et C ++, qui à son tour justifie techniquement la conversion de la valeur de retour de malloc.

La meilleure chose à faire lors de la programmation en C chaque fois que cela est possible:

1. Faites compiler votre programme via un compilateur C avec tous les avertissements activés -Wallet corrigez toutes les erreurs et avertissements
2. Assurez-vous qu'aucune variable n'est déclarée comme auto
3. Compilez-le ensuite à l'aide d'un compilateur C ++ avec -Wallet -std=c++11. Corrigez toutes les erreurs et avertissements.
4. Compilez maintenant à nouveau à l'aide du compilateur C. Votre programme devrait maintenant se compiler sans aucun avertissement et contenir moins de bogues.

Cette procédure vous permet de profiter de la vérification stricte de type C ++, réduisant ainsi le nombre de bogues. En particulier, cette procédure vous oblige à inclure stdlib.hou vous obtiendrez

malloc n'a pas été déclaré dans ce domaine

et vous oblige également à lancer le résultat de mallocou vous obtiendrez

conversion non valide de void*versT*

ou quel que soit votre type de cible.

Les seuls avantages de l'écriture en C au lieu de C ++ que je peux trouver sont

1. C a un ABI bien spécifié
2. C ++ peut générer plus de code [exceptions, RTTI, modèles, polymorphisme d' exécution ]

Notez que le deuxième inconvénient devrait dans le cas idéal disparaître lors de l'utilisation du sous-ensemble commun à C avec la caractéristique polymorphe statique .

Pour ceux qui trouvent les règles strictes C ++ incommodes, nous pouvons utiliser la fonctionnalité C ++ 11 avec le type déduit

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

Non, vous ne lancez pas le résultat de malloc().

En général, vous nevoid * lancez pas vers ou depuis .

Une raison typique donnée pour ne pas le faire est que le #include <stdlib.h> ne pas pouvoir passer inaperçu. Ce n'est plus un problème depuis longtemps car C99 a rendu illégales les déclarations de fonctions implicites , donc si votre compilateur se conforme au moins à C99, vous obtiendrez un message de diagnostic.

Mais il y a un raison beaucoup plus forte de ne pas introduire de lancers de pointeurs inutiles:

En C, une conversion de pointeur est presque toujours une erreur . Cela est dû à la règle suivante ( §6.5 p7 dans N1570, le dernier projet pour C11):

Un objet doit avoir sa valeur stockée accessible uniquement par une expression lvalue qui a l'un des types suivants:
- un type compatible avec le type effectif de l'objet,
- une version qualifiée d'un type compatible avec le type effectif de l'objet,
- un type qui est le type signé ou non signé correspondant au type effectif de l'objet,
- un type qui est le type signé ou non signé correspondant à une version qualifiée du type effectif de l'objet,
- un type d'agrégation ou d'union qui en inclut un parmi les types susmentionnés parmi ses membres (y compris, récursivement, un membre d'une union sous-agrégée ou contenue), ou
- un type de caractère.

Ceci est également connu sous le nom de règle d'alias stricte . Le code suivant est donc un comportement non défini :

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

Et, parfois de manière surprenante, ce qui suit est également:

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;

, Parfois vous ne devez pointeurs de la distribution, mais étant donné la règle stricte de aliasing , vous devez être très prudent avec elle. Ainsi, toute occurrence d'un pointeur transtypé dans votre code est un endroit où vous devez vérifier sa validité . Par conséquent, vous n'écrivez jamais une distribution de pointeur inutile.

tl; dr

En bref: parce qu'en C, toute occurrence d'une conversion de pointeur devrait déclencher un drapeau rouge pour le code nécessitant une attention particulière, vous ne devez jamais écrire de transtypages de pointeur inutiles .

Notes annexes:

• Il y a des cas où vous avez réellement besoin d' un cast void *, par exemple si vous souhaitez imprimer un pointeur:

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

  La printf()conversion est nécessaire ici, car c'est une fonction variadique, donc les conversions implicites ne fonctionnent pas.

• En C ++, la situation est différente. La conversion de types de pointeurs est quelque peu courante (et correcte) lorsque vous traitez des objets de classes dérivées. Par conséquent, il est logique qu'en C ++, la conversion vers et depuis void *n'est pas implicite. C ++ a tout un ensemble de différentes saveurs de casting.

Je préfère faire le casting, mais pas manuellement. Mon préféré utilise g_newet g_new0macros de glib. Si glib n'est pas utilisé, j'ajouterais des macros similaires. Ces macros réduisent la duplication de code sans compromettre la sécurité des types. Si vous vous trompez de type, vous obtiendrez un transtypage implicite entre des pointeurs non vides, ce qui entraînerait un avertissement (erreur en C ++). Si vous oubliez d'inclure l'en-tête qui définit g_newet g_new0, vous obtiendrez une erreur. g_newet les g_new0deux prennent les mêmes arguments, contrairement à malloccela prend moins d'arguments que calloc. Ajoutez simplement 0pour obtenir une mémoire initialisée à zéro. Le code peut être compilé avec un compilateur C ++ sans modifications.

La conversion est uniquement pour C ++ et non C. Dans le cas où vous utilisez un compilateur C ++, vous feriez mieux de le changer en compilateur C.

Le concept derrière le pointeur void est qu'il peut être converti en n'importe quel type de données, c'est pourquoi malloc renvoie void. Vous devez également être conscient de la conversion automatique de caractères. Il n'est donc pas obligatoire de lancer le pointeur bien que vous deviez le faire. Il aide à garder le code propre et aide au débogage

Un pointeur vide est un pointeur générique et C prend en charge la conversion implicite d'un type de pointeur vide vers d'autres types, il n'est donc pas nécessaire de le transtyper explicitement.

Cependant, si vous voulez que le même code fonctionne parfaitement compatible sur une plate-forme C ++, qui ne prend pas en charge la conversion implicite, vous devez effectuer le transtypage, donc tout dépend de la convivialité.

1. Comme d'autres l'ont dit, ce n'est pas nécessaire pour C, mais pour C ++.

2. L'inclusion de la distribution peut permettre à un programme ou une fonction C de se compiler en C ++.

3. En C, cela n'est pas nécessaire, car void * est automatiquement et en toute sécurité promu vers tout autre type de pointeur.

4. Mais si vous lancez alors, cela peut masquer une erreur si vous avez oublié d'inclure oubliez d' stdlib.h . Cela peut provoquer des plantages (ou pire, ne pas provoquer de plantages jusqu'à bien plus tard dans une partie totalement différente du code).

   Parce que stdlib.h contient le prototype pour malloc est trouvé. En l'absence de prototype pour malloc, la norme exige que le compilateur C suppose que malloc retourne un int. S'il n'y a pas de transtypage, un avertissement est émis lorsque cet entier est affecté au pointeur; cependant, avec le casting, cet avertissement n'est pas produit, cachant un bug.

La conversion de malloc n'est pas nécessaire en C mais obligatoire en C ++.

La conversion n'est pas nécessaire en C à cause de:

• void * est automatiquement et en toute sécurité promu vers tout autre type de pointeur dans le cas de C.
• Il peut masquer une erreur si vous avez oublié d'inclure <stdlib.h> . Cela peut provoquer des plantages.
• Si les pointeurs et les nombres entiers sont de tailles différentes, vous cachez un avertissement en transtypant et risquez de perdre des bits de votre adresse renvoyée.
• Si le type du pointeur est modifié lors de sa déclaration, il peut également être nécessaire de modifier toutes les lignes où mallocest appelé et transtypé.

D'un autre côté, la diffusion peut augmenter la portabilité de votre programme. c'est-à-dire qu'il permet à un programme ou une fonction C de se compiler en C ++.

Pour moi, le retour à la maison et la conclusion ici est que la conversion mallocen C n'est absolument PAS nécessaire, mais si vous effectuez une conversion, cela n'affectera pas malloccar mallocvous allouera toujours votre espace mémoire béni demandé. Un autre point à retenir est la raison ou l'une des raisons pour lesquelles les gens font du casting et c'est pour leur permettre de compiler le même programme en C ou C ++.

Il peut y avoir d'autres raisons, mais d'autres raisons, très certainement, vous causeraient de graves problèmes tôt ou tard.

Vous pouvez, mais n'avez pas besoin de transtyper en C. Vous devez transtyper si ce code est compilé en C ++.