Différence entre les malloc et calloc?

Quelle est la différence entre faire:

ptr = (char **) malloc (MAXELEMS * sizeof(char *));

ou:

ptr = (char **) calloc (MAXELEMS, sizeof(char*));

Quand est-ce une bonne idée d'utiliser calloc plus de malloc ou vice-versa?

En C, vous ne lancez pas le résultat de malloc famille
En C, vous pouvez écrire le ci-dessus de manière plus générale comme: ptr = calloc(MAXELEMS, sizeof(*ptr));
Un post intéressant sur la différence entre calloc et le malloc+memset vorpus.org/blog/why-does-calloc-exist
Moi aussi, je trouve que le blog, après je n'était pas satisfait avec tant de réponses sur le net. Nathaniel J. Smith mérite+ de 100 points pour son analyse.
Connexes: Peut calloc() allouer plus de SIZE_MAX au total?

InformationsquelleAutor user105033 | 2009-10-08

c calloc malloc

798

calloc() zéro-initialise la mémoire tampon, tandis que malloc() feuilles de la mémoire non initialisée.

EDIT:

Réinitialisation de la mémoire peut prendre un peu de temps, alors vous voudrez probablement utiliser malloc() si la performance est un problème. Si l'initialisation de la mémoire est de plus en plus important, l'utilisation calloc(). Par exemple, calloc() peut vous faire gagner un appel à memset().
- L' *alloc variantes sont assez mnémonique - clair-allocation de la mémoire alloc, re-alloc.
- Utiliser malloc() si vous voulez tout ce que vous utilisez dans l'espace alloué. Utiliser calloc() si vous vous apprêtez à quitter la partie des données non initialisées et il serait utile d'avoir les unset les pièces remises à zéro.
- calloc n'est pas nécessairement plus cher, puisque l'OS peut faire quelques trucs pour l'accélérer. Je sais que FreeBSD, quand il fait tout d'inactivité du PROCESSEUR temps, l'utilise pour exécuter un processus simple qui tourne et remet à zéro libéré des blocs de mémoire, et les marques de blocs ainsi les processus avec un drapeau. Ainsi, lorsque vous vous calloc, il tente d'abord de trouver l'un de ces pré-mise à zéro des blocs et simplement le donner à vous - et plus il a de chance de trouver un.
- À l'aide de calloc() est probablement plus sûr de parier en général, sauf si vous essayez d'optimiser chaque dernier peu de votre code (et même alors, comme d'autres l'ont souligné, vos efforts peuvent être vains).
- J'ai tendance à penser que si votre code devient plus "sécuritaire" comme un résultat de zéro-initing les affectations par défaut, puis votre code n'est pas suffisamment sûr de savoir si vous utilisez la fonction malloc ou calloc. À l'aide de malloc est un bon indicateur que les besoins en données d'initialisation - je n'utilise calloc dans les cas où ceux-0 octets sont réellement significatif. Notez également que calloc n'est pas nécessairement ce que vous en pensez pour les non-char types. Personne n'utilise le piège des représentations plus ou de non-IEEE flotteurs, mais qui n'est pas une excuse pour penser que votre code est vraiment portable quand elle ne l'est pas.
- "Plus sûr" est probablement une exagération, c'est plus comme "plus de risque de crash plutôt que silencieusement les données corrompues" - qui est toujours d'actualité pour le code de sécurité (comme un dernier rempart de la défense), et cela rend les choses plus facile à déboguer se bloque. Cela dit, très bon point sur float (et d'autres types pour lesquels tous les bits 0 ne peut pas dire ce que vous pensez qu'ils signifient).
- malloc(foolen); assert(foo && memset(foo,0,foolen)); couvre le débogage aspect, ou vous pouvez utiliser un eye-catcher octet autre que 0. À partir de la dernière ligne de la sécurité POV, il serait peut-être mieux de faire un lien avec une version de malloc qui efface les octets (ou des ensembles à un eye-catcher pointeur de la taille de la valeur, qui est associé à la non-lisible et non-inscriptible), plutôt que d'avoir une politique d'appel calloc à la place?
- J'aime cette idée. Je pense à l'écriture d'un simple débogage orientée malloc parfois à l'aide de mmap pour chaque allocation avec une page de garde à droite après la dernière alloués octet, et je pourrais intégrer votre idée pour le remplissage de la mémoire avec un crash induisant la valeur du pointeur de trop.
- voulais juste pour se plaindre de "Un Livre sur le C", qui décrit calloc comme "Alloue de l'espace contigu". "c" pour "contigu", hein? Bizarre. "Claire" a du sens. Kernighan pense que cela veut dire clair, trop quora.com/C-programming-language/...
- et certains de la source de calloc commentaires calloc - allocate and clear memory block minnie.tuhs.org/cgi-bin/utree.pl?file=V7M/src/libc/gen/calloc.c à Partir de JimBalter commentaire ici stackoverflow.com/a/12555996/50979
- n'est-ce pas le bon mot. Je pense que "Déterministe" est le meilleur terme. Le Code qui est plus déterministe plutôt que d'avoir des pannes qui dépend du moment et les séquences de données, sera plus facile à isoler les échecs. Calloc est parfois un moyen facile d'obtenir que le déterminisme, par rapport à l'initialisation explicite.
- le point les gens font, c'est que si votre code de comportement ou même le chemin d'exécution dépend du contenu de la mémoire non initialisée, c'est généralement un problème là. Il y a certains cas où vous pouvez prouver que c'est ok pour le faire, comme research.swtch.com/sparse, mais c'est très exceptionnel.
- tout à fait d'accord. Je pense que c'est certainement mieux préférer déterministe d'un code non déterministe code. Pavel fait le point. Si vous avez un bug qui involontairement lit non-initialisé la mémoire, préférez-vous le son de lecture aléatoire de données, ou des données nulles?
- Juste pour ajouter: calloc ajoute une autre mesure défensive: il est généralement enregistrer à l'encontre de dépassement d'entier, par exemple dans la glibc, on vérifie que la taille multipliée par le nombre d'éléments n'a pas enveloppement au maximum de size_t limite. Habituellement, vous ne vérifiez pas de débordement lorsque vous appelez la fonction malloc et multipliez la taille d'un élément en nombre d'éléments, mais calloc le fait pour vous et ne parvient pas à l'appel, si elle déborde; (en fait, c'est quelque chose qui peut être exploitée que si vous déduire de ces valeurs à partir d'un message que vous venez de lire sur le net).
- Sujet FreeBSD processus qui tourne autour de la réinitialisation de la mémoire. Avez-vous des références sur elle? Je trouve cette idée très intéressante...
- J'ai écrit un artificiel scénario à propos de malloc et de la sécurité. Si la fonction malloc n'est pas mise à zéro de la mémoire, puis-je prendre du noyau.
- Sur votre système d'exploitation, avec votre compilateur, avec cette version du compilateur, avec les options de compilation que vous avez spécifié, qui peut être le cas. Ne comptez pas sur elle pour quelque chose d'important.
- Vous pouvez ajouter une note à ce sujet: bien que la plupart des plateformes modernes représentent le pointeur null comme tous les bits à zéro, la Norme ne garantit pas que les éléments du tableau alloué par calloc() peut raisonnablement supposer être initialisé à la NULL pointeur.
- Est-il exact de dire que la mémoire allouée à la fois dans le cas off calloc et malloc sont contigus dans la nature. J'ai lu ici qui - The only difference between malloc() and calloc() is that, malloc() allocates single block of memory whereas calloc() allocates multiple blocks of memory each of same size and sets all bytes to zero. je crois que c'est incorrect. N'est-ce pas? Je crois calloc a obtenu son nom de clear allocated memory c'est à dire zéro de la mémoire allouée, qui est la seule différence quand je le compare à malloc.
- "peut vous faire gagner un appel à memset(..)" Ce qui serait intéressant, c'est, lequel est le plus rapide 1. malloc(..) & memset(..), ou calloc(..).
- Je pourrais certainement imaginer une alloc suivie par une boucle à 0000 0000 tous les octets. Là où je voulais que le résultat, calloc seul semble mieux.
- Qui a répondu dans un commentaire de ddddavidee sur la question d'origine. S'avère calloc peut être beaucoup plus rapide (100x). L'article a été une très bonne lecture. Il y avait une autre grande différence là aussi--en Passant par 2 opérandes permet calloc erreur-vérifiez les grandes affectations où malloc serait juste de débordement et de retour d'un tampon avec moins de mémoire que vous avez demandé.
InformationsquelleAutor Fred Larson
352

