Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

Attention, une faille de sécurité dans bash a récemment été rapportée, il est recommandé de mettre à jour son système (plus de détails)

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

Pylades

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

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. tongue)
(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, à 02:15)


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne

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

The Uploader

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

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, à 03:48)


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

maxpoulin64

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

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  ===> []

Hors ligne

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

grim7reaper

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

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, à 06:24)

Hors ligne

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

maxpoulin64

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

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 tongue

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 hmm

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.

Hors ligne

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

grim7reaper

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

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 smile

Hors ligne

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

:!pakman

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

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 mad

const char* toto = "salade";

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

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


...

Hors ligne

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

grim7reaper

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

:!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 mad

const char* toto = "salade";

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

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 wink

Hors ligne

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

:!pakman

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

Thanks wink


...

Hors ligne

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

grim7reaper

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

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 wink

Hors ligne

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

The Uploader

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

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, à 12:24)


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

grim7reaper

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

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.

Hors ligne

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

The Uploader

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

Hum, damned. lol

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

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

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


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

The Uploader

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

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 ! yikes

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 big_smile )

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


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

nathéo

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

Il ne vaudrait pas plutôt faire un simple

toto[0] = 'm'

?

EDIT : Bah t'as corrigé tout seul tongue

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


C'est rarement par le sarcasme qu'on élève son âme.
Le jus de la vigne clarifie l'esprit et l'entendement.
De quoi souffres-tu ? De l'irréel intact dans le réel dévasté ?
N'oubliez pas d'ajouter un [RESOLU] si votre problème est réglé.ᥟathé൭о

Hors ligne

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

The Uploader

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

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, à 12:58)


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

grim7reaper

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

@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, à 13:02)

Hors ligne

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

nathéo

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

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 ?


C'est rarement par le sarcasme qu'on élève son âme.
Le jus de la vigne clarifie l'esprit et l'entendement.
De quoi souffres-tu ? De l'irréel intact dans le réel dévasté ?
N'oubliez pas d'ajouter un [RESOLU] si votre problème est réglé.ᥟathé൭о

Hors ligne

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

The Uploader

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

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

(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, à 13:27)


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

nathéo

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

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


C'est rarement par le sarcasme qu'on élève son âme.
Le jus de la vigne clarifie l'esprit et l'entendement.
De quoi souffres-tu ? De l'irréel intact dans le réel dévasté ?
N'oubliez pas d'ajouter un [RESOLU] si votre problème est réglé.ᥟathé൭о

Hors ligne

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

grim7reaper

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

The Uploader a écrit :

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

De rien.

The Uploader a écrit :

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

lol

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).

Hors ligne

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

The Uploader

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

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


Passer de Ubuntu 10.04 à Xubuntu 12.04 LTS
ASUS N56VV (UEFI + GPT, Core i5-3230M @ 2.60GHz, Intel HD4000 + GeForce 750M, 12 Go de RAM, SSD 1 To)
Système principal : Archlinux (amd64), avec KDE
Système oublié la plupart du temps : Windows 8.1 Update 1 (x64, OEM)

En ligne

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

Pylades

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

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.


“Any if-statement is a goto. As are all structured loops.
“And sometimes structure is good. When it’s good, you should use it.
“And sometimes structure is _bad_, and gets into the way, and using a goto is just much clearer.”
                Linus Torvalds – 12 janvier 2003

Hors ligne

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

:!pakman

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

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 yikes


...

Hors ligne

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

Rolinh

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

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.


Blog
"If you put a Unix shell to your ear, do you hear the C ?"

Hors ligne

Haut de page ↑