bonsoir  
 
bon le problème est surement super connue, mais je le relance quand même parceque j'ai pas trouver ce que je voulais, dans mes recherches sur le forum.
 

 
seulement quand j'entre un chemin absolu du style "c:\ok.txt" je me retrouve avec Buffer contenant ceci "c:\\ok.txt"
 
donc ma question est la suivante, comment saisir qu'1 antislash?

je rêve ou tu mix C et C++ ?
 

heu ouai c vrai que j'utilisela syntaxe c++ le plus possible mais je reste C dans ma construction. Donc oui j'ai pas posté au bon endroit peu etre
 
Pour le cin et bien non je veux pas m'en servir. mon but c'est de recuperer caractere par caractere le chemin(url) du fichier (pour ensuite aller le lire ...).  
mais je vois pas comment empecher le double antislash que je recupere alors que j'en tape qu'1.

Tu peux pas, c'est un caractère d'échappement. T'as tapé '\n' dans ta condition, tu devrais percuter pourquoi pour avoir un '\' "réél", la chaîne doit donc contenir '\\'

Tu peux récupérer caractère par caractère via cin si tu veux aussi, (normalement...mais faut pas me demander comment on fait ) hein... Je vois pas trop le but de la manoeuvre là

sisi j'avais percuté la dessus mais je suis pas sur de comprendre vraiment ce que tu me conseils. il faudrait que je tape 2 fois \\ quand je rentre ma chaine de caractere? jimagine que c'est pas ca que tu veux me dire .
là j'ai une idée qui me viens vagument je vais essayer de l'appliquée.  
je debute un peu la prog, j'avais commencé ya qq temps mais j'avais laché, découragé. mais la je crois que je vais m'y mettre au taquet!

C'est cin.get() pour récupérer caractère par caractère.
 
Mais, vu qu'il est en cat C et qu'il fait moit/moit, pourquoi tu lui dis pas de remplacer cout par un puts ou équivalent?

je fais un getchar() pour saisir uniquement les caracteres nécessaires, je sais pas faire d'allocation encore
ok pour le cin.get() je vais voir avec ca alors merci
 
re: mon fichier est en .cpp  a force de mélanger je fais plus gaffe au langage

Ben, les '\' qui rentre dans un programme (c-a-d autre que ceux que tu mets dans le code) sont automatiquement échappés, ce qui fait que tu peux voir un double '\' en debuggant admettons. Mais lorsque tu demandes à ouvrir le fichier à cet emplacement, il ne sera pris en compte que comme un simple '\' puisqu'en fait c'est un seul caractère... (je sais pas si je suis trés clair là )

ok je crois que je te suis IrmatDen. c'est bien en debuggant que j'appercois le double \\. mais la suite de mon prog pour l'instant c'est ca  :

 
bon mon code est confu et pas bien commenté peu etre, mais je verrai ca demain là je suis plus bon à rien, j'ai les snoeil eclatés. je vois ca demain ca vaut mieux  
 
j'ai m^me pas fini ce que je voulais dire: fichier = fopen( "Buffer", "r" ); retroune null alors que mon fichier contient quelque chose. donc c'est bien un probleme d'antislash qui fausse l'adresse.
sinon mon prog sert a rien pour l'instant mon but serra de recup les caracteres du fichier puis de les stockers dans le buffer pour ensuite crypter ces caracteres et les ajouter enfin dans les fichiers. je savais pas quoi faire comme prog, j'ai eu ma dose de calcul et de tri  
 
je vais utiliser puts alors mais c'est juste que je veux m'habituer a la syntaxe c++. J'ai luu des choses pas terrible sur le printf, donc je le zap

non ? (ligne 15)
 
et oui, faut mieux remplacer cout par autre chose (printf, puts...)

quel c'est ridicule ...
 
et fgets ...

faut bien si mettre mon petit Taz, si je loupe le coche sur les bases je progresserai lentement par la suite...je me passerai de ton avis si c'est pour te foutre de moi .
merci quand même pour le fgets je connaissais pas je crois.

t'es déjà perdu à mélanger C et C++ qui sont deux langages distincts.

mais arrête de dire des conneries mon petit Taz, c'est pas l'utilation du cout au lieu du printf et du cin au lieu du scanf qui vont me mettre dans le flou.
J'ai encore du mal à cerner la notion d'objet (ici c++) donc je me contente de la struture du c. une fois que j'aurais compris je passerai au c++.  
et puis quand tu dis que c et c++ sont 2 langages distincts je suis pas d'accord à 100%. Insérer du c quand tu fais du c++ ca pose pas plus de problème que ca je crois, l'inverse n'est pas vrai par contre.
dites moi si je me plante.

Si. La preuve pas plus tard que la phrase suivante :

Tu te plantes. Très simple de créer un programme C qui ne compile pas en C++, et vice-versa. Ce sont deux langages distincts, avec deux philosophies distinctes, et deux bibliothèques de base distinctes (libC pour le C, STL pour le C++).
La grammaire et commune, et le fait que le C++ ait accès à la libC de manière quasi transparente. Ce qui perd le plus les débutants, c'est qu'on peut écrire du simili-C en C++, ce qui est pourri, illisible, le plus souvent bugué, et souvent synonyme de programme à jeter à la poubelle.