Un moins connu différence est que, dans les systèmes d'exploitation avec optimiste de l'allocation de mémoire, comme Linux, le pointeur retourné par malloc n'est pas étayée par l'utilisation de la mémoire jusqu'à ce que le programme fait la touche.

calloc , en effet, toucher la mémoire (il écrit des zéros) et ainsi vous serez sûr que l'OS est la sauvegarde de la répartition réelle de la RAM (ou swap). C'est aussi pourquoi il est plus lent que malloc (pas seulement à zéro, l'OS doit également trouver une zone de mémoire par éventuellement échanger des autres processus)

Voir, par exemple, cette SORTE de question pour la poursuite de la discussion sur le comportement de la fonction malloc
- calloc n'a pas besoin d'écrire des zéros. Si le bloc alloué se compose essentiellement de nouveau à zéro des pages fournies par le système d'exploitation, il peut laisser intacte. Bien sûr, cela nécessite calloc à être à l'écoute pour le système d'exploitation plutôt que d'une bibliothèque générique de la fonction sur le dessus de malloc. Ou, un réalisateur pourrait faire calloc comparer chaque mot contre zéro avant la mise à zéro il. Ce ne serait pas sauver tout le temps, mais il permettrait d'éviter de salir les nouvelles pages.
- note intéressante. Mais dans la pratique, ces implémentations existent dans la nature?
- Tous les dlmalloc-comme les implémentations de sauter le memset si le morceau a été obtenu par mmaping nouveau les pages anonymes (ou l'équivalent). Généralement ce type de répartition est utilisée pour les plus grands morceaux, en commençant à 256k ou donc. Je ne sais pas du tout implémentations qui ne la comparaison par rapport à zéro avant d'écrire de zéro en dehors de mon propre.
- omalloc aussi saute le memset; calloc n'a pas besoin de toucher à toutes les pages qui ne sont pas déjà utilisés par l'application (le cache de la page), jamais. Cependant, extrêmement primitif calloc implémentations différent.
- glibc calloc vérifie si elle devient la mémoire de frais de l'OS. Si oui, elle sait qu'elle N'a PAS besoin de l'écrire, parce que mmap(..., MAP_ANONYMOUS) renvoie la mémoire qui est déjà remis à zéro.
- Sur Windows VirtualAlloc alloue également de pré-mise à zéro de la mémoire.
- aussi cela dépend si la répartition s'étend sur plusieurs pages de mémoire virtuelle ou non; si elle correspond à la page en cours, puis le plus souvent il y a une arène en-tête qui est avant le retour de la mémoire et qui doit être modifié, ce qui fait de tourner la page en sale état. (lié à la question parle d'un très gros répartition qui s'étend sur plusieurs pages)
InformationsquelleAutor Isak Savo
104

Un souvent négligé, l'avantage de calloc est que (des implémentations conformes aux) il vous aidera à vous protéger contre les vulnérabilités de type débordement d'entier. Comparer:
```
size_t count = get_int32(file);
struct foo *bar = malloc(count * sizeof *bar);
```
vs
```
size_t count = get_int32(file);
struct foo *bar = calloc(count, sizeof *bar);
```
L'ancien pourrait entraîner une petite allocation et suivantes dépassements de la mémoire tampon, si count est plus grand que SIZE_MAX/sizeof *bar. Ce dernier échouera automatiquement dans ce cas comme un objet que les grands ne peuvent pas être créés.

Bien sûr, vous pourriez avoir à être à l'affût de la non-conforme implémentations qui ignorent tout simplement la possibilité de débordement... Si c'est un souci sur les plates-formes que vous ciblez, vous devrez faire un test manuel pour le débordement de toute façon.
- Apparemment, le dépassement de capacité arithmétique a été ce qui a causé OpenSSH trou en 2002. Bon article à partir d'OpenBSD sur les dangers de ce mémoire, les fonctions liées: undeadly.org/cgi?action=article&sid=20060330071917
- Intéressant. Malheureusement, l'article est lié a la désinformation dès le début. L'exemple avec char est pas un dépassement de capacité, mais plutôt une mise en œuvre conversion définie lors de l'affectation du résultat dans un char objet.
- C'est là sans doute à des fins d'illustration seulement. Parce que le compilateur est susceptible d'optimiser ce que l'écart de toute façon. Mine compile dans cet asm: appuyez sur 1.
- Vous devriez noter quelque part dans cette réponse que vous prenez un 32 bits size_t parce que je ne vois pas de problème quand size_t est de 64 bits de large.
- Ce n'est pas que le code est exploitable sur toutes les implémentations, mais que c'est une erreur sans hypothèses supplémentaires et donc de ne pas corriger/portable utilisation.
- Le truc, c'est que certaines personnes (moi) programme exclusivement sur 64 bits machines. J'ai dû rayer de ma tête vraiment long à même de voir où le débordement des risques a été. S'il y avait eu une mention de la taille de size_t il aurait été évident. Certes, c'est mon problème que je développe maintenant uniquement sur 64 bits des machines, mais l'évidence n'est pas nécessairement le même que d'autres (par exemple, je suis vraiment bon à trouver des int débordements dans le code de gens avec un 32 bits modèle mental).
- Si votre mode de pensée est "size_t est en 64 bits, donc c'est pas un problème", c'est une façon erronée de penser qui va conduire à des bugs de sécurité. size_t est un type abstrait qui représente tailles, et il n'y a aucune raison de penser que l'arbitraire du produit d'un nombre de 32 bits et un size_t (note: sizeof *bar pourrait, en principe, être supérieur à 2^32 sur 64 bits C mise en œuvre!) s'inscrit dans size_t.
- Non seulement vous aurez un problème avec 32-Bit size_t, si size_t est de 16 Bits (ou toute valeur entre) vous auriez également un problème (ce qui est fréquent sur les Microcontrôleurs qui ont souvent moins de 64KiB espace total).
InformationsquelleAutor R..
32

De la documentation rend la calloc ressembler à malloc, qui n'a tout simplement zéro-initialiser la mémoire; ce n'est pas la principale différence! L'idée de calloc est à abstraite de copie sur écriture de la sémantique pour l'allocation de la mémoire. Lorsque vous allouez de la mémoire avec calloc il toutes les cartes à la même page physique qui est initialisé à zéro. Lorsque l'une des pages de la mémoire allouée est écrit dans une page physique est attribué. Ceci est souvent utilisé de faire de grandes tables de hachage, par exemple depuis les pièces de hachage qui sont vides ne sont pas soutenu par une mémoire supplémentaire (pages); ils sont heureux de point de le seul initialisé à zéro de la page, qui peut être partagée entre plusieurs processus.

Tout écrire à l'adresse virtuelle est mappé à une page, si la page est le zéro-page, une autre page physique est affecté, le zéro de la page est copiée là et le flux de contrôle est renvoyé au client processus. Cela fonctionne de la même manière que les fichiers mappés en mémoire, la mémoire virtuelle, etc. du travail.. il utilise la pagination.

Voici une optimisation de l'histoire sur le sujet:
http://blogs.fau.de/hager/2007/05/08/benchmarking-fun-with-calloc-and-zero-pages/

InformationsquelleAutor t0rakka
26

Il n'y a pas de différence dans la taille du bloc de mémoire alloué. calloc seulement remplit le bloc de mémoire physique de tous les zéro-bits motif. Dans la pratique, il est souvent supposé que les objets situés dans le bloc de mémoire alloué avec calloc ont initilial valeur que s'ils ont été initialisés avec littérale 0, c'est à dire les entiers doivent avoir une valeur de 0, virgule flottante variables - la valeur de 0.0, les pointeurs, - la bonne de pointeur null valeur, et ainsi de suite.

De la pédant point de vue cependant, calloc (ainsi que memset(..., 0, ...)) n'est garanti que pour initialiser correctement (avec des zéros) les objets de type unsigned char. Tout le reste n'est pas garanti d'être correctement initialisé et peut contenir des dits piège de la représentation, ce qui provoque un comportement indéfini. En d'autres termes, pour tout type autre que unsigned char ladite tous les zéro-bits patterm pourrait représenter une valeur illégale, le piège de la représentation.

Plus tard, dans l'un des Rectificatifs Techniques de standard C99, le comportement a été définie pour tous les types d'entiers (ce qui est logique). I. e. officiellement, dans le courant du langage C, vous pouvez initialiser uniquement les types d'entiers avec calloc (et memset(..., 0, ...)). À l'aide d'initialiser autre chose dans le cas général, conduit à un comportement indéfini, du point de vue du langage C.

Dans la pratique, calloc œuvres, comme nous le savons tous :), mais si vous voulez l'utiliser (vu ci-dessus) est à vous. Personnellement, je préfère l'éviter complètement, utiliser malloc place et faire de mon propre initialisation.

Enfin, un autre détail important est que calloc est nécessaire pour calculer le dernier bloc de la taille de en interne, en multipliant la taille de l'élément par le nombre d'éléments. Tout en faisant cela, calloc devez regarder pour un possible dépassement de capacité arithmétique. Il en résultera d'échec d'allocation (pointeur null) si la taille de bloc demandée ne peut pas être correctement calculée. Pendant ce temps, votre malloc version ne tente pas de le regarder pour le débordement. Il alloue une partie "imprévisible" de la quantité de mémoire en cas de débordement se produit.
- Par la "un autre détail important" de ce paragraphe: "qui semble faire de memset(p, v, n * sizeof type); un problème parce que n * sizeof type peut déborder. Suppose que je vais avoir besoin d'utiliser un for(i=0;i<n;i++) p[i]=v; boucle robuste code.
- Il serait utile si il y avait un moyen standard par le code qui pourrait affirmer qu'une mise en œuvre doit utiliser tous les bits à zéro comme un pointeur null (refus de compilation autrement), depuis qu'il existe des implémentations d'utiliser d'autres pointeur null représentations, mais ils sont relativement rares; code qui ne doit pas fonctionner sur leur mise en œuvre peut être plus rapide si elle peut utiliser calloc() ou memset pour initialiser des tableaux de pointeurs.
- vorpus.org/blog/why-does-calloc-exist
- Non, si un tableau avec n éléments existent, où un élément de la taille sizeof type, puis n*sizeof type ne peut pas déborder, parce que la taille maximale d'un objet doit être inférieure à SIZE_MAX.
- Vrai à propos d'un array taille <= SIZE_MAX, mais il n'y a pas les tableaux ici. Le pointeur retourné à partir de calloc() peut pointer vers la mémoire allouée que dépasse SIZE_MAX. De nombreuses implémentations ne limite le produit des 2 arguments pour calloc() à SIZE_MAX, mais la C spec ne pas imposer cette limite.
InformationsquelleAutor AnT
20

d'un article L'analyse comparative du plaisir avec calloc() et zéro pages sur Georg Hager Blog

Lors de l'allocation de la mémoire à l'aide de calloc(), la quantité de mémoire requise n'est pas alloué tout de suite. Au lieu de cela, toutes les pages qui appartiennent à la mémoire de bloc sont connectés à une seule page contenant tous les zéros par certains MMU magie (liens ci-dessous). Si ces pages sont en lecture seule (ce qui était vrai pour les tableaux b, c et d dans la version originale de l'indice de référence), les données sont fournies à partir de l'unique zéro de la page, qui – bien sûr – s'inscrit dans le cache. Autant pour la mémoire de la boucle de grains. Si une page est écrit (peu importe comment), une erreur se produit, la page de “vrai” est mappé et le zéro de la page est copiée dans la mémoire. Ceci est appelé copy-on-write, une approche d'optimisation (que je n'ai même enseigné à plusieurs reprises dans mon C++ conférences). Après cela, le zéro-lire astuce ne fonctionne pas plus pour que la page et c'est pourquoi le rendement est donc beaucoup plus faible après l'insertion de la – soi-disant redondant – initialisation de la boucle.
- où est le lien?
- première ligne de la réponse contient de lien vers Georg Hager Blog.
InformationsquelleAutor Ashish Chavan
11

