12
votes

Utilisation de nouveau vs var in va

Vous avez une fonction avec un argument, un pointeur à un type.

b := new(bar)
foo(b)


1 commentaires

Ne le pense pas. Cette question pose spécifiquement des questions sur le résultat de et variable vs nouveau (type) lorsqu'il est passé à un type de pointeur prise de fonction. 10990174 ne demande pas et ne répond pas à cela.


3 Réponses :


5
votes

Les deux doivent représenter le même pointeur sur le même objet initialisé avec la même valeur par défaut.

le spec mentionne:

après xxx

Les détentements suivants: xxx

La même chose serait aussi vraie après xxx

aussi:

Prendre l'adresse d'un littéral composite (§ Les opérateurs d'adresse ) génère un pointeur à un instance unique de la valeur de la littérale. xxx


0 commentaires

13
votes

Non, il n'y a pas de différence, comme, contrairement à C, allez explicitement indiqué que vous pouvez donner un pointeur à une variable créée localement.

de La documentation :

Notez que, contrairement à C, il est parfaitement correct de retourner l'adresse d'un variable locale; Le stockage associé à la variable survit Après la fonction renvoie


0 commentaires

-4
votes

Il y a une différence dans certaines situations. nouveau (t) , comme le nom l'indique, renvoie une nouvelle instance de type T, tandis que var b t est une seule instance, une fois pour toujours (ERR, En fait jusqu'à la fin de sa durée de vie == sortir de la portée, pas accessible ...).

considère cette boucle xxx

vs xxx

Dans l'affaire ultérieure, si foo par exemple stocke son arg dans un conteneur, entraîne 10 instances de bar existant tandis que le premier cas avec une seule variable B .

Une autre différence est dans la performance. La variable B serait une variable globale entièrement statique ou si vous êtes généralement assis à un décalage connu statilement dans un enregistrement d'invocation de fonction / méthode (nom de fantaisie pour généralement un cadre de pile). Nouveau OTOH, s'il n'est pas optimisé par le compilateur, est un appel d'allocator mémoire. Un tel appel coûtera un peu de temps non nul. Si cela est fait dans une boucle et non nécessaire, il peut alors faire un ralentissement notable de certains sentiers de code.


18 commentaires

La seule différence est que nouveau () renvoie un pointeur à une variable lorsque Var vous permet de déclarer une variable. Cette réponse aurait un sens si aller reconnaître la différence entre la pile et le tas dans la langue. Voir la réponse de Dystroy ci-dessous et ma propre réponse à une autre question Stackoverflow.com/a/10990287/727643


@Stephenweinberg: Je suis à ma réponse. (Bien sûr après que je le vérifie maintenant). Veuillez spécifier les défauts perçus WRT les spécifications. En outre, dites-moi quelle alternative (raisonnable) alternative à la répartition de la mémoire est destinée à la mise en œuvre de neuf . Aussi, s'il vous plaît laissez-moi savoir quel (s) compilateur (s) Go existant utilise cette alternative. Merci d'avance. Je réalise que les spécifications ne parlent pas de pile ou de tas. Cela n'exclut pas de parler de la manière dont la mise en œuvre fonctionne, surtout si elle aide à comprendre. Voir aussi: recherche.swtch.com/godata


@Jeremywall: Il est difficile de dire avec toutes les informations spécifiques fournies. S'il vous plaît laissez-moi savoir ce qui devrait être changé. Je serais ravi de faire la réponse (plus) correcte.


@jnml: Une autre façon d'implémenter de nouvelles personnes est la même chose que l'OP a fait. var b bar; PTRB: = & B . Les deux manières qu'il a énumérées sont identiques selon les spécifications. Vous êtes autorisé à parler de la mise en œuvre si vous le mentionnez, c'est la mise en œuvre dépendante. Cependant, vous avez tort de la mise en œuvre. GC et GCCGO les alloueront à la fois au tas dans les deux cas. Dans les deux cas, l'analyse d'évasion les oblige à mettre la variable sur le tas.


Pendant que vous aviez raison de la différence entre vos deux exemples de bouclage, ils ont manqué le point de la question. Si vous mettez la barre var b à l'intérieur de la boucle dans le premier exemple, il ferait exactement la même chose que le deuxième exemple. C'est ce que l'OP a demandé en premier lieu.


@StephenweInberg: Vous utilisez des arguments, je n'ai pas dit: "Cependant, vous avez tort de la mise en œuvre. GC et GCCGO les alloueront au tas dans les deux cas." t Dis quelque chose contraire à cela - veuillez vérifier par vous-même. J'ai dit qu'il y aurait 1 instance ("dans la variable b") vs dix instances ("dix instances existantes"). Cela ne dit rien si 'B' est sur la pile ou sur le tas. Vous m'avez perdu où vous prétendez savoir mieux que l'op de quoi il demandait. PS: Je vais prétendre la partie sur ce que je suis autorisé à parler et sous quelles conditions ne sont-elles pas arrivées, d'accord?


Vous êtes confus. Nouveau (t) et & T {} sont la même chose. La seule raison nouvelle (t) existe est que la dernière forme ne peut pas être utilisée avec des types primitifs (par exemple. int). Les deux extraits de code sont différents, mais c'est parce que, dans le premier, vous allouez en dehors de la boucle et dans la seconde, vous allouez à l'intérieur de la boucle. C'est un code différent, vous n'avez pas répondu à quoi l'OP a demandé, à la place, vous avez posté une réponse malformée et déroutante.


