Comment ajoutez-vous un élément à une liste code> dans scala 2.7.5, sans créer de nouvelle liste
code> et sans utiliser de solution obsolète. P>
6 Réponses :
La méthode L'avertissement de dépréciation est donc un indice subtil que vous devez redéfinir votre programme pour travailler en prépendeur. Au lieu d'ajouter: p> (Notez que + = code> sur une liste est obsolète car elle ajoute un élément à la queue, ce qui est coûteux. Le moyen le moins coûteux d'ajouter un élément à une liste consiste à ajouter à la tête à l'aide de
:: = code>.
:: = code> et
+ = code> sur un
var code> ne sont pas des méthodes réelles, mais le sucre pour
l = l :: elem code>, etc.) p> p>
Mais est l code> toujours la même liste? De plus, vous êtes en train de préparer, pas à l'annexe.
Eh bien, vous n'avez pas répondu à la question :)
Souvent, la vraie solution au problème sous-jacent n'est pas une réponse directe à la question initiale.
@Leppie Les questions posent comment on ajoute un élément. Le titre de la question mentionne l'annexe. Il a donc répondu à la question, mais pas le titre. :-)
@Daniel: Non, il a demandé comment le faire sans créer une nouvelle liste.
Leppie, si vous êtes au courant de la manière dont le sucre syntaxique de Scala permet des opérations de style apparemment mutables sur des objets immuables variables, il est logique d'interpréter cette partie de la question comme «sans explicitement i> créer une nouvelle liste ". Et au cas où il / elle n'était pas au courant de cela, je l'ai mentionné aussi.
Il convient de souligner que la liste La liste La méthode Je suppose qu'une manière différente serait de préparer avec 2 inversions: p> Je doute que c'est Plus efficace! En général, si je veux appendez em> comportement, j'utilise prépendez em>, puis code> a une signification très spécifique dans Scala, qui n'est pas équivalente à l'interface
java.util.list code>.
Liste CODE> est une classe abstraite scellée, représentant une structure de données reconsive em> qui a une tête em> et a queue em>. (Il existe des structures de liste de liste Java à Scala, dont certaines sont mutables.)
Scala's code> s sont
java.util.linkedlist code> p>
+ code> a été obsolète pour une bonne raison car elle est inefficace; Utilisez plutôt: p>
inverse code> (au point d'avoir besoin d'accéder à la liste): p>
C'est une argumentation, pourquoi la question pourrait être une mauvaise. Mais cela ne répond pas à la question.
Cela répond exactement à la question. Le questionneur a demandé comment ajouter à une liste sans créer une nouvelle liste. C'est impossible! Peut-être devriez-vous développer pourquoi vous avez bownvothed ma réponse (correcte)
Jens, pour appliquer votre propre raisonnement, vous n'avez pas répondu à la question que cela vous demande comment appendez-le à une liste code> code>, pas un linkedlist code> ou
listbuffer code >, dont aucun des deux résultat de la liste
code>. (Pourtant, votre réponse est toujours utile.)
J'aime annoncer la liste existante à une nouvelle liste d'une approche de l'article!
Cela devrait le faire: http: // www.scala-lang.org/docu/files/API/scala/collection/mutable/singlelinkedlist.html#append%28Ce%29 P>
ou ceci: HTTP : //www.scala-lang.org/docu/files/API/scala/collection/Mutable/listbuffer.html#%2B%3A%28A%29 P>
Le truc de base consiste à utiliser une liste mutable (ou une classe avec fonctionnalité similiaire) p>
c'est possible, mais va contre l'esprit de Scala
Vous pouvez utiliser un listbuffer code>, qui fournit une heure constante ajoute:
voie non obsolète d'ajouter un élément à une liste dans Scala 2.7.5? P>
Cela n'existe pas, et il n'existera jamais. P>
Comment ajoutez-vous un élément à une liste dans Scala 2.7.5, sans créer de nouveau Liste et sans utiliser de dépréciation Solution. P> blockQuote>
utiliser
:: code>: p>
xxx pré> ou, si
list code> est un
var code>, p>
xxx pré> Il ne crée pas de nouvelle liste
code> (cependant, il crée un nouveau
:: code> , également appelé contre em>), et il ajoute un élément à celui-ci. p>
Si vous souhaitez ajouter des éléments à une séquence sans créer de nouvelle séquence, utilisez une structure de données mutable. p> blockQuote>
Ceci réellement achète code> un élément à une liste, qui est différent d'un fonctionnement code> append code>.
@OPENSAS LISTE CODE> est immuable, vous ne pouvez donc pas le changer. Vous devez affecter une nouvelle liste à la variable, ce qui nécessite d'utiliser une mission.
Oups, je pensais que si la liste était un var, ce n'était plus immuable
Ce qui suit n'est pas vrai pour la mise en œuvre de la liste des opérations. Merci à Sschaef pour la correction. P>
Un point très important que je n'ai pas vu mentionné ici est que la création d'une nouvelle collection d'une autre collection n'est pas nécessairement aussi coûteuse à Scala que dans Java. Ce concept s'appelle la persistance. Daniel Spiewak le prévoit dans son article, http://www.codecommit.com/blog/scala/scala-collections-for-the-astillement-bored-Part-1 . P>
Voici un extrait de la section correspondante, P>
Bien sûr, la question naturelle qui vient à l'esprit est, qu'en est-il de la performance? Si chaque invocation crée en fait un nouvel ensemble pour chaque appel récursif, cela ne nécessite que beaucoup de copie d'objet inefficace et d'opérations de tas? Eh bien, comme il s'avère, ce n'est pas vraiment le cas. Oui, une nouvelle instance doit être créée à chaque tour, ce qui est une opération relativement coûteuse sur la JVM, mais presque rien n'est copié. Toutes les structures de données immuables de SCALA ont une propriété appelée persistance, ce qui signifie que vous ne copiez pas les données de l'ancien conteneur lors de la création d'une nouvelle référence, vous venez d'avoir la nouvelle référence à l'ancienne et de traiter tout son contenu comme s'il s'agissait étaient ses propres. p> blockQuote>
Donc, alors qu'il sera moins coûteux d'utiliser une liste mutable, il n'est pas autant de préoccupation que c'est sous Java. P>
Ceci n'est vrai que pour les structures de données immuables dont le contenu peut être partagé en raison de ses références existantes. Ce n'est pas le cas lorsque vous souhaitez ajouter un élément à la liste Scalas, car il s'agit d'une liste unique liée et aucune référence au dernier élément n'existe. Cela signifie que chaque élément doit être copié afin d'annoncer un élément qui est O (n). En revanche, un élément est O (1) parce que le nouvel élément peut pointer vers l'ancienne liste sans rien copier (c'est ce que votre devis décrit).
@sschaf, ah merci de me corriger, je suis nouveau à Scala et je tiens à tout comprendre.
Pour votre édition: il est vrai pour la liste, mais pas pour toutes les opérations. La même chose avec d'autres structures de données ...
La mutation est mauvaise, mmkay :)
Peut-être devriez-vous clarifier si par "sans créer une nouvelle liste
code>" Vous voulez dire ne pas dupliquer toute la liste en mémoire ou que toutes les références à la liste reflètent le changement. Ce dernier n'est pas possible, comme la liste
code>, à Scala, est immuable.