Sources à compléter

Ici, les membres du forum pourront mettre les sources à compléter qui sont incorrects ou qui ne sont pas encore faits.

Je commence par le code source à compléter de l'exercice " la lettre la plus présente" du QCM de sélection de 2002

Edit O'Xian : Le code est maintenant lisible

1
2
3
4
5
6
7
#include <stdio.h>#include <stdlib.h>

int purger(){    int c;    while ((c = getchar()) != '\n' && c != EOF);}

size_t max(char* string){    /*votre source à compléter ici*/    return max;}

int main(void){    char *string = NULL;    int taille_chaine = 0;    size_t max_number = 0;    scanf("%d",&taille_chaine);    taille_chaine++;    string = malloc(taille_chaine * sizeof(char));    purger();    fgets(string,taille_chaine,stdin);    max_number = max(string);    printf("%ld",max_number);    free(string);  return 0;}

d'accord, et aussi, l'exo 2 du QCM 2002, les sources à compléter sont très dures à faire(de manière sécurisée)

je pense que mon but est plus de faire l'exo plutôt que de faire sa source à compléter.
Donc s'il serait possible d'éviter les entrées du type
12 13 574 6 0 1 3 7 9 4
je vous en serait très reconnaissant.

tes sources à compléter : déjà elles ne compilent pas sur le site de Prologin, ensuite, tu utilises des trucs compliqués qui servent à rien, tu passes en arg n, le nombre de caractères, alors que toutes les chaines de caractères s finissent par '\0'
A quoi cela sert?
Ensuite, tu n'as pas mis de free, c'est assez dangereux, le programme ne libère pas la mémoire allouée.

Franchement, je veux bien comprendre que vous êtes bénévoles, mais quand même, à faire des erreurs de ce type c'est un peu dommage.

thomas : as tu un e-mail pour que je puisse entrer en contact privé avec toi?

Merci de votre lecture.

Perso, je pense pas que le free soit si important... Le but, c'est pas de faire de la programmation pour un jeu, c'est de l'algorithmie, donc bon.

"

elles ne compilent pas sur le site de Prologin

" : j'ai testé en local chez moi et ça marche. J'imagine que Thomas a testé uniquement chez lui. Je me demande ce qui cloche sur le serveur.

"

tu utilises des trucs compliqués

" : le code source reste simple. Un calloc, un fgets et un scanf. Ca fait trop longtemps que je ne fais plus de C pour juger la qualité du code, mais tout reste simple.

"

tu passes en arg n, le nombre de caractères

" : oui, cela peut être une donnée utile. Surtout en C où il est impossible de connaître la taille d'une chaîne sans en faire le parcourt total.

"

tu n'as pas mis de free, c'est assez dangereux

" : quel danger ?

"

le programme ne libère pas la mémoire allouée

" : le système s'occupe de le faire. OK, c'est bien de prendre l'habitude de le faire dans le cas général ; mais le faire avant de quitter le programme a un intérêt limité.

"

je veux bien comprendre que vous êtes bénévoles

" : tu peux aussi remarquer qu'il a ajouté le code source rapidement après ta demande, que l'on a beaucoup de choses à faire en ce moment (les demi-finales...) et que modifier un sujet qui a 7 ans est loin d'être la priorité. Et que l'erreur est humaine.

Si tu veux, tu peux passer sur IRC, Thomas y est souvent.

Pour le problème de compilation, c'est effectivement ma modification qui l'a cassée. Nous investiguons...

Pour ce qui est des sources à compléter, elles peuvent être légèrement redondantes (passage de la longueur de la chaîne en C++ par exemple) mais c'est parce qu'elles sont générées avec un outil qui permet de gérer tous les langages à la fois. Il faut bien des compromis. (et puis excuse moi, mais c'est quand même plus joli que ton code :-)

Pour l'allocation mémoire, je plussoie LLB : désallouer avant que le programme ne ferme n'a pas grand intérêt.

Et oui, j'ai une adresse courriel, premier résultat quand tu cherches "thomas deniau" sur Google :-) (troisième sur exalead)

"oui, cela peut être une donnée utile. Surtout en C où il est impossible de connaître la taille d'une chaîne sans en faire le parcourt total."

Oui en effet, mais cela ne change pas grand chose au temps d'exécution surtout que il y a une fonction en C qui permet de calculer le nombre de caractères d'une chaine.

"et puis excuse moi, mais c'est quand même plus joli que ton code"

Peut être plus joli, mais on ne juge pas un code à sa beauté.

L'indentation n'est pas représentée sur le forum, donc cela n'est pas de ma faute, mon code est fonctionnel, plus ou moins sécurisé(c'est relatif), et pas forcément moche.

