Algorithmes, méthodes de résolution, comparaison de leurs performances - page 8
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
Je voudrais souligner que, contrairement à tout le monde ici, Peter a probablement la plus grande patience - et la volonté d'écrire un code monotone. Je ne peux pas expliquer autrement comment il a réussi à écrire autant de choses.
Cette tendance au code monotone est-elle un style "indien" ?
Ou qu'est-ce que vous entendez par là ?
)
J'ai juste une question, pourquoi ne pas utiliser un tableau d'int ou mieux encore, utiliser un listing si vous avez assez de ces assistants ?
Pourquoi utiliser une chaîne de caractères pour faire cela ? pour que vous puissiez aussi entrer des lettres ? ou vous pouvez aussi compter dans le système 16 bits ! ou encore plus cool, passer directement à 128 bits...
Le penchant pour le code monotone est-il un style "indien" ?
Ou qu'est-ce que tu voulais dire par là ?
)
Bingo ! !! Je ne voulais pas le dire moi-même.
La tendance au code monotone est-elle un style "indien" ?
Ou qu'est-ce que tu voulais dire par là ?
)
Le style russe, avec son besoin incessant de tout réécrire, n'est pas non plus très agréable, surtout dans les grands projets.
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 que int alloue de la mémoire pour 10% de plus que string alloue de la mémoire pour 1 caractère, si vous comparez plus de caractères alors je suppose que int gagne.
Il serait intéressant de vérifier votre affirmation dans la pratique. Si le redimensionnement constant d'un tableau d' int avec réécriture des données dans les deux sens est aussi rapide que de travailler avec une chaîne, je préférerais certainement int.
Mais je doute fort que la vitesse soit la même. Intuition.
Il serait intéressant de vérifier votre affirmation dans la pratique. Si le redimensionnement constant d'un tableau d'int avec réécriture des données dans les deux sens est aussi rapide que de travailler avec une chaîne, je préférerai certainement int.
vérifiez - le code ici est simple.... Je conseille également de boucler le code 100 000 fois, ainsi il sera plus clair et moins dépendant de facteurs extérieurs.
Je pensais que ce sujet était initialement destiné à de telles comparaisons.
Je voudrais souligner que, contrairement à tout le monde ici, Peter a probablement la plus grande patience - et la volonté d'écrire un code monotone. Sinon, je ne peux pas expliquer comment il a réussi à écrire autant.
Bingo ! !! Je ne voulais pas le dire moi-même.
Encore une fois,fxsaber a raison- l'invisibilité des messages et des sujets des personnages de sa "liste noire" pour chaque utilisateur de ce forum est déjà une nécessité. pour maintenir une société saine. Et l'individu...
Sinon, ce fil n'est pas perçu comme une moquerie de la profession.
(
C'est une déclaration audacieuse, pouvez-vous l'étayer avec quelque chose ?
OK, Peter développe des GUIs - en écrivant des GUIs, la POO nous aide à simplifier et simplifier le code plus que n'importe où ailleurs. Cependant, nous écrivons sans elle - et ici nous ne pouvons pas appeler cette méthode rapidement, mais la persistance prend le dessus et nous voyons une certaine GUI) ..... Bien sûr, je ne compare pas ces personnes qui ont 30 lignes OOP difficiles chacune avec des macros de classes défuntes comme #define micrcalss(CALSS, PARENTS) class CLASS : public PARENTS ......