Algorithmes, méthodes de résolution, comparaison de leurs performances - page 7
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
En résumé, une chaîne de caractères est uncaractère dont le code est compris entre 0 et 255 et qui pèse 1 octet... et qu'on lui a alloué juste assez de mémoire pour contenir 256 valeurs, 257 ne tiendra pas là, il reviendra à la première.
Dans toute page, chaque caractère est un nombre de 0 à 255... donc on prend le nombre 10000000 - il pèse 4 octets, on le convertit en chaîne de caractères "10000000" puis pour chaque caractère on alloue de la mémoire comme pour une carte individuelle de 0 à 255... 8 octets au total. Il n'y a pas d'économie de mémoire nulle part.
Je vois ce que vous voulez dire.
Nous devons calculer avec précision la quantité de mémoire consommée dans cette solution.
Vous pouvez commencer à écrire la deuxième ligne. Puis le troisième et ainsi de suite... :)
p.s. Oh oui, vous avez encore une erreur. Si MathRand, au troisième appel, renvoie par exemple le nombre 1000 et écrit _3_1000_, quel type de medge sera trouvé pour une transaction avec le numéro d'ordre 1000 ?Le fait est que MathRand n'est nécessaire que pour simuler les nombres medigee.
Les nombres Medjic sont fixés par l'utilisateur, et il peut contourner une valeur inférieure à 100 000 (disons).
Cependant, il peut y avoir une erreur dans l'exemple donné. Vous avez raison.
Merci pour l'observation. Une solution complète devrait en tenir compte.
Je comprends votre point de vue.
Nous devons calculer avec précision la quantité de mémoire consommée dans cette solution.
Cela gaspille également beaucoup de ressources sur les références internes, car l'accès à chaque caractère de la chaîne est identique à l'accès au tableau char[x]. Dans ce cas, un lien est un accès à un certain élément du tableau. Et tu vas juste passer par des piles énormes d'entre eux là. L'implémentation avec int serait beaucoup plus facile et rapide à comprendre...
Quant à la limitation de la longueur de la chaîne de caractères, elle dépend généralement de la taille maximale du tableau char[x] - celui-ci a également sa propre limite maximale.
Cet homme ne se rend vraiment pas compte de l'étendue de sa propre stupidité.
L'effet Dunning-Kruger en action.
C'est bon, une personne a juste besoin d'un langage non typé et pas de problèmes)).
bien qu'il y ait toujours une différence de vitessep.s. Oh oui, vous avez encore une erreur. Si MathRand au troisième appel retourne par exemple le nombre 1000 et écrit _3_1000_, quelle magie sera trouvée pour traiter le nombre ordinal 1000 ?
Cela gaspille également beaucoup de ressources sur les références internes, car accéder à chaque caractère de la chaîne revient à accéder à char[x] d'un tableau. Dans ce cas, un lien est un accès à un certain élément du tableau. Et tu vas juste passer par des piles énormes d'entre eux là. L'implémentation avec int serait beaucoup plus facile et rapide à comprendre...
Quant à la limitation de la longueur des chaînes de caractères, elle dépend généralement de la limite de taille maximale du tableau char[x] - il a sa propre limite maximale, ainsi que d'autres.
Nous ne pouvons pas l'implémenter avec int, car nous ne connaissons pas à l'avance le nombre de transactions futures. Nous devons soit deviner, soit modifier la taille du tableau à chaque transaction et réécrire les données dans les deux sens.
Comment faire autrement ?
La vitesse de ma solution est insensée.
La mémoire est consommée, mais on ignore à quel point elle est inefficace. Nous devons en être sûrs.
Il va "réfléchir" un peu plus et résoudre ce problème : il mettra un trait de soulignement devant la transaction, et un symbole différent devant le magicien :)
Je voudrais souligner que, contrairement à tout le monde ici, Peter a probablement la plus grande patience - et la volonté d'écrire un code monotone. Il n'y a pas d'autre façon d'expliquer comment il a réussi à écrire autant.
Nous ne pouvons pas implémenter avec int, car nous ne connaissons pas à l'avance le nombre de transactions futures. Soit nous devons deviner, soit nous devons modifier la taille du tableau et réécrire les données dans les deux sens à chaque transaction.
Comment faire autrement ?
La vitesse de ma solution est insensée.
La mémoire est consommée, mais on ignore à quel point elle est inefficace. Nous devons en être sûrs.
Il n'y a que deux variantes de chaîne de caractères : soit elle a une taille maximale (en réserve), soit la mémoire est allouée et dans votre cas, pendant le processus d'ajout, elle est allouée à chaque fois..... C'est donc la même chose que de changer la taille d'un tableau d' int. 1in1 eh bien peut-être qu'il faut 10% plus de temps à int pour allouer de la mémoire qu'à string pour allouer de la mémoire pour 1 caractère, si vous comparez plus de caractères alors je suppose que int gagne.