PS : je ne vois pas l'intérêt d'un calloc là où un malloc suffit.

Et en plus, quand l'utilisateur te dit 150 caractères, qui te dit qu'il va réellement en taper 150?
D'où le fait que transmettre n n'est pas très intéressant. Vaut mieux calculer soi-même la chaine.

C'est normal que maintenant que les sources à compléter pour cet exo sont disponibles, nos soumissions (et points) pour celui-ci ont été reset ?

Et est-ce aussi normal que mon code qui marche très bien en local ne compile pas sur prologin, et même que le compilateur ne renvoie aucune erreur ?

Pour programmer en général, les remarques peuvent être pertinentes...
MAIS ici, on n'a pas besoin de "sécuriser" l'entrée... les fichiers tests sont pas faits pour dire : "ah, tiens, il a pas vérifié si je lui balançais un nombre ou une lettre !". Donc le coup de l'utilisateur... on a pas de débat "scanf, ça pue, c'est pas sécurisé" ici.
En général aussi, le nombre de caractère d'une chaîne a son importance, ne serait-ce que pour ne pas la parcourir, comme ça a déjà été dit. Le calloc, à mon avis, est là au cas où on ait besoin d'avoir un tableau rempli à 0. Donc c'est pas nécessaire tout le temps, mais c'est pas génant.

"oui, cela peut être une donnée utile. Surtout en C où il est impossible de connaître la taille d'une chaîne sans en faire le parcourt total."

Oui en effet, mais cela ne change pas grand chose au temps d'exécution surtout que il y a une fonction en C qui permet de calculer le nombre de caractères d'une chaine.

Sachant qu'ici vous êtes évalués (entre autre) sur la rapidité d'exécution, il vaut mieux prendre en paramètre la longueur plutôt que de la calculer. Ca n'est pas forcément flagrant sur un seul appel, mais imagine un code récursif...

Comme l'a dit alexfun13, l'objectif n'est pas d'être secure , mais d'être efficace.

--
O'Xian
Prologin

Pardon, je les ai oublié :S

Je n'ai pas de réponse pour le moment ni pour l'une, ni pour l'autre. Je transmet aux personnes concernées.

Le compilateur ne te renvoit vraiment rien ? Même pas un message ?
Tu codes avec quel langage ? Quelle est la version (numéro + OS) de ton compilateur ?

--
O'Xian
Prologin

oxian : à propos du compilateur de Prologin, cela me fait aussi l'erreur, il ne dit que ça ne compile pas et basta.

Tous mes points ont étés réinitialisés.

"il vaut mieux prendre en paramètre la longueur plutôt que de la calculer."

On n'a pas besoin de calculer la longueur dans cet exo.

C'est un boucle
while(s[i] !='\0')

C'est tout aussi rapide voir même plus.

Avec ma technique, je fait d'une pierre 2 coups.

La fonction est indépendante des données de l'utilisateur, c'est plus sécurisé, et le code est moins compliqué(oui, mais il était pas très compliqué le votre aussi).

@jaloyan:
si tu veux ne pas utiliser le paramètre n c'est ton droit. On te le donne si tu le veux, ça ne mange pas de pain, inutile de remuer ciel et terre pour ça.

Pour le problème de compilation, oxian et les autres, ça merde depuis que j'ai rajouté les sources. Je ne comprends pas. C'est peut-être dû au changement du nom du problème... (en tout cas ça explique le pb de points). J'attends la réponse du webmestre.

Et pour strlen(), on ne bosse pas avec des chaînes Pascal, hein... strlen() doit parcourir toute la chaîne pour en connaître la longueur.

Bref, le 'n' est une info que l'on a et il serait dommage de la perdre, on peut avoir envie de t'en servir.

Quant aux testcases, ils correspondent à la description, donc si on dit qu'il y a 100 caractères, il y en a 100 pas 150 :-)

Bonne nuit !

Répondre au sujet

Vous devez vous enregistrer ou vous connecter pour poster des messages.