@ Aramhăvărneanu: Les confusions réside dans le fait que les littéraux composites, ni dans la forme et la forme {}, ont été posés / discutés / mentionnés / ont répondu dans cette question par quiconque devant vous ;-)


Ces programmes ont la même signification (et avec la mise en œuvre de GC actuelle même la même sortie): play.golang.org / p / gopm50ibxj et play.golang.org/p/ciknn3jpxv . S'il vous plaît ne confondez pas et n'entraînez pas les débutants en répondant aux questions qu'ils n'ont pas demandé.


@ Aramhăvărneanu: Ce n'est pas moi qui répond à la non-posé & t {} Stuff ;-) Avant votre commentaire, il a été présenté nulle part ici. L'OP n'a pas demandé à ce sujet, personne n'a répondu à ce sujet et personne ne l'a mentionné et personne ne discutait de prendre en compte d'un littéral composite. Prise d'adresse d'une variable est une chose différente de Than & t {}.


Y a-t-il une raison pour laquelle vous avez gardé est une seule instance, une fois pour toujours (ERR, effectivement jusqu'à la fin de sa vie == sortir de la portée, pas accessible ...). Dans? Il semble que vous ayez remarqué ce que vous avez écrit n'était pas tout à fait correct et mettez de plus amples informations en parenthèses. IMHO c'est déroutant maintenant. Ça vous dérange de prendre ce peu d'informations? Je finirais que cette phrase droite après est une seule instance .


@Kissaki: Le texte entre parenthèses est un rappel sur la durée de vie limitée de certaines choses (en déplacement). Peut-être que la formulation est mauvaise stylistiquement, mais c'est mon style (détendu) et il n'y a rien de fait factuellement incorrect dans la teneur en fabrication-it-plus précise du texte parenthèse. En fait, lorsque j'apprends quelque chose, je préfère voir d'abord l'aperçu / concept plus large avec des spécificités / exceptions / exceptions détaillées / des limitations / ... Suite que plus tard / après cela. Parce que dans l'ordre inverse, il est trop facile de manquer la forêt à cause des arbres ;-)


Lire à nouveau la phrase, les différences qu'il souligne ne sont pas là. Oui Nouveau retourne une nouvelle instance de type T, mais il tente de comparer la fonctionnalité du nouvel opérateur avec un type de variable. - Eh bien, je repauverais tout le premier paragraphe, mais gardez-le si vous devez le faire.


@Kissaki: Tout ce thread est vraiment intéressant. Il me semble que, pour une raison quelconque inconnue, l'ouverture, le réglage de la portée "Il existe une différence dans certaines situations." (suivi de la représentation de deux exemples de ce type) est probablement invisible envers les autres ;-) (cité ci-dessus inclut la faute de frappe comme initialement faite - l'extra 'A' avant le mot «Différences»)


JNML, Go détermine s'il faut mettre des données sur le tas en effectuant une analyse d'évasion. Cela n'a rien à voir avec l'utilisation de nouveaux ou non. Si un pointeur échappe à la fonction, allez mettre ces données sur le tas. Il y a zéro différence entre l'utilisation de nouveaux (t) et & t {}.


@Jeremywall: Lisez peut-être la réponse plus attentivement? Encore une fois, cela se dispute par ce qui n'est pas dans le (prétendument faux à cause de cela). En fait j'ai dit "nouvel otoh, s'il n'est pas optimisé par le compilateur , est un appel de mémoire d'allocator." 1) vrai à la fois dans GC et GCCGO 2) Tout conflit avec "Go décide de mettre des données sur le tas en effectuant une analyse d'évasion" . (Oui, Analyse d'évasion (mai, où réalisable) fournit des informations à la fois pour quand une entité doit aller sur le tas comme lorsqu'une entité n'a pas besoin pour être introduite par neuf .) ... à suivre ...


... aussi Vous êtes _ complètement mal à propos de _ "Il y a Différence zéro entre neuf (t) et & t {}.", Comme pour type T int Il a une différence non nulle à ce que le compilateur le rejette. Le sujet & T {} n'a jamais été mentionné / considéré par quiconque avant d'aramer, de sorte que sa discussion n'est absolument pas pertinente pour la correction de cette réponse. Ce que je supporte toujours parce que chaque accusation de son incorrectement a été montrée jusqu'à présent comme mal, de sorte que ce dernier de votre part. Aucune infraction prévue, nous ne faisons que chercher la vérité, n'est-ce pas? ;-)


Var B T est également un appel d'allocation de mémoire. La seule différence entre le nouveau (B) et le VAR B T est que l'un est un type de pointeur tandis que l'autre n'est pas. Dans le contexte de ce que l'utilisateur demande cette différence est immatériel. Pour la phraser différemment nouveau (t) et var b t; & B sont équivalents à tous égards qui comptent, y compris la manière dont la mémoire est allouée. Vous ne répondez jamais à l'affaire de type primitive qui, lorsque vous identifiez avec précision, c'est la seule différence entre les nouveaux et les opérateurs. Votre réponse se lit sous telle manière d'être trompeuse comme illustré par la longueur de ce fil de commentaire.