http://www.jeuxvideo.com/cgi-bin/j [...] _while.cpp
Je voudrais faire la même chose, mais pour que le code soit "oui" j´ai essayé en remplacant 23 par "oui" mais ça marche pas
Comment faire svp?
Merci!

"oui" est une chaine de caractères, tu ne peux donc pas utiliser les opérateurs mathématiques pour comparer deux chaines de caractères entre elles. Il existe des fonctions spéciales pour cela, en particulier strcmp().

Tu pourrais me donner un exemple stp?
Merci

post_it : strcmp() c'est du C, ici on est en C++
 

C'est vrai, mais  C++ est une extension du langage C, donc tout ce qui est valide en C est valide en C++.
D'ailleurs, on n'est même pas obligé de faire de l'objet pour faire du C++ !
C'est un peu bête, je sais !  

 
C'est toi qui est un peu bête ... du C++ sans objet est une connerie sans nom, tout comme utiliser l'API C sur des types commes les chaines de caractéres ...

ptain quand les gens comprendront que le c++ n'est pas qu'une 'extension' du c ...

L'objet n'est pas lié au langage. On peut faire de l'objet en C. C'est moins pratique c'est tout.
A la base le C++ voulait être un meilleur C, mais on est arrivé à un autre langage, réellement à part, qui est compatible avec le C dans une certaine mesure, mais qui n'est pas une extension du C.
Le C++ a ses propres méthodes de manipulation des chaines de carcatères. Il faut oublier les char*.

 
"moins pratique", je reve, l'objet en C c'est un truc a se jeter par la fenetre

mais le C, à quelques détails près, est un sous ensemble du C++
tout bon prog C est un prog C++ comme dit stoustrup
 
celà dit même si je trouve qu'un petit printf parfois est + simple qu'un formattage de cout, pour presque tout coder comme en C, autant faire du vrai C. Un projet C++ peut très bien comporter des partie en C. C'est conçu pour, faut juste penser à utiliser extern "C".
 

je suis complétement d'accord. Même si ça peut parraître simpliste, pour moi C + objet = C++. C'est une des raisons pour lesquels je n'aime pas Objective C.
Coder en objet avec du C c'est faire le boulot de CFront : convertir du C++ en C, c'est à dire passer this à la main en paramètre des méthodes etc. Inutile et fastidieux.

 
De mon temps, on en fusillé pour moi que ça  

je ne vois pas en quoi extern "C" est mal. C'est standard et portable, ce qui deviens rare de nos jour avec la mode du .Net et du managed. Je trouve assez élégant de faire qlq partie d'un projet en C pur, pour optimiser. L'opti me semble plus naturelle en C qu'en C++.

 
.net est standart, a sa facon, et portable oué, assurément
mais c'est pas le sujet, revenons donc au techno paleolithique. Extern "c" c'est bien, pour dire au compilo "degage avec ta décoration de noms" et c'est tout

.net il est standard avec lui-même et avec sa version actuelle.
Voir les progs java qui ne sont ni bytecode-compatible ni code-compatible avec la JVM java 5. Des progs qui ne peuvent plus s'exécuter ni se recompiler sans mise à jour Alors la notion de standard chez java/.net...

 
OSEF en fait, c'est pas le sujet. En C++ on utilise string, faut être masochiste pour en rester aux char*.
C'est tout, y a pas à chercher plus loin.

L'évolution des langages est quelque chose de normal. Même maintenant écrire un prog C++ (d'une taille minimale) qui compile sous plusieurs compilos c'est pas évident. Alors prend un prog C++ écrit il y a 5 ans, et recompile le avec le même compilo dans sa version récente.  
Pour la version compilée c'est pareil, pour peu que la libc a changé badaboum. Ah non, pas sous Windows, où un prog compilé il y a 20 ans tourne toujours 8)

 
(.net est standardisé iso/ecma je crois bien)

Ah ? J'aurai dit un peu moins

Pareillement.

 
mais bien sûr.

Dans 15 jours, Windows a 20 ans

Utiliser void* sans cast c'est légal mais crade.
Tous les exemple du K&R ANSI (qui date de 89) compilent en C++.
Et puis remet pas en cause les paroles de stroustrup ou je m'énerve

 
Crade ?!
C'est dans la norme, ce n'est pas "crade", et c'est même un soulagement que d'écrire des malloc() à peu près lisibles    

 
Je sais pas si tu es au courant, mais on en est au C99 et au C++98 maintenant
 
Genre je doute que tu puisses compiler un prog C avec VLA en C++    
 
http://david.tribble.com/text/cdiffs.htm#C99-vs-CPP98

oui

 
jsavais pas

merci mais je connais le C99
pour être puriste je répète que tout bon programme C (sous entendu C89, le C99 reste peu employé) est un prog C++, en particulier les exemples du K&R. (citation page 16 du stroustrup 3e edition française)
 
cela dit pour le malloc je suis d'accord, moi-même je ne mets pas de cast, mais dans le K&R ils en mettent toujours.

Une des rares différences silencieuses. Ca compile des deux cotés sans warning mais le comportement est différent. En C toute constante entière littérale (non typée explicitement) est un entier. C'est le cas des enum (alors que c'est faux en C++)
 
enum truc { TOTO };
sizeof(TOTO) == sizeof(int) en C. Pas forcément en C++.

 
Regarde le prototype de fonctions qui acceptent un caractère, strchr() par exemple
 

 
Mais même avec le C89 il y a des incompatibilités avec le C++

ouais ca je sais, mais j'etais pas allé au dela en fait
 

J'ai pas dit qu'il y avait pas d'incompatibilité, j'ai dit que du C bien écrit c'est aussi du C++ au sens ou ça compile en mode C++.

bin pour moi ca reste du C meme si ca compile en c++, paske faire du C en C++ c'est cretin, enfin, voila quoi  
 
(quel fin debat)
 
(on s'en fout)

bidon
 
while(cin >> ligne && ligne != "oui" )
{
 
}