disons que je veux allouer de manière dynamique la mémoire mais avec une fonction au lieu de la fonction principale ().
J'ai donc essayé de le faire: p> alors je Réalisé: Même si la mémoire allouée sur le tas est disponible pour la durée de vie du programme, cette mémoire ne peut être référencée que par argument formel alors comment puis-je affecter de manière dynamique la mémoire avec une fonction? P> p> FPTR code> et non l'argument réel (appelons-le
APTR code >). Mais une fois, la fonction est excitée, cette mémoire est perdue. P>
4 Réponses :
Cette mémoire ne peut être référencée que par argument formel
FPTR code> et non l'argument réel (appelons-le
APtr code>). P>
APTR code> ne peut pas désigner à l'objet de mémoire de tas avant em> l'appel sur
dynamalloc () code> car l'objet n'a pas encore été attribué et son adresse attribué à
APTR code> auge
FPTR code>. Par la suite
APTR code> faire em> référence l'objet de tas. P>
Nous devons simplement passer l'adresse du pointeur de
APTR code> à < Code> dynamalloc () code>. Vous avez donc besoin d'arguments appropriés (arguments réels) et de paramètres (arguments formels) pour transmettre l'adresse du pointeur
APTR code> entre les fonctions, comme vous le voyez ci-dessous. P>
Alors, comment puis-je affecter de manière dynamique la mémoire avec une fonction? P> blockQuote>
Vous le faites comme si vous le faites
principal () code>, il n'a pas d'importance si le pointeur était déclaré à l'intérieur de
principal () code> ou une autre fonction, Il vous suffit de passer l'adresse du pointeur
APTR code> sur les autres fonctions, dans laquelle vous souhaitez utiliser l'objet de mémoire de tas, comme Fe: p>
xxx pré> < HR> N'oubliez pas de
gratuit () code> la mémoire de tas! p> blockquote>
Il restera intact en mémoire après la terminaison du programme i> b>. Le système d'exploitation ne revendiquera-t-il pas toute la mémoire allouée à un programme?
ou simplement le faire comme ceci: et l'utilisation des futures: p> mais double point de pointeur peut se lenter Certaines conditions, répondent avec le retour dans la fucntion OD de fin, la copie de ce pointeur local est une meilleure pratique. p> p>
Comme c requis, il peut être fait comme ça int * pTR = (int *) null; code>
Votre fonction dépend des variables globales. Ne quittez pas le programme dans une telle fonction.
Ce n'est pas la fin de la foulée, ce n'est pas un cas de le réparer, comme l'ingénieur de firmware intégré, je ferais de nombreuses autres modifications à ce code, en commençant par ce que la fonction dans ce cas est la perte de temps de processeur, à moins que votre type de wrapper soit Ce malloc qui peut vérifier les octets fuites plus tard, le bus encore, un meilleur choix est de rendre cette wrapper en ligne-avec macro.
@Johnysiemanokolano Vous dites donc que int * dynamalloc (int * fptr) code> est plus rapide (je suppose que c'est mieux?), C'est-à-dire une adresse de retour dans le tas, c'est mieux que la syntaxe à double pointeur? Une raison pour laquelle on utiliserait une double syntaxe de pointeur sur th th th the
En outre, j'ai lu que la valeur de retour de casting de MALLOC est une mauvaise pratique. Voir Stackoverflow.com/q/605845/10701114 . C'est pourquoi je n'ai pas lancé le mien par opposition à votre commentaire après la déclaration Malloc () Code>. Certains disent que le casting n'est plus mauvais en fonction des commentaires sur le lien.
Il est plus pratique d'utiliser une fonction macro, comme ceci: update: p> Le but de la macro est de résumer les détails et de faire une allocation de mémoire Moins d'erreur sujette. Avec une fonction (non-macro), nous devrions passer la taille de l'élément sous forme de paramètre car cette information est perdue lorsqu'un pointeur est transmis à un paramètre formel de type Void Pointer: P> NewArray(&myArray, n, sizeof myArray[0]);
Pourquoi macro code> pourquoi pas
inline code> fonction à la place?
@Truthseeker inline code> est pour une fonction i>.
New_array (PTR, N) CODE> N'AIT pas comme une fonction i>, plus comme
PTR = FOO (N, type de PTR) code>.
@ Chux-RestarStaTemonica: Oui, c'est vrai. Le point que je faisait est lorsque nous pouvons résoudre un rôle régulier pour que les macro. Après avoir lu Ce . J'essaie d'éviter les macro, partout où c'est possible.
@Truthseeker alors mieux d'indiquer votre point (votre souhait d'exprimer quelque chose) que de poser une question (sonne comme si vous voulez apprendre quelque chose)
Comme vous devez modifier le pointeur lui-même - le pointeur vers le pointeur est nécessaire
@Truthseeker Way extrêmement compliqué. gratuit code> sur le pointeur
(NOID **) & PTR CODE> - Accéder à
int * code> via
* (void **) code> est un comportement non défini.
Formal Arument FPTR et non l'argumen réel code> - Qu'est-ce qu'un "argument formel"? Qu'est-ce qu'un "argument réel"? Comment vont-ils différer? Vous demandez-vous comment attribuer une valeur à une variable de la portée extérieure à partir d'une fonction?
Yup, je demande comment attribuer un bloc de mémoire de Heap (quelle est la "valeur" que vous avez parlé) à l'argument réel,
APTR code> (variable de la portée extérieure).
Alors quelque chose comme Comment changer une variable dans une fonction d'appel d'une fonction appelée? ?
Attribuer un bloc de mémoire Code> - Un pointeur n'est pas un bloc de mémoire, il s'agit simplement d'une adresse à la mémoire.
Donc, tout ce que je dois faire est de remplacer
int * fptr code> avec
int ** fptr code> Pour recevoir
& APtr code> comme argument?
dynamalloc (int ** fptr) code> puis
* FPTR = MALLOC (COLS * TAILOFOF (** FPTR)); CODE> Sinon, vous attribuez le bloc attribué à un copier i> b> du pointeur local à la fonction de sorte que l'allocation n'est jamais vue dans
principale () code> (et essentiellement une fuite de mémoire). Appelez avec
dynamalloc (& pointeur) code> dans
principal () code>.
@Kamicuk @Davidthe multiple Dereferencing
* code> Les opérateurs ont rendu plus difficile que ce n'est en réalité, mais j'ai réalisé que le concept est toujours le même. Merci beaucoup de me montrer la voie!