Algorithmes, méthodes de résolution, comparaison de leurs performances - page 7

 
Alexandr Andreev:

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.

 
Реter Konow:

Vous pouvez commencer à écrire la deuxième ligne. Puis le troisième et ainsi de suite... :)

Je comprends maintenant pourquoi la création de votre "constructeur" est si longue.
 
Vasiliy Sokolov:


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.

 
Реter Konow:

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 vitesse
 
Vasiliy Sokolov:
p.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 ?
Il "réfléchira" un peu plus et résoudra ce problème : mettez un trait de soulignement avant la transaction, et un autre symbole avant le magicien :)
 
Alexandr Andreev:

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.

 
Yury Kulikov:
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.

 
Реter Konow:

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.