Reprise du message précédent :
[

Ben je dirais que c'est bon parce que:
dans le cas 1 : retour de la valeur de ch, ch etant definis comme
char et donc signe', et EOF = -1 donc la conversion est correct.
dans le cas 2: trivial !
 
en fait il aurait fallu declarer unsigned ch ... et la boucle infinie !
 
Plucker

 
putain j'hallucine !
On leur montre une ferrari et ils la confondent avec une chaise
 
Le programme à l'écran c'est un logiciel qui s'appelle Together qui permet de concevoir et de programmer des logiciels
 
http://togethersoft.com/index.jsp
http://togethersoft.com/products/c [...] /index.jsp
 
Son principal avantage est qu'il permet le round trip engineering
C'est à dire la faculté de modifier le diagramme de classes et de répercuter les modifications sur le code source
inversement lorsque l'on modifie le code source, ca modifie le diagramme de classes automagiquement.
 
Par exemple, je crée une classe en un clic, ca me génére le .h et le .cc. je clique sur ajouter un constructeur et automatiquement il est ajouté.
Si je modifie les paramètres du constructeur que je viens d'ajouter, ca va modifier le diagramme UML
 
Ca fait aussi les diagrammes de séquences, l'audit du code source, le refactoring, la génération de la documentation, ca supporte le C++ et Java, on peut facilement implémenter les design patterns du GOF, intègre un frontend à CVS, le debug, constructeur d'interface graphique, export/import xmi, reconnait EJB J2EE XML  ect...
 
C'est LE soft de développement le plus avancé à l'heure actuelle
Eclipse, rational rose ou netbeans ne proposent pas le quart de ce que fait Together.
Ca fait 4 mois que je l'utilise et pour moi c'est révolutionnaire pour le développement. Tu peux vraiment te concentrer sur la conception, tu peux communiquer facilement avec les autres codeurs et tu détectes très rapidement les erreurs que tu fais.
 
http://tanguy.dyndns.org/~tanguy/together3.gif
 
Ce qu'on voit à l'image c'est le diagramme de classes d'un logiciel qui comporte en jaune des interfaces, en vert un joli design patterns, en rose des observer, un héritage en diamant...
ca représente un onglet dans Together. les autres onglets comportent des diagrammes similaires.
Sans Together il aurait fallu 10x plus de temps pour programmer ce qu'il y a à l'écran.
 
Pour ceux qui trouvent que c'est juste des traits et des rectangles, il vaut mieux qu'ils changent de métier.

ben on dit pas, mais pkoi on pourrait pas le faire avec visu ?  
 
(et bon, quand on connait le prog, la seule chose qu'on voit c bien des traits et des rectangles)

Euh siouplait non, pas de géguerre sur les EDI ici.
Vous savez bien que c'est des sujets qui fachent, alors allez vous battre ailleurs.
 
 
Plucker:
-"unsigned char" (de 0 à 255)
-"signed char" (de -128 à 127)
-"char" est un type distinct.
Selon les implémentaions , "char" peut être comme signed ou unsigned.
 
Quoi qu'il en soit, "EOF" n'est PAS un caractère, et sa valeur (qui ne regarde personne soit dit en passant) n'est celle d'aucun caractère.
C'est pourquoi "getchar" renvoie un "int" plutôt qu'un "char": pour caser cette valeur.
Donc "ch=getchar()" ne peut valoir "EOF". Du moins ne devrait pas.
 
 
[B]Trouvez le bogue !(9)[/B]

Ce code contient un bogue en puissance.
Un débutant faisant des essais pourrait tomber dessus... ou pas.

J'aurais plutôt mis  
 

Mais je pense que c plus cosmétique qu'autre chose.  

 
C bien joli tout ça mais on était surtout parti sur la qualité des compilo en eux même, et même si les fonctionalités de Together on l'air géniale ct pas franchement le sujet de départ (c bien beau d'avoir un chouete code mais si tu peux pas le compiler correctement après c moyen) et de toute manière ct pas le topic de départ donc on va arréter là

1) Il y a une différence plus que cosmétique.
2) Ta proposition corrige le problème.

 
Ha, ben tant mieu alors
 
J'aime pas avoir la réponse sans savoir pkoi elle est bonne

quelle différence entre char var[] et char* var ?

