Somme d'entiers - Page 2

c'est gorêt

bof, j'ai déjà la réputation, alors autant être à la hauteur

en C ça ralentit pas (si c'est bien utilisé)
en BASIC, je sais pas.

Mais si envoie un source plein de goto et de labels à quelqu'un pr lui demander de rouver la raison d'une erreur, ça va être cho...
Dans ce cas là, qd on m'envoie cetype de source (c'est arrivé une seule fois), j'ai trois possibilités :
1: Je tente de réécrire tout le programme s'il est court et que je le comprend
2: je répond au mail en lui disant que je réussis pas à comprendre, et en disant qu'il fo pas faire ça
3: je cherche pas longtemps à comprendre, et je répond même pas tellement ce style de prog me gave
(c'est arrivé qu'une seule fois... j'ai pris la première option ou la deuxième, je sais plus)

En basic c'est très classique, et je ne pense pas que ça fasse ralentir bcp...
En fait je ne me suis jamais posé la question, et j'ai jamais essayé de programmer avec des while, loop, etc pour éviter les lbl.

Mais bon un prog en C j'en sais rien un prog en basic ça se déchiffre facilement (j'en connait un qui va venir trouver une exeption...)

mais je ne comprends pas pourquoi vous trouvez ç plus difficile de lire un prog avec des 'goto'.
Moi je trouve ça plus facile...
Enfin, c'est vrai que si le gars remplace les for, while,etc... par des trucs équivalents avec des goto ça sera plus chiant, mais sinon, si au lieu d'appeler une fonction, il utilise un goto dans la même fonction, moi je trouve aussi simple à comprendre
[edit]Edité par jackiechan91 le 06-03-2002 à 19:42:31[/edit]

Moi aussi, mais enfin ça dépend de comment ils sont foutus aussi

eh ben... plus simple ?
ma foi... chacun pense ce qu'il veut...

je trouve franchement qu'utiliser un goto plutôt que d'appeler une fonction est plus lisible.

ben ma fois, libre à toi...
mais bon........

l'habitude du basic...
un programme en basic dont chaque partie distincte est précédée de son lbl, et séparée par un saut de ligne de la suivante et de la précedente, c'est très clair

arf............
j'imagine 4000 lignes (Krypton doit faire ça, peut-être un peu plus ou moins, je sais pas) de code C sans fonctions, que avec des lbl...
et j'imagine, en plus de ça, le code de KryptonII sans fonctions, que avec des lbl (et avec de l'ASMin-line qui rallonge le code à mort)... là, j'en rigole carrément à la pensée de la crise de nerfs pr le débuggage.

il fait cb en taille, non compilé ?

parceque à vue de nez je pense que j'ai déjà fait des progs plus lourds bourrés de lbl, et pourtant il m'a bien fallu les débugger...

Merci pour vos réponses, je crois qu'il faudra creuser en direction d'un backtracking.

J'y réfléchis...

Bob> qu'est-ce que tu entend par taille ?
si t parle de taille mémoire non compressé, ça fait dans les 50ko + 2 fois 40 ko pr les graphismes jenpenses
(pour Krypton)

(pour KryptonII, je sais pas du tout : pas assez avancé... et tous les trucs externe seront géré autrement, pr que le prog ait besoin de moins de RAM libre)

Voilà backtracking c ce que je cherchait...
ça doit être adaptable

C'est bon, j'ai trouvé :

avec values = tableau d'entiers
select = l'élement est-il sélectionné ?
length = nombre d'entiers
goal = somme à atteindre
index = index actuel
sum = somme actuelle
appeller trySum (#, #, #, #, 0, 0);

int trySum (int * values, int * select, int length, int goal, int index, int sum) {
if (sum == goal)
return -1;
if (index == length)
return 0;
if (sum > goal)
return 0;
select[index] = 1;
if (trySum (values, select, length, goal, index + 1, sum + values[index]))
return -1;
else {
select[index] = 0;
if (trySum (values, select, length, goal, index + 1, sum))
return -1;
else
return 0;
}
}