Problème avec l'ouverture totale de certains fichiers!
ndubien
Messages postés557Date d'inscriptiondimanche 25 septembre 2005StatutMembreDernière intervention10 mai 2014
-
21 févr. 2007 à 12:13
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 2014
-
21 févr. 2007 à 22:44
Bonjour,
J'ai un problème avec l'une de mes fonctions, cette derniere est censée ouvrir tous les fichiers du début à la fin mais lorsqu'elle rencontre le caractère ascii n°26, la fonction s'arrête d'ouvrir le fichier comme si elle se trouvait à la fin de ce dernier et renvoi seulement un morceau du fichier et non le fichier global.
Ma fonction :
void ouvrir(string &phrase) {
cout <<"\n\nNom du fichier a analyser : ";
string nom_fichier;
getline(cin,nom_fichier);
ifstream fichier(nom_fichier.c_str());
if (!fichier) {
cout <<"Erreur, fichier corrompu ou inexistant !\n\n";
phrase = "Erreur, fichier corrompu ou inexistant !";
} else {
stringstream buffer;
buffer << fichier.rdbuf();
fichier.close();
phrase = buffer.str();
}
}
Pouvez-vous me proposer une fonction semblable mais qui ne s'arrête pas lorsqu'elle rencontre le caractère ascii n°26 (en c++ console win32) ?
Merci d'avance et à bientôt.
Nico
A voir également:
Problème avec l'ouverture totale de certains fichiers!
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 21 févr. 2007 à 13:48
Salut,
Sous Windows, il est toujours préférable d'utiliser les APIs faites pour cela.
CreateFile()
ReadFile()
WriteFile()
CloseHandle()
Aucun problème avec caractère ascii 26 ou autre.
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 21 févr. 2007 à 14:46
turnerom >> SI. Si on code pour Windows il faut penser Windows. On gagne beaucoup en éfficacité. Les APIs permettent de profiter des nombreuses fonctionnalités de Windows. Les fonctions de la CRT les ignore pour raison de portabilité du code. Rien qu'avec la gestion des fichiers, on voit bien la différence.
turnerom
Messages postés492Date d'inscriptionsamedi 10 juillet 2004StatutMembreDernière intervention12 janvier 20121 21 févr. 2007 à 14:48
Oui mais si on code C++, comme ca a l'air de vouloir etre le cas, il faut coder en C++.
Les fonctions CreateFile(), ReadFile(), WriteFile(), CloseHandle(), ... ne sont pas des fonctions du standard C++ mais du standard Windows
Vous n’avez pas trouvé la réponse que vous recherchez ?
turnerom
Messages postés492Date d'inscriptionsamedi 10 juillet 2004StatutMembreDernière intervention12 janvier 20121 21 févr. 2007 à 19:26
bah !!!
La ou je bosse, on ne travail qu'avec de C++ standard, de telle sorte que nos prog compile indiférement sous Win/Linux/Mac. Y'a pas que visual studio dans la vie (que l'on a d'ailleurs banni de chez nous)
cs_vicenzo
Messages postés178Date d'inscriptionmardi 16 août 2005StatutMembreDernière intervention25 août 20101 21 févr. 2007 à 19:38
Racpp => Pas d'accord du tout sur ta position extrémiste !
BruNews => C'est grace à la portabilité du C/C++ que je ne suis pas au chomage !!
Sans entrer dans un débat stérile sur le sujet du choix des api et librairies, il faut nuancer !
Oui, la progammation Windows a son intérêt et ses avantages et en fonction des projets et préférable à du code portable !
Mais, y pas que Windows sur terre, et que lorsqu'on bosse sur des gros
projets réseaux, DB, Serveurs, ... a moins d'être masochistes à faire
XYZ fois le boulot (un pour windows, un pour unix, ), faut faire du
portable..
Pourquoi Java, FireFox, APache (APR, WEB, Tomcat, ...), Oracle, MySql,
..... existe-ils et pourquoi sont ils populaires ?? Parce qu'ils sont
portables et minimisent le code spécifiqe à chaque machine.
Mes projet professionnels inpliquent des applications graphiques faites
en API Win32. D'autres en c pour des interfaces portables (MS et Unix)
temps réel entre gros systémes ...
Faut pas dire , Sur Windows fait automatiquement du win32.. Surtout à
un jeune de 15 ans ... Pour une application console qui ne fait pas
grand chose, pourquoi pas du C ou du c++ pur ??
Et enfin pour Racpp, pour info, les fonction standard C et C++ de
manipulation de fichiers utilise l'api win32 sous Windows (fopen ->
OpenFile(), ....), c'est obligé !
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 21 févr. 2007 à 20:36
turnerom >> Rien n'empêche d'utiliser les APIs Windows en C++. Le code ne sera certes pas portable si on pense aux autres OS. Windows représente plus de 90% dans le monde donc...Si vous ne faites que du portable, ce sera dommage pour les applications car elles ne profiteront pas des fonctionnalités spécifiques à chaque OS.
visenzo >> Ma position est plutôt réaliste. C'est vrai que les fonctions standard finiront toujours par utiliser les fonctions du système hôte. Mais là justement il y'a une grande différence. Si fopen() appelle OpenFile() alors se serait vraiment dommage car elle devrait appeler CreateFile(). Cette dernière corrige les limitations de OpenFile(). Par exemple avec OpenFile() le chemin ne doit pas dépasser 128 caractères. Quand on regarde CreateFile() de près, on voit bien qu'elle dépasse, et de loin, fopen(). Le nombre de paramètres et les combinaisons des differents flags permettent, justement, de profiter de tout ce que nous offre le système. Il suffit de comparer pour en avoir le coeur net:
CreateFile() fopen()
cs_vicenzo
Messages postés178Date d'inscriptionmardi 16 août 2005StatutMembreDernière intervention25 août 20101 21 févr. 2007 à 21:18
Racpp,
Bien sur que sous windows, CreateFile sera plus rapide, plus souple......(+ tout que tu veux) que fopen par exemple. Si tu utilise une primitive d'ouverture de fichier pour ouvrir des fichiers dans ton appli de temps temps (fichier conf, ....) quel est l'intérêt de gagner quelques cycles cpu en passant par la version window ? Aucun.
Maintenant si ton appli ne tournera jamais sur une machine mac, linux, unix, système embarqué, ...et qu'elle passe son temps a gérer des fichiers (ouverture, E/S, fermeture) dans les cas d'analyse de mails, logs, data, ... La, Ok CreateFile and Co ont tous leur sens... Donc en fonction du contexte tu choisis le plus utile.
Tu crois que les codeurs d'Apache et FireFox par exemple font du Win32 ? Non et pourtant apache est le serveur web le plus répandu et firefox un ou le meilleur+ rapide browser... Tout le code applicatif est 300 % portable sur des dizaines d'OS... Grace à des librairies (APR pour apache et NLS pour FF) d'abstraction de la couche OS et pourtant ils sont performants.
Je fais du Win32 tous les jours au boulot mais aussi du code portable windows / unix aussi. Par exemple, j'ai des lib de gestion de fichier de conf, de socket, fichier, http, .. que j'utilise sous windows et unix. Et j'ai pas a écrire 2 foix le même code !!!
Bref, il faut relativiser : de la perf quant c'est nécessaire -> api os et sinon du portable si possible...
Mais bien sur, si tu n'a connu que windows et ne connaitra que windows, je parle dans le vide....
Mais dans la réalité du monde professionnel, y pas que win32, il y a aussi java, c# qui ont été pensés entre pour se défaire des apis des OS.
Quand tu utilise une primitive Java ou C# sous windows, ce fait un openfile ou createfile et sous linux ca fait un fopen...
La tendance générale (java, .NET) va dans ce sens....
Microsoft enrougage tout le monde a faire du .NET ? Pourquoi ? Parce que entre autre, ils veulent de débarasser de win32 dont les bases remontent à win16 de windows 3.1.
Aujourd'hui, .NET sur une machine microsoft est une grosse surcouche de Win32.
Dans quelques années, (minimum 10 ans) , Tonton Bill sortira un Windows dont le coeur ne sera plus Win32 mais pourra émuler les "vielles applis Win32..."
Bon, y a mamie qui m'appelle pour que je n'oublie pas ma tisane !
racpp
Messages postés1909Date d'inscriptionvendredi 18 juin 2004StatutModérateurDernière intervention14 novembre 201417 21 févr. 2007 à 22:44
Je ne parlais pas seulement des performances. Je suis convaincu que si FireFox (et les autres) était conçu séparément pour chaque OS, il aurait été encore meilleur. Une lib assurant la portabilité néglige les spécificités de chaque OS pour ne garder que le tronc commun. Je n'ai pas besoin de développer pour les autres OS pour m'en apercevoir. Rien qu'en utilisant une lib de portabilité sur Windows, je sais bien ce que je perds.
Quant à JAVA et .NET, c'est une autre histoire. L'exécutable n'est pas natif car il aura toujours besoin de la machine virtuelle JAVA ou du FrameWork .NET. Adieu les performances...
Déjà avec les APIs, on comprend bien le fonctionnement du système. Pour moi, c'est essentiel car cela aide beaucoup dans la conception des applications.