A mon avis dans le prmier cas le compilo réserve de la place soit sur la pile soit dans le ségment de donnée pour la chaine, dans le deuxième tu déclare un pointeur sur une chaine qui est crée sur la pile... Ouai c pas flagrant là différence ne fait, heu ça doit pas être ça
 
Edit: En fait si par ce que y a de forte chance que la chaine disparaisse après l'instruction dans le 2eme cas:

 
Alors que dans le prmier elle fait partie des variables locale de la fonction.

Ca devient un peu tordu. A ce niveau la j'ai ca pour vous :
 
Ce code contient un bug en puissance
 

 
 
 
 
 
 
 
 
 
 
Réponse : c'est du C ou du C++.

 
il faut faire une allocation mémoire de la chaine

C'est très différent pour sizeof par exemple.
 

Non, jamais.
 
Je vous laisse encore chercher, puis je vous fait un cours magistral.
 
Kristoph:
C'est valide en C et C++. Pas de bogue.

Pas du tout.
Disons, éventuellement si je veux écrire dedans.

Disons le \0 alors

C'est pas bugué mais c'est tellement excellent!
C'est du C
 

 
Pas mal, hein?

OUahou!!!!!!!! Ca compile ca???

Non, ca ne compile pas...dommage

Excuse moi, mais ça compile parfaitement bien!
Ca dessine des bonhommes en ASCII, c'est excellent !