calloc est généralement malloc+memset à 0

Il est généralement un peu mieux utiliser malloc+memset explicitement, en particulier lorsque vous faites quelque chose comme:
```
ptr=malloc(sizeof(Item));
memset(ptr, 0, sizeof(Item));
```
C'est mieux parce que sizeof(Item) est savoir pour le compilateur au moment de la compilation et le compilateur dans la plupart des cas, le remplacer avec le meilleur des instructions à zéro de la mémoire. D'autre part, si memset qui se passe dans calloc, le paramètre de taille de l'allocation n'est pas compilé dans le calloc code et réel memset est souvent appelé, qui pourrait contenir le code-octet par octet de remplissage jusqu'long de la frontière, que le cycle de remplissage de la mémoire dans sizeof(long) morceaux et enfin, octet par octet, remplir l'espace restant. Même si l'allocation est assez intelligent pour appeler quelques - aligned_memset il sera toujours un générique en boucle.

Une exception notable lorsque vous faites malloc/calloc d'une très grande partie de la mémoire (certains power_of_two kilo-octets), auquel cas l'allocation peut être fait directement à partir du noyau. Comme OS de noyaux généralement à zéro, toute la mémoire qu'ils donnent à l'écart pour des raisons de sécurité, assez intelligent calloc pourrait juste retourner supplémentaires sans réduction à zéro. Encore une fois - si vous êtes juste de l'allocation de quelque chose que vous savez est petite, vous pourriez être mieux avec malloc+memset de performance.
- +1 pour le rappel qu'un générique de la mise en œuvre d'une fonctionnalité dans un système de bibliothèque n'est pas nécessairement plus rapide que la même opération dans le code de l'utilisateur.
- Il existe également un deuxième point qui font calloc() plus lent que malloc(): la multiplication de la taille. calloc() est nécessaire pour utiliser un générique de multiplication (si size_t est de 64 bits, même le très coûteux 64 bits*64 bits=64 bits opération), tandis que la fonction malloc() auront souvent une compilation constante de temps.
- la glibc calloc a une certaine intelligence de décider de la façon la plus efficiente de claire le retour de morceau, par exemple, parfois seulement une partie des besoins de compensation, et aussi un déroulé clair jusqu'à 9*sizeof(size_t). La mémoire est la mémoire, l'effacement de 3 octets à la fois ne va pas être plus rapide tout simplement parce que vous êtes alors en vais l'utiliser pour tenir struct foo { char a,b,c; };. calloc est toujours mieux que malloc+memset, si vous allez toujours à effacer toute malloced région. calloc a une prudente mais efficace de vérifier int dépassement au niveau de la taille * éléments de, trop.
InformationsquelleAutor virco
8

