Salut,
Quel est l’intérêt d’utiliser readfile (API) plutôt que fread (AINSI-C) ?
NB : je développe, uniquement, sur Windows XP.
Version imprimable
Salut,
Quel est l’intérêt d’utiliser readfile (API) plutôt que fread (AINSI-C) ?
NB : je développe, uniquement, sur Windows XP.
Tu t'assures que ton programme ne compilera que sous Windows :)Citation:
Envoyé par valentine74
donc aucun avantage du readfile (window only) par rapport au fread (toute plateforme) ???!!!!
Je peux donc continuer à utiler (sans complexe) les FILE *fout et fwrite (même sur windows )
cool !
Ben oui :)
Plus c'est portable, mieux c'est ;)
Ben non, n'importe quoiCitation:
Envoyé par Pouic
Quand je fais un programme pour Windows, j'utilise seulement les API. Avec elles tu controles mieux ce que tu fais, notamment avec les fichier. Par exemple, CreateFile a plus d'options que fopen.
Et fread c'est de l'ANSI, pas de l'AINSI :mouarf:
Si tu ne fais que le programmation Windows, tu fais ce que tu veux. Pour tous les autres qui doivent faire tourner des programmes sous Unix, Linux, VMS, etc., on programme portable...Citation:
Envoyé par socrate
Nous ne savons pas si valentine74 a besoin d'avoir quelque chose de portable.
A priori non, mais cette bonne vieille fread() fait bien le boulot, non? Et il ne faut jamais dire qu'on ne portera pas un programme.Citation:
Envoyé par socrate
Tu as d'un côté une fonction portable, qui offre les fonctionnalités demandées par le PO ; et de l'autre, une fonction système-dépendant, pour faire ce que l'autre fait.Citation:
Envoyé par socrate
Le choix est vite vu : il faudrait avoir une poutre dans l'oeil et une sacré mauvaise foi pour dire qu'il faudrait choisir la fonction système-dépendant.
Evidemment, s'il s'agit de programmation système, nécessitant des options spécifiques, on en rediscute. Mais au vu de la question du PO (ie quant à la pertinence de la fonction à utiliser), ça m'étonnerait : le choix d'une solution portable reste donc celle à choisir.
Si tu le dis...
Quand on fait une application qui va tourner seulement sous Windows (ce qui est vrai dans la majorité des cas me semble-t-il), c'est nul d'utiliser fopen. Je vois pas pourquoi tu décides que la portabilité c'est important
Pourquoi ?Citation:
Envoyé par socrate
Parce qu'il existe d'autres systèmes.
Quand je développe une application pour une plate-forme embarquée, je ne m'amuse pas à tout recoder quand ladite plate-forme évolue.
Quand un outil qu'on développe doit au moins tourner sur les 3 systèmes grand public (Linux, Mac OSX, Windows) , je ne m'amuse pas à tout recoder.
Quand je reprend un code déjà existant pour le faire tourner sur une plate-forme différente, j'apprécie que le codeur précedent ait fait son code de façon portable afin de réduire le coût humain/financier inhérent à un refactoring.
Donc non, Windows n'est pas le seul système ; et une application faite pour Windows peut interesser des gens n'utilisant pas ce système.
A partir de là, une solution portable est la meilleure pour la pérénité d'une application, ainsi que pour ceux qui auront à la faire évoluer (développeur, entreprise) : tout le monde y gagne.
Tu m'a carrément cloué le bec
J'espère surtout t'avoir sensibilisé au problème de la portabilité... :)Citation:
Envoyé par socrate
Afin que tu réfléchisses aux conséquences qu'impliquent des réflexions comme celle que tu as faite ;)
(mon intérêt n'est pas de clouer le bec de gens, loin de là : je ne serai pas sur ce forum sinon... :))
Nous avons un goret de Force 5 !Citation:
Envoyé par socrate
http://emmanuel-delahaye.developpez.com/goret.htm
Citation:
Utilisation de fonctions systèmes alors qu'il existe des fonctions standards qui font le même travail
Ne t'inquiète pas, je suis un authentique Force 10. En effet j'utilise parfois le goto, et souvent des variables globales publiques modifiables
Ma foi, quand je code c'est pour moi et pas pour les autres, donc je respecte mes méthodes
Je ne suis pas un force 9 car je n'utilise pas malloc (ben oui, c'est standard), mais HeapAlloc ou VirtualAlloc
Pour être sérieux, j'approuve pas ton échelle de goret. Quelques exemples que je ne comprends pas:
switch de plus de 20 case
cacher les pointeurs (c'est quand même un peu obligatoire des fois)
Absence de prototypes (a quoi ca sert de les mettre systématiquement)
Plus d'un return par fonction 8O
Utilisation abusive de la récursion
Bref, j'ai pas les mêmes points de vue que vous partout, c'est pas une raison de me traiter de goret
PS: à ta place je mettrais pas d'icone W3C quand la page web n'est pas valide :mouarf: A moins que ce soit la foirce 11 et que tu ais oublié de l'écrire?
No excuse....:oops: :oops: :oops: (Corrigé).Citation:
Envoyé par socrate
Pour revenir au pb de départ:
Par exemple un fopen échoue. Comment savoir pour quelle raison il a échoué (fichier n'existe pas, déja utilisé, pas les droits...)
En fait, je trouve que les fonctions standard sont trop vagues (ce qui est normal)
perror()Citation:
Envoyé par socrate
Bon ben je suis un force 5 alors, mais je le resterai ;)
Le seul interet de ReadFile c'est le partage de fichiers entre application. Mais c'est très très rarement utile. Donc à n'utiliser que en cas de (grande) necessité.
http://www.developpez.net/forums/sho...d.php?t=148427
CreateFile() permet aussi de régler les attributs du fichier (lecture seule, archive), d'optimiser la lecture du fichier (random access, sequential), de garder un fichier dit temporaire en mémoire, de supprimer le fichier automatiquement après fermeture, de lire le fichier en mode non-bloquant... Et accessoirement, de donner directement une ACL au fichier (peu utilisé).
Bref, pas mal de chose qu'un fopen() ne peut pas faire...
Encore que, en lecture, pas mal de ces fonctions deviennent inutilisables.