ITM a écrit a écrit :     char *T="IeJKLMaYQCE]jbZRskc[SldU^V\\X\\|/_<[<:90!\"$434-./2>]s", K[3][1000],*F,x,A,*M[2],*J,r[4],*g,N,Y,*Q,W,*k,q,D; X() ici on déclare X {r  [r [r[3]=M[1-(x&1)][*r=W,1],2]=*Q+2,1]=x+1+Y,*g++=((((x&     7) -1)>>1)-1)?*r:r[x>>3],(++x<*r)&&X();}E(){A||X(x=0,g=J) ici on l'invoque ,x=7&(*T>>A*3),J[(x[F]-W-x)^A*7]=Q[x&3]^A*(*M)[2         +( x&1)],g=J+((x[k]-W)^A*7)-A,g[1]=(*M)[*g=M[T+=A            ,1 ][x&1],x&1],(A^=1)&&(E(),J+=W);}l(){E(--q&&l              () );}B(){*J&&B((D=*J,Q[2]<D&&D<k[1]&&(*g++=1                ), !(D-W&&D-9&&D-10&&D-13)&&(!*r&&(*g++=0)                   ,* r=1)||64<D&&D<91&&(*r=0,*g++=D-63)||D                     >= 97&&D<123&&(*r=0,*g++=D-95)||!(D-k[                       3] )&&(*r=0,*g++=12)||D>k[3]&&D<=k[                          1] -1&&(*r=0,*g++=D-47),J++));}j(                            ){ putchar(A);}b(){(j(A=(*K)[D*                              W+ r[2]*Y+x]),++x<Y)&&b();}t                                 () {(j((b(D=q[g],x=0),A=W)                                   ), ++q<(*(r+1)<Y?*(r+1):                                     Y) )&&t();}R(){(A=(t(                                        q= 0),'\n',j(),++r                                          [2 ]<N)&&R();}O()                                            {( j((r[2]=0,R(                                              )) ),r[1]-=q)                                                && O(g-=-q)                                                  ;} C(){(                                                     J= gets                                                      (K [1]))&&C((B(g=K[2]),*r=!(!*r&&(*g++=0)),(*r)[r]=g-K[2],g=K[2 ],r[ 1]&& O()) );;} main (){C ((l( (J=( A=0) [K], A[M] =(F= (k=( M[!A ]=(Q =T+( q=(Y =(W= 32)- (N=4 )))) +N)+ 2)+7 )+7) ),Y= N<<( *r=! -A)) );;}

 
Le nombre de parametres passé a X est incorrect

Il est temps de répondre.
 
[B]Solution (7):[/B]

L'analyseur syntaxique du C/C++ est dit "gourmand": il prends le plus gros morceau qu'il reconnaisse.
C'était juste pour rappeler que la syntaxe du C++ n'est pas analysée en fonction du contexte: il ne va pas interpréter le symbole ">>" comme ">"+">" juste parceque ce serait plus approprié.
 
[B]Solution (9):[/B]
Les chaînes C littérales "..." sont des [B]constantes[/B].
"chaineC" est un pointeur sur caractères non constants, et permet donc de (tenter de) modifier la constante.
Si votre compilateur et votre OS gèrent les pages de données en lecture seule, cela ferait une violation de mémoire.
Pourquoi les compilateurs ne protestent pas ? Sans doute parceque c'est tellement courant...

Je prépare un post pour en parler plus en détail et de façon plus générale.

[B]Trouvez le bogue !(10 à 15)[/B]

 
Y a u ntruc qui va pas là:

ce serait pas plutôt:

ITM a écrit a écrit : C'est pas bugué mais c'est tellement excellent! C'est du C   Code : #include <stdio.h> char *T="IeJKLMaYQCE]jbZRskc[SldU^V\\X\\|/_<[<:90!\"$434-./2>]s", K[3][1000],*F,x,A,*M[2],*J,r[4],*g,N,Y,*Q,W,*k,q,D;X(){r  [r [r[3]=M[1-(x&1)][*r=W,1],2]=*Q+2,1]=x+1+Y,*g++=((((x&     7) -1)>>1)-1)?*r:r[x>>3],(++x<*r)&&X();}E(){A||X(x=0,g       =J ),x=7&(*T>>A*3),J[(x[F]-W-x)^A*7]=Q[x&3]^A*(*M)[2         +( x&1)],g=J+((x[k]-W)^A*7)-A,g[1]=(*M)[*g=M[T+=A            ,1 ][x&1],x&1],(A^=1)&&(E(),J+=W);}l(){E(--q&&l              () );}B(){*J&&B((D=*J,Q[2]<D&&D<k[1]&&(*g++=1                ), !(D-W&&D-9&&D-10&&D-13)&&(!*r&&(*g++=0)                   ,* r=1)||64<D&&D<91&&(*r=0,*g++=D-63)||D                     >= 97&&D<123&&(*r=0,*g++=D-95)||!(D-k[                       3] )&&(*r=0,*g++=12)||D>k[3]&&D<=k[                          1] -1&&(*r=0,*g++=D-47),J++));}j(                            ){ putchar(A);}b(){(j(A=(*K)[D*                              W+ r[2]*Y+x]),++x<Y)&&b();}t                                 () {(j((b(D=q[g],x=0),A=W)                                   ), ++q<(*(r+1)<Y?*(r+1):                                     Y) )&&t();}R(){(A=(t(                                        q= 0),'\n'),j(),++r                                          [2 ]<N)&&R();}O()                                            {( j((r[2]=0,R(                                              )) ),r[1]-=q)                                                && O(g-=-q)                                                  ;} C(){(                                                     J= gets                                                      (K [1]))&&C((B(g=K[2]),*r=!(!*r&&(*g++=0)),(*r)[r]=g-K[2],g=K[2 ],r[ 1]&& O()) );;} main (){C ((l( (J=( A=0) [K], A[M] =(F= (k=( M[!A ]=(Q =T+( q=(Y =(W= 32)- (N=4 )))) +N)+ 2)+7 )+7) ),Y= N<<( *r=! -A)) );;}   Pas mal, hein?

 
tu compile ca avec quoi  

Oups, erreur d'intervalle et deux fois le même bogue.
De 10 à 15 donc.
 
[B]Solution (10):[/B]
Oui bien sûr, %c pour un char.
Par contre, pas besoin de backslash pour une apostrophe dans une chaîne: "...'%c'...".
Pareillement, pas besoin de backslash pour un caractère guillemet seul: '"'.

 
064 c'est de loctal donc ce n'est pas le caractere 64 prevu.
 
Bon au dodo maintenant

 
Ben si tu devais te fader de debugger sur un Mac avec CodeWarrior, tu comprendrais a quel point Visual C++ est un outil appreciable...[J'ai connu pire: le debug avec les outils Metaware de code pour Windows 3.1]
 
Moi j'ai utilisé pas mal d'outils sous SunOs/Dec Ultrix/Aix/HP-UX/Linux/Dos...Win2K/Mac Os9 pour compiler du C et C++ et je jeterrais pas la pierre a Visual C++.
Avec un certain nombre d'additifs (les librairies Dinkumware...) c'est un compilo (en ligne, j'utilise pas leur systeme merdique de projets) utilisable. J'utilise l'IDE uniquement pour debugger (j'edite sous emacs), et c'est un assez bon outil pour ça.
 
A+,

Allez, en voila d'autres réponses :
 

 
TRUE n'est pas définie dans la norme C que je sache, donc ça n'a que peut de chances de marcher.
 
Dans le cas ou TRUE est définie, le comportement de la comparaison n'est pas garanti quand même. En effet, le "true" en C est un int different de 0. Donc si TRUE vaut 1 et que isalpha(in) retourne -1 pour dire vrai, tu l'as dans l'os car ton test echoue alors qu'il devrait réussir.
 

On est plus à l'époque de windows 3.1, depuis les outils on grandement évolués.
moi j'ai commencé avec Visual, je l'ai utilisé pendant longtemps parceque tout le monde utilise ca et que je pensais tout simplement qu'il n'y avait pas grand chose de mieux.
Mais essaye Together pour le C++ et le Java, charges juste les sources d'un soft et tu vas voir que c'est magique.
C'est sur que si tu compares Visual à CodeWarrior...

 
Que je sache, et meme si ce n'est pas une norme ,TRUE devrait être défini comme !0 , et dans ce cas, ca marche.

red faction a écrit a écrit :     tu compile ca avec quoi

Ca se compile avec un compilo C ANSI. Ce programme est un des gagnants d'un concours dont j'ai oublié le nom qui vise à écrire le code C le plus crade possible. Ca doit avoir deja une paire d'années, mais c'est vraiment très bien fait. J'ai deja essayé de comprendre comment ca marche, mais j'ai pas reussi

http://www.es.ioccc.org/main.html
Pour ceux que ca intéresse ( Merci a ITM! )

Kristoph a trouvé:
Solution(11): oui, il faut faire attention à cette base octale. Accessoirement, pourquoi exite-t'elle alors que la binaire non ?
Solution(12): TRUE, c'est dans quel define ? C'est lié à  Windows ?
Solution(13): La valeur de TRUE ne devrait pas être importante. Et isalpha retourne "différent de 0" si vrai.
Difficile d'avoir une égalité dans ces conditions.
Donc t'as perdu R3g !

pas mal ta signature musaran!
dans quel cas ca devient un viol (du point de vue de la programmation!)?

Je comprends pas :
en admettant qu'on aie #define TRUE !0 (ce que je crois vrai, oui ca doit etre dependre de windows), et que isalpha renvoie "different de 0", c'est à dire n'importe quoi sauf 0,
 alors (isalpha() == TRUE) equivaut à (isalpha() == !0), ce qui est equivalent à (isalpha() != 0), ce qui est vrai. CQFD    
 
Peux-tu m'expliquer où j'ai faux ?

 
signed char : -128 à +127

"La transmission d'arguments entre une fonction et et son appelant est comme un baiser, ça ne doit pas être un viol."
J'ai lu ça dans un livre sur l'art de la programmation.
Il y est dit qu'on doit être clair sur ce à quoi une fonction accède, et de quelle façon.
Notamment, qu'on ne doit pas abuser des information reçues par une fonction pour mettre son nez là où ce n'est pas prévu.
Par exemple:

Ça a l'air bête résumé comme ça, mais il y a plein de moyens détournés de faire l'équivalent.
 
"Même avec les clés, un voleur reste un voleur".
Ce qui veut dire que c'est pas parce qu'on sait comment accéder à quelque chose que c'est légitime de le faire.
 

Là: "(isalpha() == !0), ce qui est equivalent à (isalpha() != 0)".
Non, c'est pas des formules mathématiques mais des intructions, et tu ne peux pas faire ce genre de "simplifications".
!0 vaut 1, mais la valeur de isalpha n'étant pas connue exactement, un test d'égalité a peu de chance de marcher !
 

bjone a écrit a écrit : signed char : -128 à +127

J'ai tendance à être bogué vers minuit.

 
Ok d'accord ! Je pensais nahivement que !0 avait une valeur indéterminée (mais differente de 0) !

"si indéterminé==indéterminé..."
Aucun sens pour moi.
 
Il est spécifié (C++) que !0 vaut 1.
Mais ! est avant tout un opérateur logique (vrai-faux).
Il vaut mieux penser en termes de !false vaut true (et inversement).
Et si on a un entier plutôt qu'un booléen, il est plus sain de faire une comparaison avec un entier pour produire un booléen.
 
Ça évites ce genre de bogue /*int*/==true.

en fait mon idee c'etait plutot si (tout sauf 0 == tout sauf 0).
mais bon, ca y est j'ai compris, je discute plus

 
J'ai toujours pas compris ou était l'erreur