Différence 1:

malloc() généralement alloue le bloc de mémoire et il est initialisé segment de mémoire.

calloc() alloue le bloc de mémoire et d'initialiser tous les bloc de mémoire à 0.

Différence 2:

Si vous considérez malloc() syntaxe, il faudra seulement 1 argument. Considérons l'exemple suivant ci-dessous:
```
data_type ptr = (cast_type *)malloc( sizeof(data_type)*no_of_blocks );
```
Ex: Si vous souhaitez allouer 10 bloc de mémoire pour le type int,
```
int *ptr = (int *) malloc(sizeof(int) * 10 );
```
Si vous considérez calloc() syntaxe, il faudra 2 arguments. Considérons l'exemple suivant ci-dessous:
```
data_type ptr = (cast_type *)calloc(no_of_blocks, (sizeof(data_type)));
```
Ex: si vous souhaitez allouer 10 blocs de mémoire de type int et Initialiser tous à ZÉRO,
```
int *ptr = (int *) calloc(10, (sizeof(int)));
```
Similitude:

Les deux malloc() et calloc() sera de retour void* par défaut si elles ne sont pas de type coulé .!
- Et pourquoi voulez-vous garder data_type et cast_type différents ?
InformationsquelleAutor Shivaraj Bhat
7

Il y a deux différences.