Bref, utiliser la libC en C++ ça peut dépanner j'imagine, mais il vaut mieux regarder avant dans la STL ou dans les bibliothèques communes s'il n'y a pas l'équivalent en C++, c'est bien mieux.

C'est pas une question d'être d'accord ou non. C'est un fait, pas une opinion. Il y a 2 documents ISO distincts qui définissent ces langages (C++98 / C05). Le seul sous-ensemble commun garanti par la définition de ces deux langages est la bibliothèque standard du C. C'est tout.

 
Qu'appelles-tu 'insérer' ?

On sait réaliser des projet avec des fichiers sources différents (C, C++, asm), oui (chaque fichier sera compilé avec le compilateur qui va bien). Une fonction écrite en C est capable d'appeler une fonction écrire en C++, oui. Mais 'insérer', je ne vois pas...

Si tu as l'intention de compiler du C avec un compilateur C++, tu commets une grave erreur. Le comportement est indéfini. Point.

http://david.tribble.com/text/cdiffs.htm

(avec Machin un typedef sur char* bien sûr)
 
J'ai vu ça sur un projet d'élève il y a 5min.  
L'avis des élèves qui reprennent ce code :  
"mais c'est dla merde"
 
Je dois en plus les prévenirs que le programme bien qu'il "compile" risque de leur claquer un comportemant pas prévisible ?

Comme je l'ai indiqué, on a le droit d'utiliser en C++ des appels de fonctions C, y compris de la bibliothèque standard du C. Le problème n'est pas là.  
 
Ce qu'il ne faut pas faire, c'est prendre un code écrit en C, réputé conforme au langage C et se dire, je vais le compiler en C++ et ça va marcher. Ben non.
 
Au mieux, ça ne compile pas, au pire, ça compile et le comportement est indéfini.  

ok c'est quand même plus sympa quand les choses sont dites comme ca. je prends note  

 
Non, d'où tu sors ça ? C99 a étendu le préprocesseur. C++98 lui est antérieur (!) et ne l'a pas - la révision de 03 n'y a rien changé. Le seul sous-ensemble commun que je connaisse, c'est la bibliothèque C. Après il y a peut-être deux ou trois choses par ci par là ...
 
 

 
Tout dépend comment tu définis "indéfini"
Le comportement du programme *C++* en résultant, est défini si le programme C en question est aussi un programme C++ valide. Je ne suis pas en train de dire qu'ils donneront le même résultat.

Justement : le résultat n'est pas prévisible par les normes C.

Exact, c'est le préprocesseur du C90 qui est le même que celui de C++98.
 
Je corrige.

Oui, mais quand on écrit du C, on est pas censé connaitre les règles du C++. pour être sûr, il faut être expert dans les 2 langages. Ce n'est pas donné à tout le monde...
 
En plus quel est l'intérêt ?

Oui, mais qui parle d'être expert ?
 

Demander un contrôle des types plus poussé, exploiter la surcharge. C'est ce qui me vient en tête en premier.

Dans ce cas, écrit en C++. Point. Laisse tomber le C, c'est pas grave.

 
(Ce n'était absolument pas mon point, j'essayais de répondre à ta question qui n'en était sans doute pas une, d'ailleurs)
Mon cas personnel - puisque tu as l'air de l'évoquer - est lié au contexte de mon employeur. Arrêtes un peu avec ta rengaine.
 
Et ce n'est peut-être pas ton expérience, mais des équipes compilent leurs logiciels avec un compilateur C, et de temps en temps avec un compilateur C++. Ils y voient des avantages. Une compilation rapide en C, une compilation C++ plus stricte et qui pousse à un meilleur style selon eux.

Oui c'était à la mode pendant un temps suite à l'article 'http://www-sens.sys.es.osaka-u.ac. [...] ter_c.html', mais c'est risqué, car ce sont 2 langages différents :

http://david.tribble.com/text/cdiffs.htm

Cette manip est réservée aux experts des deux langages que nous ne sommes pas.

 
Je ne sais pas si c'est le bon article. ça explique plutôt ce qu'il y a de bon à prendre en C++. Je parlais des quelques avantages qu'il y avait à utiliser un *compilateur* C++ pour compiler du C.
 

Je ne suis pas expert, mais tu m'excusera de m'en sentir capable.

Je m'autoflagelle pour cette imprécision. C++98 inclu uniquement la bibliothèque *C90* par référence.

Ca va leur faire tout drôle à tes équipes le jour où ils déclareront un "int new" dans une fonction C et qu'ils iront le compiler avec un compilo C++ pour affûter leur style...

Et cette incompatibilité présente un danger selon toi ?

Non, car ça ne va pas compiler... Chez moi, c'est encore plus radical. Tous mes sources C
 
http://mapage.noos.fr/emdel/clib.htm
 
commencent par :  

Ben oui, faut pas déconner non plus. C c'est pas C++.

Ce qui est toujours mieux qu'une erreur de compilation sur les conversions void* -> T*...

Sinon - ce n'est pas encore d'actualité - mais pour ce qui est des avantages à compiler du C avec un compilateur C++, on peut prévoir que les variadic templates seront finalisées dans C++0X, et permettront une implémentation type-safe des fonctions variadic de la bibliothèque C.