/* Topic des codeurs [8] */

Pylades · Le 14/03/2013, à 01:11

Elzen a écrit :

Là comme ça, et sans trop regarder dans le détail, le double %d sans rien entre les deux dans le premier scanf me semble bizarre ; il faudrait un séparateur, je pense, sinon, ça va être difficile de savoir où s'arrête le premier et où commence le deuxième…

Non, c’est une syntaxe tout à fait valable. Après, never trust user input, mais là n’est pas la question.

(Et l’erreur se voit comme le nez au milieu de la figure. )
(D’ailleurs ce code ne compile même pas, de plus.)
(Outre le fait qu’il soit non-standard.)

Dernière modification par Πυλάδης (Le 14/03/2013, à 01:15)

The Uploader · Le 14/03/2013, à 02:47

point virgule en trop à moins que je rêve

		while (b != 0);

Sinon je trouve l'absence de void dans int main() plus grave que ce genre d'erreur idiote.

(pas essayé la compil')

Dernière modification par The Uploader (Le 14/03/2013, à 02:48)

maxpoulin64 · Le 14/03/2013, à 03:27

Ouais c'est le point virgule le problème principal (mis à part quelques autres trucs pas trop super non plus, je sais).

Je pensais vous offrir un petit divertissement avec une erreur toute conne, parce que j'ai du y mettre une bonne heure ou deux, j'ai littéralement éclaté de rire quand j'ai vu le point-virgule de trop. J'essayais de voir ce qui foirait avec l'algorithme et tout, aucun problème par là... Ouaip, un point-virgule.

Par contre chez moi le code compile bien, mais y'a peut-être 2-3 caractères invisibles par ci par la vu que c'est copié d'un document en .doc.

... bon ok je sais où est la sortie ===> []

grim7reaper · Le 14/03/2013, à 05:04

maxpoulin64 a écrit :

des erreurs stupides et pointues que personne ne fait de toute façon.

Erreur stupide, oui.
Pointues, non pas du tout. Erreur très simple même, ça ne demande pas des connaissances poussées en C pour trouver et comprendre.
Que personne ne fait, là aussi je ne suis pas d’accord. C’est une erreur assez courante chez les débutants.

Dans le genre erreur un peu plus poussée, je pense pas que j’irais jusqu’à la qualifier de pointue mais je ne suis pas super objectif je pense, on pourrait citer celle là :

#include <stdio.h>

int main(void)
{
    char toto[] = "salade";
    *toto = 'm';
    puts(toto);
    return 0;
}

Ce code fonctionne.

#include <stdio.h>

int main(void)
{
    char* toto = "salade";
    *toto = 'm';
    puts(toto);
    return 0;
}

Ce code plante (du moins avec gcc et clang). Pourquoi ?
D’ailleurs à noter que gcc et clang, mode normal ne signale rien. En revanche gcc en mode maniaque émet un warning, clang toujours rien.

Dernière modification par grim7reaper (Le 14/03/2013, à 05:24)

maxpoulin64 · Le 14/03/2013, à 07:21

Le premier exemple crée automatiquement le tableau requis pour contenir la chaine, alors que le 2e me semble créer un pointeur et lui affecter comme valuer le contenu de la chaine, donc un pointeur qui ne fait pas vraiment de sens? Le C est un peu loin pour moi

En fait, j'ai peut-être jugé l'exemple que j'ai donné un peu trop vite. Pour donner un peu de contexte, l'exam de 12 pages (papier+crayon, noir et blanc) n'est constitué que de colles du genre. Je peux comprendre que ça peut être utile de montrer la plupart des pièges, mais un examen au complet (qui compte pour près de la moitié de la note finale de ce cours universitaire) bourré de pièges comme ça, ça me donne quand-même l'impression que c'est de l'abus. J'ai peut-être tort, ça me donne la forte impression qu'on ne montre que la syntaxe, alors que ce cours est supposé être une introduction à la programmation C. Et puis, on a beau connaître la plupart des pièges, perso ça m'a jamais empêché de les faire. Après que je les ait faites, là j'ai arrêté de les faire.

En plus le texte de la question envoi direct dans la mauvaise piste

Mais bon, je vais faire plus attention avant de poster un problème et le juger ainsi. J'ai tellement mis de temps à le voir que j'ai peut-être très légèrement abusé ma réaction avant de poster le problème.

grim7reaper · Le 14/03/2013, à 08:16

maxpoulin64 a écrit :

Le premier exemple crée automatiquement le tableau requis pour contenir la chaine, alors que le 2e me semble créer un pointeur et lui affecter comme valuer le contenu de la chaine, donc un pointeur qui ne fait pas vraiment de sens?

Non, le second créé un pointeur qui pointe sur la chaîne (le pointeur contient l’adresse de la chaîne) donc il a du sens.

maxpoulin64 a écrit :

En fait, j'ai peut-être jugé l'exemple que j'ai donné un peu trop vite. Pour donner un peu de contexte, l'exam de 12 pages (papier+crayon, noir et blanc) n'est constitué que de colles du genre. Je peux comprendre que ça peut être utile de montrer la plupart des pièges, mais un examen au complet (qui compte pour près de la moitié de la note finale de ce cours universitaire) bourré de pièges comme ça, ça me donne quand-même l'impression que c'est de l'abus. J'ai peut-être tort, ça me donne la forte impression qu'on ne montre que la syntaxe, alors que ce cours est supposé être une introduction à la programmation C. Et puis, on a beau connaître la plupart des pièges, perso ça m'a jamais empêché de les faire. Après que je les ait faites, là j'ai arrêté de les faire.

Oui, j’ai déjà eu des examens comme ça, constitué de « trouve l’erreur », et oui c’est chiant et je vois pas franchement l’utilité.
Comme tu le dis, il faut le faire pour l’apprendre, le voir ne suffit généralement pas.
Sans compter que le papier n’offre pas de coloration syntaxique ce qui est d‘autant plus chiant.

maxpoulin64 a écrit :

Mais bon, je vais faire plus attention avant de poster un problème et le juger ainsi. J'ai tellement mis de temps à le voir que j'ai peut-être très légèrement abusé ma réaction avant de poster le problème.

Y’a pas de mal. Ce n‘était pas un reproche hein, je donnais juste mon point de vue

:!pakman · Le 14/03/2013, à 08:34

grim7reaper a écrit :

#include <stdio.h>

int main(void)
{
    char* toto = "salade";
    *toto = 'm';
    puts(toto);
    return 0;
}
Ce code plante (du moins avec gcc et clang). Pourquoi ?
D’ailleurs à noter que gcc et clang, mode normal ne signale rien. En revanche gcc en mode maniaque émet un warning, clang toujours rien.

A l'arrache : je crois qu'il faut déclarer le tableau en const, si on crée une chaîne de cette manière, non ? Je crois me souvenir d'un problème à la con dans le genre

const char* toto = "salade";

C'est bon ? Y'a toujours un warning ?

Dernière modification par :!pakman (Le 14/03/2013, à 08:40)

grim7reaper · Le 14/03/2013, à 08:56

:!pakman a écrit :

grim7reaper a écrit :
#include <stdio.h>

int main(void)
{
    char* toto = "salade";
    *toto = 'm';
    puts(toto);
    return 0;
}
Ce code plante (du moins avec gcc et clang). Pourquoi ?
D’ailleurs à noter que gcc et clang, mode normal ne signale rien. En revanche gcc en mode maniaque émet un warning, clang toujours rien.
A l'arrache : je crois qu'il faut déclarer le tableau en const, si on crée une chaîne de cette manière, non ?

Le code que tu cites déclares un pointeur, pas un tableau.

:!pakman a écrit :

Je crois me souvenir d'un problème à la con dans le genre
const char* toto = "salade";
C'est bon ? Y'a toujours un warning ?

Oui, si tu mets const ça ne crasheras plus, car normalement le compilo va émettre une erreur lors de la compilation.

Le plus intéressant c’est pourquoi ça plantait (sachant que le plantage étant le comportement le plus courant, mais vu que c’est un comportement indéfini la norme autorise le compilateur à te faire sortir des démons du pif) ?

Pour ceux qui ne voit pas ce que des démons viennent faire ici, voilà la référence

:!pakman · Le 14/03/2013, à 09:12

Thanks

grim7reaper · Le 14/03/2013, à 10:34

Si personne ne trouve pourquoi l’un plante et pas l’autre, je donnerais la solution ce soir.
Mais je pense que certains peuvent trouver

The Uploader · Le 14/03/2013, à 11:11

grim7reaper a écrit :

#include <stdio.h>

int main(void)
{
    char* toto = "salade";
    *toto = 'm';
    puts(toto);
    return 0;
}
Ce code plante (du moins avec gcc et clang). Pourquoi ?

Ben tu définis *toto deux fois, et la deuxième fois c'est un pointeur de "type" void (donc on sait pas la taille). Puts accède à n'importe quoi.

Le pointeur de type void c'est pas forcément une erreur (d'où le fait que ça passe la compil', voire très bien vu qu'il n'y presque pas de warning), mais si on veut vraiment faire ça (j'vois pas trop l'intérêt) ben faudrait pouvoir spécifier la taille à puts.

Après je me goure peut-être... (quand même ça m'a fait du bien de réviser mon C avec dosbox, avant j'pense que j'aurais même pas trouvé une réponse qui tient à peu près la route sans devoir compiler/tester des modifs).

Le C c'est sadique parfois, mais ça fait travailler les neurones.

----

Tiens d'ailleurs mon truc d'enregistrement dans un thread se met à ramer au bout d'un heure environ. Suffit de stopper - ce qui bloque DOSBox sur un Wait_Thread jusqu'à quelques minutes alors que la queue n'est pas censée être très grosse O_o - et de redémarrer l'enregistrement pour avoir à nouveau une heure avant que ça rame à nouveau.

J'ai pas compris sur ce coup là encore... (j'ai pas vraiment regardé la conso mémoire au bout d'une heure, vu comment ça prend tout le système par les tripes une fois que ça se met à ramer. Mais avant cette limite j'ai beau regarder pendant des minutes entières je vois pas de fuite mémoire).

----

Et sinon le patch qui rajoute l'émulation de la 3DFX Voodoo 1 ne marche pas encore avec des jeux DOS car le changement de résolution de la carte n'est pas implémenté (typiquement quand on passe du 320x200 du dos au 640x480 minimum de la carte). Ça marche qu'avec Win95 et des jeux Windows/Glide/Direct3D tels que le premier Tomb Raider avec le patch 3DFX qui va bien parce que Win95 est déjà au minimum en 640x480 sur la carte graphique 2D (S3 Trio par défaut) émulée (la 3DFX ne faisant QUE de la 3D à partir d'un port PCI, avec un câble VGA<-> VGA entre les deux cartes et l'écran branché sur la 3DFX. La 2D/3D sur la même carte qui se met sur un port AGP2X ou plus il a fallu attendre la Voodoo Banshee pour ça).

---

(putain c'est toujours aussi con Starship Troopers, même en HD, et surtout le matin)

Dernière modification par The Uploader (Le 14/03/2013, à 11:24)

grim7reaper · Le 14/03/2013, à 11:21

The Uploader a écrit :

grim7reaper a écrit :
#include <stdio.h>

int main(void)
{
    char* toto = "salade";
    *toto = 'm';
    puts(toto);
    return 0;
}
Ce code plante (du moins avec gcc et clang). Pourquoi ?
Ben tu définis *toto deux fois, et la deuxième fois c'est un pointeur de "type" void (donc on sait pas la taille). Puts accède à n'importe quoi.

Nope, je ne le déclare qu’une seule fois.

char* toto = "salade";

Après je fais une assignation :

*toto = 'm';

Pour tranformer « salade » en « malade ».
En cas de double définition, ça ne passe pas la compilation.

The Uploader · Le 14/03/2013, à 11:27

Hum, damned.

Ça va m'obséder, s'malin. J'devais être productif aujourd'hui.

edit : ah ben c'est même pas puts qui plante en fait.

Dernière modification par The Uploader (Le 14/03/2013, à 11:34)

The Uploader · Le 14/03/2013, à 11:45

We also need to understand the two different ways that string literals like "now is the time" are used in C. In the definition
char amessage[] = "now is the time";
the string literal is used as the initializer for the array amessage. amessage is here an array of 16 characters, which we may later overwrite with other characters if we wish. The string literal merely sets the initial contents of the array. In the definition
char *pmessage = "now is the time";
on the other hand, the string literal is used to create a little block of characters somewhere in memory which the pointer pmessage is initialized to point to. We may reassign pmessage to point somewhere else, but as long as it points to the string literal, we can't modify the characters it points to.

http://www.eskimo.com/~scs/cclass/krnotes/sx8e.html

Ahhh !

J'ai bien essayé de faire :

*toto[0] = 'm';

(ce qui me semblait plus approprié pour modifier seulement le premier caractère, mais quand ça a planté j'ai été surpris - "what ? j'ai pourtant vu ce genre de choses en C !" - et avec une recherche rapide voilà l'explication).

Faut faire plutôt ça :

#include <stdio.h>

int main(void)
{
      char toto[] = "salade";
      toto[0] = 'm';
      puts(toto);
      return 0;
}

J'étais pourtant sûr qu'on pouvait modifier le contenu du string sur lequel pointe un pointeur de type *char ?

(

Starship Troopers a écrit :

"Remember your training and you will make it back alive"

Ah oui, le conseil m'a été utile sur ce bout de code, enfin un peu )

Dernière modification par The Uploader (Le 14/03/2013, à 11:51)

nathéo · Le 14/03/2013, à 11:49

Il ne vaudrait pas plutôt faire un simple

toto[0] = 'm'

?

EDIT : Bah t'as corrigé tout seul

Dernière modification par nathéo (Le 14/03/2013, à 11:59)

The Uploader · Le 14/03/2013, à 11:54

moi a écrit :

J'étais pourtant sûr qu'on pouvait modifier le contenu du string sur lequel pointe un pointeur de type *char ?

J'crois que j'suis trop habitué aux références des langages comme Ruby, et que ça déteint sur mes souvenirs des pointeurs en C.

A force de se dire que les références sont des pointeurs, voilà ce que ça donne.

Dernière modification par The Uploader (Le 14/03/2013, à 11:58)

grim7reaper · Le 14/03/2013, à 12:00

@The Uploader : yep, c’est bien ça.
Les chaînes littérales peuvent être placées dans une mémoire en lecture seule (vu qu‘elles sont constantes), donc tenter de les modifier est un comportement indéfinie(Cf. la norme).
La première solution, via le tableau, fonctionne car la chaîne est utilisant en tant qu’initialiseur du tableau et est donc copié dedans.
Un autre lien sur le sujet.

Tu peux modifier des chaînes via des pointeurs (char*), mais pas quand ça pointe sur des chaînes littérales (vu qu’elles sont constantes et donc, pas définition, pas modifiables).

Dernière modification par grim7reaper (Le 14/03/2013, à 12:02)

nathéo · Le 14/03/2013, à 12:00

Références en ruby ? Est-ce que c'est une sorte de classe, ou simplement la manière dont les tableaux sont perçus ?

The Uploader · Le 14/03/2013, à 12:11

@grim' : \o/
Merci pour l'explication.

(maintenant que j'ai trouvé je vais pouvoir passer à autre chose, genre ouvrir les volets)

@nathéo :
La référence à un objet en Ruby, ça se voit avec Object#object_id. Tu manipules constamment des références dans un langage objet.

Dernière modification par The Uploader (Le 14/03/2013, à 12:27)

nathéo · Le 14/03/2013, à 12:22

Ok merci, je vais faire des recherches sur le sujet, pour ce que je codais, résonner un peu comme en C suffisait.

grim7reaper · Le 14/03/2013, à 13:04

The Uploader a écrit :

@grim' : \o/
Merci pour l'explication.

De rien.

The Uploader a écrit :

(maintenant que j'ai trouvé je vais pouvoir passer à autre chose, genre ouvrir les volets)

The Uploader a écrit :

Tu manipules constamment des références dans un langage objet.

Pas forcément. En C++ les deux existent (pointeurs et références).

The Uploader · Le 14/03/2013, à 13:30

Ah, exact. J'pensais surtout à Java, Python, etc...

Pylades · Le 14/03/2013, à 13:40

maxpoulin64 a écrit :

Par contre chez moi le code compile bien, mais y'a peut-être 2-3 caractères invisibles par ci par la vu que c'est copié d'un document en .doc.

En fait, « 'o' » changé en « ‘o’ ». Encore un exemple que les substitutions automatiques c’est evil.

Et sinon, je ne trouve pas que ce problème tire exagérément dans les coins.

:!pakman · Le 14/03/2013, à 13:48

grim7reaper a écrit :

@The Uploader : yep, c’est bien ça.
Les chaînes littérales peuvent être placées dans une mémoire en lecture seule (vu qu‘elles sont constantes), donc tenter de les modifier est un comportement indéfinie(Cf. la norme).
La première solution, via le tableau, fonctionne car la chaîne est utilisant en tant qu’initialiseur du tableau et est donc copié dedans.
Un autre lien sur le sujet.
Tu peux modifier des chaînes via des pointeurs (char*), mais pas quand ça pointe sur des chaînes littérales (vu qu’elles sont constantes et donc, pas définition, pas modifiables).

Impressionnant, j'ignorais tout ça

Rolinh · Le 14/03/2013, à 18:41

C'est relativement courant comme erreur. Pas plus tard que vendredi dernier, un ami m'a demandé de débugger le code d'une élève parce qu'il ne trouvait pas pourquoi la réaffectation d'une variable ne fonctionnait pas. Et c'était précisément pour cette raison.

@grim: Merci. Je vais modifier le CMakeLists.txt alors.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#826 Le 14/03/2013, à 01:11

Re : /* Topic des codeurs [8] */

#827 Le 14/03/2013, à 02:47

Re : /* Topic des codeurs [8] */

#828 Le 14/03/2013, à 03:27

Re : /* Topic des codeurs [8] */

#829 Le 14/03/2013, à 05:04

Re : /* Topic des codeurs [8] */

#830 Le 14/03/2013, à 07:21

Re : /* Topic des codeurs [8] */

#831 Le 14/03/2013, à 08:16

Re : /* Topic des codeurs [8] */

#832 Le 14/03/2013, à 08:34

Re : /* Topic des codeurs [8] */

#833 Le 14/03/2013, à 08:56

Re : /* Topic des codeurs [8] */

#834 Le 14/03/2013, à 09:12

Re : /* Topic des codeurs [8] */

#835 Le 14/03/2013, à 10:34

Re : /* Topic des codeurs [8] */

#836 Le 14/03/2013, à 11:11

Re : /* Topic des codeurs [8] */

#837 Le 14/03/2013, à 11:21

Re : /* Topic des codeurs [8] */

#838 Le 14/03/2013, à 11:27

Re : /* Topic des codeurs [8] */

#839 Le 14/03/2013, à 11:45

Re : /* Topic des codeurs [8] */

#840 Le 14/03/2013, à 11:49

Re : /* Topic des codeurs [8] */

#841 Le 14/03/2013, à 11:54

Re : /* Topic des codeurs [8] */

#842 Le 14/03/2013, à 12:00

Re : /* Topic des codeurs [8] */

#843 Le 14/03/2013, à 12:00

Re : /* Topic des codeurs [8] */

#844 Le 14/03/2013, à 12:11

Re : /* Topic des codeurs [8] */

#845 Le 14/03/2013, à 12:22

Re : /* Topic des codeurs [8] */

#846 Le 14/03/2013, à 13:04

Re : /* Topic des codeurs [8] */

#847 Le 14/03/2013, à 13:30

Re : /* Topic des codeurs [8] */

#848 Le 14/03/2013, à 13:40

Re : /* Topic des codeurs [8] */

#849 Le 14/03/2013, à 13:48

Re : /* Topic des codeurs [8] */

#850 Le 14/03/2013, à 18:41

Re : /* Topic des codeurs [8] */

Pied de page des forums