Tout d'abord, est le nombre d'arguments. malloc() prend un seul argument (de mémoire, en octets), alors que calloc() a besoin de deux arguments.

Deuxièmement, malloc() ne pas initialiser la mémoire allouée, alors que calloc() initialise la mémoire allouée à ZÉRO.
- calloc() alloue une zone mémoire, la longueur sera le produit de ses paramètres. calloc remplit la mémoire à ZÉRO et retourne un pointeur vers le premier octet. Si elle ne parvient pas à trouver assez d'espace, il renvoie une NULL pointeur.
Syntaxe: ptr_var=(cast_type *)calloc(no_of_blocks , size_of_each_block);
c'est à dire ptr_var=(type *)calloc(n,s);
- malloc() alloue un bloc de mémoire de REQUSTED TAILLE et retourne un pointeur vers le premier octet. Si elle ne parvient pas à trouver requsted quantité de mémoire il retourne un pointeur null.
Syntaxe: ptr_var=(cast_type *)malloc(Size_in_bytes);
Le malloc() prise de fonction à un argument, qui est le nombre d'octets à allouer, tandis que le calloc() fonction prend deux arguments, l'un étant le nombre d'éléments, et l'autre étant le nombre d'octets à allouer pour chacun de ces éléments. Aussi, calloc() initialise l'espace alloué pour les zéros, alors que malloc() ne pas.

InformationsquelleAutor Jainendra
6

La calloc() fonction qui est déclarée dans le <stdlib.h> en-tête offre quelques avantages par rapport à la malloc() fonction.
1. Il alloue de la mémoire, comme un certain nombre d'éléments d'une taille donnée, et
2. Il initialise la mémoire est allouée afin que tous les bits sont
  zéro.
InformationsquelleAutor Vipin Diwakar
5

Une différence pas encore parlé: limite de taille

void *malloc(size_t size) ne peut allouer jusqu'à SIZE_MAX.

void *calloc(size_t nmemb, size_t size); peut allouer environ SIZE_MAX*SIZE_MAX.

Cette capacité n'est pas souvent utilisé dans de nombreuses plates-formes avec adressage linéaire. De tels systèmes limite calloc() avec nmemb * size <= SIZE_MAX.

Envisager un type de 512 octets appelé disk_sector et le code veut utiliser beaucoup de secteurs. Ici, le code ne peut utiliser jusqu'à SIZE_MAX/sizeof disk_sector secteurs.
```
size_t count = SIZE_MAX/sizeof disk_sector;
disk_sector *p = malloc(count * sizeof *p);
```
De considérer les éléments suivants qui permet une plus grande allocation.
```
size_t count = something_in_the_range(SIZE_MAX/sizeof disk_sector + 1, SIZE_MAX)
disk_sector *p = calloc(count, sizeof *p);
```
Maintenant, si un tel système peut fournir un tel grand répartition est une autre affaire. La plupart aujourd'hui ne le sera pas. Pourtant, il y a eu pendant de nombreuses années lorsque SIZE_MAX a 65535. Compte tenu de La loi de Moore, pensez que cela va se produire à propos de 2030, avec certains modèles de mémoire avec SIZE_MAX == 4294967295 et des pools de mémoire dans le 100 de Go.
- Généralement, size_t sera capable de tenir la taille de la plus grande espèce d'objet d'un programme peut gérer. Un système où size_t est de 32 bits est peu probable d'être en mesure de traiter une allocation supérieure à 4294967295 octets, et un système qui serait capable de gérer les allocations de la taille serait presque certainement faire size_t de plus de 32 bits. La seule question est de savoir si l'aide calloc avec les valeurs dont le produit est supérieure à SIZE_MAX pourrait être invoqué pour un rendement de zéro plutôt que de retourner un pointeur vers une petite allocation.
- D'accord à propos de votre généralisation, mais la C spec permet calloc() allocations dépassant SIZE_MAX. Il est arrivé dans le passé avec 16 bits size_t et que la mémoire continue à les rabaisser, je ne vois pas pourquoi il ne peut pas se passer d'aller de l'avant, même si c'est pas commune.
- Le C Standard rend possible pour le code de demande une allocation dont la taille dépasse SIZE_MAX. Il n'est certainement pas exiger toute circonstance où une telle répartition peut réussir; je ne suis pas sûr qu'il y a tout avantage particulier de rendre obligatoire que les implémentations qui ne peut pas gérer ces allocations doivent retourner NULL (en particulier étant donné que c'est commun pour certaines implémentations d'avoir malloc renvoient des pointeurs à l'espace qui n'est pas encore engagé et peuvent ne pas être disponibles lorsque le code réellement essaie de l'utiliser).
- De plus, là où il peut y avoir des systèmes dans le passé, la plage d'adresses dépassé le plus grand entier représentable, je ne vois aucune possibilité réaliste de que plus jamais se produire, car cela impliquerait une capacité de stockage de milliards de gigaoctets. Même si la Loi de Moore a continué à tenir, va à partir du point où 32 bits cesse d'être assez au point où 64 bits cessé d'être assez prendrait deux fois plus long que le point où 16 bits a été suffisamment au point où 32 ne l'était pas.
- pas sûr qu'il y a tout avantage particulier de rendre obligatoire que les implémentations qui ne peut pas gérer cette répartition doit retourner NULL " --> conformité d'Une implémentation C "La calloc fonction retourne un pointeur null ou un pointeur vers l'espace alloué." Il ne dispense pas de maths de dépassement de nmemb * size > SIZE_MAX.
- possibilité de que plus jamais se produire, car cela impliquerait une capacité de stockage de milliards de gigaoctets" --> Mémoire dépassant 4G est suffisant pour considérer que les architectures utilisant un calloc() qui retourne une des pointeurs vers la mémoire > SIZE_MAX (4G-1).
- Pourquoi une mise en œuvre qui peut accueillir une allocation unique dans l'excès de la 4G définissent pas size_t à uint64_t?
- Laissez-nous continuer cette discussion dans le chat.
InformationsquelleAutor chux
4

malloc() et calloc() sont des fonctions de la bibliothèque C standard qui permettent d'allocation dynamique de la mémoire, en ce sens qu'ils permettent à la fois de l'allocation de mémoire en cours d'exécution.

Leurs prototypes sont comme suit:
```
void *malloc( size_t n);
void *calloc( size_t n, size_t t)
```
Il y a principalement deux différences entre les deux:
- Comportement: malloc() alloue un bloc de mémoire, sans l'initialiser, et la lecture de contenu à partir de ce bloc de résultat dans les ordures valeurs. calloc(), d'autre part, alloue un bloc de mémoire et l'initialise à zéros, et, évidemment, en lisant le contenu de ce bloc va entraîner des zéros.
- Syntaxe: malloc() prend 1 argument (de la taille à allouer), et calloc() prend deux arguments (nombre de blocs alloués et la taille de chaque bloc).
La valeur de retour de deux est un pointeur vers le bloc alloué de la mémoire, en cas de succès. Sinon, NULL sera renvoyé indiquant l'échec d'allocation de mémoire.

Exemple:
```
int *arr;

//allocate memory for 10 integers with garbage values
arr = (int *)malloc(10 * sizeof(int)); 

//allocate memory for 10 integers and sets all of them to 0
arr = (int *)calloc(10, sizeof(int));
```
Les mêmes fonctionnalités que calloc() peut être réalisé en utilisant malloc() et memset():
```
//allocate memory for 10 integers with garbage values   
arr= (int *)malloc(10 * sizeof(int));
//set all of them to 0
memset(arr, 0, 10 * sizeof(int)); 
```
Noter que malloc() est utilisé de préférence sur calloc() car c'est plus rapide. Si l'initialisation à zéro des valeurs est voulu, utilisez calloc() à la place.

InformationsquelleAutor elmiomar
0

Pas de blocs:

malloc() Affecte seul bloc de demandé de mémoire,

calloc() Affecte plusieurs blocs de la mémoire demandée

Initialisation:

malloc() n'est pas claire et initialiser la mémoire allouée.

calloc() initialiser la mémoire allouée par zéro.

Vitesse:

malloc() la vitesse est Rapide.

calloc() la vitesse est Relativement lente.

Syntex:
```
void *malloc(size_t size);                   //syntex for malloc() function
void *calloc(size_t num, size_t size);       //syntex for calloc() function
```
Argument:

Si vous envisagez de malloc() de la syntaxe, il faudra seulement 1 argument.

Si vous envisagez de calloc() de la syntaxe, il faudra 2 arguments.

Manière de l'Allocation de mémoire::

malloc() fonction alloue de la mémoire, de la "taille" à partir de la tas.

calloc() fonction alloue de la mémoire qui est la taille de ce qui est égal à ‘num *taille".

Sens sur le nom:

Le nom de la fonction malloc moyens attribués à l'allocation de la mémoire.

Le nom de calloc signifie allocation contiguë.

InformationsquelleAutor Majbah Habib

Vous devez vous connecter pour publier un commentaire.