IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

SL & STL C++ Discussion :

déçu par fstream


Sujet :

SL & STL C++

  1. #1
    Inactif  

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    534
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 534
    Par défaut déçu par fstream
    Bonjour,

    Je suis surpris que fstream ait été conçu selon une amputation des possibilités du FILE * de stdio.h du C.

    Les fonctions de fstream ne renvoient aucune information, par ex read, write alors que ces mêmes actions en C renvoient de l' information fread, fwrite...

    De même dans l' "ancien C++" , on pouvait retrouver le handle du fstream avec :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    int getHandle( fstream& s ) { return s.rdbuf()->fd() ; }
    qui est devenue impossible.

    La question est pourquoi une telle implémentation restrictive des fichiers ?

    En consultant le code source de QFile de QT , il apparaît bien que le fichier est FILE * pas fstream.

    On dirait que fstream a été inventé, mais que dans la pratique tout le monde préfère les FILE * du C ...

    Salut.

  2. #2
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2004
    Messages
    5 463
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2004
    Messages : 5 463
    Par défaut
    Alors, déjà, c'est pas vrai, je n'ai jamais rien compris aux FILE*, donc je leur préfère les stream. Les streams sont extensibles, tant en terme de sources de données (y compris par chaînage) que de données à écrire, ce que les FILE* ne sont pas...

    Retourver un handle de fstream obligerait à baser l'implémentation des fstream sur ces handle. Ca pourrait être contre performant. Je ne sais même pas quel est ce handle int que retournait ce fd. S'agissait-il d'un FILE*, d'un handle spécifique à un os ? D'autre chose ? Pour info, il est courant qu'il y ait des extentions aux streams spécifiques à un OS pour obtenir un descripteur de fichier compatible avec cet OS.

    Autrement, que voulais tu faire avec les valeurs de retour de read et write ? Peut-être que read_some peut répondre à ton attente ? Sinon, peux-tu détailler ton besoin ?
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  3. #3
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Je suis surpris que fstream ait été conçu selon une amputation des possibilités du FILE * de stdio.h du C.
    Au contraire, ça fait beaucoup plus de choses.

    Les fonctions de fstream ne renvoient aucune information, par ex read, write alors que ces mêmes actions en C renvoient de l' information fread, fwrite...
    Hmmm? Ce que tu dis est incompréhensible.
    Ça te plait pas que getc prenne son paramètre par référence plutôt que de retourner une valeur de retour ? Cela a une raison simple, qui résout certains problèmes plus élégament que l'équivalent C.

    De même dans l' "ancien C++" , on pouvait retrouver le handle du fstream avec :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    int getHandle( fstream& s ) { return s.rdbuf()->fd() ; }
    qui est devenue impossible.
    Cela retourne le fd. Ce qui est l'implémentation bas niveau de tous les flux sous les unix-like. Rien à voir avec FILE*.
    Et des choses de ce genre existent en tant qu'extensions sur quasiment toutes les implémentations...

    En consultant le code source de QFile de QT , il apparaît bien que le fichier est FILE * pas fstream.

    On dirait que fstream a été inventé, mais que dans la pratique tout le monde préfère les FILE * du C ...
    Tout le monde n'est pas Qt.
    Qt n'utilise pas vraiment la bibliothèque standard du tout, et ne se met que progressivement à utiliser quelques outils du C++ moderne.
    Bref, c'est pas un exemple de trucs à faire.

  4. #4
    Inactif  

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    534
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 534
    Par défaut
    Bonjour,
    Je ne comprends pas ces réponses de convertis.
    fstream::read, ou write ne renvoient aucun résultat, alors que fread et fwrite donnent de l' info par retour.

    Il faudrait sans doûte être nigaud pour ne pas s' apercevoir de la différence...

    Et voilà que l' on justifie en plus que l' attribution d' un hande de fstream, pourrait fatiguer le procésseur...
    La fonction
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    int getHandle( fstream& s ) { return s.rdbuf()->fd() ; }
    est devenue impossible !!!

    Le fstream paraît comme une convenience pour ceux qui entendent gérer des flux naîfs.

    De manière générique, le FILE * du C reste la méthode la plus performante pour gérer des fichiers.

    Pour exemple, ne serait-ce qu' un seul, QFile de Qt...
    Et d' autres exemples vont tomber comme de la pluie ?

    Salut.

  5. #5
    Membre éprouvé
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    90
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2006
    Messages : 90
    Par défaut Dans fstream il y a f et il y a stream
    Les fonctions de fstream ne renvoient aucune information
    C'est faux : la valeur de retour de istream::read() (ou ostream::write()) permet de détecter s'il y a une erreur et de chaîner les appels en cas de succès (l'intérêt du chaînage est plus clair pour les entrées/sorties formatées).

    istream::gcount() permet d'obtenir le nombre d'octets lus par la dernière fonction de lecture non formatée (istream::read(), istream::get(), ...).

    istream::readsome() retourne le nombre de caractères lus.

    streambuf::sgetn() (resp streambuf::sputn()) retourne le nombre de données lues (resp écrites).

    Le fstream paraît comme une convenience pour ceux qui entendent gérer des flux naîfs.
    Les opérateurs associés aux streams privilégient effectivement les entrées/sorties formatées (sur du texte), mais il est toujours possible de surcharger ces opérateurs pour faire ce qu'on veut (entrées/sorties "typées" sur des données binaires).

    Les streams ont une syntaxe générique (il n'y a pas que les fstreams...).

    QFile propose plusieurs méthodes de manipulation de fichiers (rename(), setPermissions(), ...) ; les fstreams ne permettent que de créer un fichier.

    Mon avis en bref :
    • Les streams sont pratiques (code lisible et facile à écrire) pour gérer les flux de données formatées
    • Dans l'état actuel du standard C++, les bibliothèques spécialisées ont l'apanage des manipulations de fichiers

  6. #6
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Citation Envoyé par dj.motte
    Je suis surpris que fstream ait été conçu selon une amputation des possibilités du FILE * de stdio.h du C.
    Comme par exemple la possibilité d'avoir des crashs quand on se trompe de type?

    Les fonctions de fstream ne renvoient aucune information, par ex read, write alors que ces mêmes actions en C renvoient de l' information fread, fwrite...
    read et write sont en effet rarement utiles. Les iostream ce n'est pas l'interface pour faire des IO binaires. L'interface c'est les bufstream qui ont sgetn et sputn qui devraient mieux te convenir.

    De même dans l' "ancien C++" , on pouvait retrouver le handle du fstream avec :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    int getHandle( fstream& s ) { return s.rdbuf()->fd() ; }
    fd() n'a à ma connaissance jamais été universellement disponible. Et l'équivalent n'est pas non plus disponible en C standard (POSIX le fournit, mais POSIX ne fournit rien pour le C++). Il n'y a pas de notion de handle de fichier en C++, c'est donc difficile de fournir une interface d'accès.

  7. #7
    Expert confirmé

    Homme Profil pro
    pdg
    Inscrit en
    Juin 2003
    Messages
    5 756
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : pdg

    Informations forums :
    Inscription : Juin 2003
    Messages : 5 756
    Billets dans le blog
    3
    Par défaut
    Compare ce code C++:
    http://c.developpez.com/faq/cpp/?pag...ture_par_ligne
    avec un équivalent en C. Tu verras que les stream sont plus élégants, sûr et faciles d'emploi, sans utiliser read, write ou un file descriptor.

  8. #8
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    Je ne comprends pas ces réponses de convertis.
    Et moi je ne comprends pas pourquoi tu redis la même chose alors qu'on t'a déjà expliqué tous les points.

  9. #9
    Inactif  

    Profil pro
    Inscrit en
    Décembre 2002
    Messages
    534
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2002
    Messages : 534
    Par défaut
    Bonjour,

    Merçi pour vos réponses, mais ne soyez pas trop véhément avec moi car je suis un âne.

    Lorsque que l' on me dit que les handle de fichiers, ce n' est plus à la mode, je me pose la question du moins avec linux.
    Exemple dans stdio_filebuf.h
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    126
    127
    128
    129
    130
    131
    132
    133
    134
    135
    136
    137
    138
    139
    140
    141
    142
    143
    144
    145
    146
    147
    148
    149
    150
    151
    152
    153
    154
    155
    156
    157
    158
    159
    160
    161
    162
    163
    164
    165
    166
    167
    168
    169
     
    / File descriptor layer for filebuf -*- C++ -*-
     
    // Copyright (C) 2002 Free Software Foundation, Inc.
    //
    // This file is part of the GNU ISO C++ Library.  This library is free
    // software; you can redistribute it and/or modify it under the
    // terms of the GNU General Public License as published by the
    // Free Software Foundation; either version 2, or (at your option)
    // any later version.
     
    // This library is distributed in the hope that it will be useful,
    // but WITHOUT ANY WARRANTY; without even the implied warranty of
    // MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    // GNU General Public License for more details.
     
    // You should have received a copy of the GNU General Public License along
    // with this library; see the file COPYING.  If not, write to the Free
    // Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
    // USA.
     
    // As a special exception, you may use this file as part of a free software
    // library without restriction.  Specifically, if other files instantiate
    // templates or use macros or inline functions from this file, or you compile
    // this file and link it with other files to produce an executable, this
    // file does not by itself cause the resulting executable to be covered by
    // the GNU General Public License.  This exception does not however
    // invalidate any other reasons why the executable file might be covered by
    // the GNU General Public License.
     
    /** @file ext/stdio_filebuf.h
     *  This file is a GNU extension to the Standard C++ Library.
     */
     
    #ifndef _EXT_STDIO_FILEBUF
    #define _EXT_STDIO_FILEBUF
     
    #pragma GCC system_header
    #include <fstream>
     
    namespace __gnu_cxx
    {
      /**
       *  @class stdio_filebuf ext/stdio_filebuf.h <ext/stdio_filebuf.h>
       *  @brief Provides a layer of compatibility for C/POSIX.
       *
       *  This GNU extension provides extensions for working with standard C
       *  FILE*'s and POSIX file descriptors.  It must be instantiated by the
       *  user with the type of character used in the file stream, e.g.,
       *  stdio_filebuf<char>.
      */
      template<typename _CharT, typename _Traits = std::char_traits<_CharT> >
        class stdio_filebuf : public std::basic_filebuf<_CharT, _Traits>
        {
        public:
          // Types:
          typedef _CharT                     	        char_type;
          typedef _Traits                    	        traits_type;
          typedef typename traits_type::int_type 		int_type;
          typedef typename traits_type::pos_type 		pos_type;
          typedef typename traits_type::off_type 		off_type;
     
        protected:
          // Stack-based buffer for unbuffered input.
          char_type			_M_unbuf[4];
     
        public:
          /**
           *  @param  fd  An open file descriptor.
           *  @param  mode  Same meaning as in a standard filebuf.
           *  @param  del  Whether to close the file on destruction.
           *  @param  size  Optimal or preferred size of internal buffer, in bytes.
           *
           *  This constructor associates a file stream buffer with an open
           *  POSIX file descriptor.  Iff @a del is true, then the associated
           *  file will be closed when the stdio_filebuf is closed/destroyed.
          */
          stdio_filebuf(int __fd, std::ios_base::openmode __mode, bool __del,
    		    int_type __size);
     
          /**
           *  @param  f  An open @c FILE*.
           *  @param  mode  Same meaning as in a standard filebuf.
           *  @param  size  Optimal or preferred size of internal buffer, in bytes.
           *                Defaults to system's @c BUFSIZ.
           *
           *  This constructor associates a file stream buffer with an open
           *  C @c FILE*.  The @c FILE* will not be automatically closed when the
           *  stdio_filebuf is closed/destroyed.
          */
          stdio_filebuf(std::__c_file* __f, std::ios_base::openmode __mode, 
    		    int_type __size = static_cast<int_type>(BUFSIZ));
     
          /**
           *  Possibly closes the external data stream, in the case of the file
           *  descriptor constructor and @c del @c == @c true.
          */
          virtual
          ~stdio_filebuf();
     
          /**
           *  @return  The underlying file descriptor.
           *
           *  Once associated with an external data stream, this function can be
           *  used to access the underlying POSIX file descriptor.  Note that
           *  there is no way for the library to track what you do with the
           *  descriptor, so be careful.
          */
          int
          fd()
          { return _M_file.fd(); }
        };
     
      template<typename _CharT, typename _Traits>
        stdio_filebuf<_CharT, _Traits>::~stdio_filebuf()
        { }
     
      template<typename _CharT, typename _Traits>
        stdio_filebuf<_CharT, _Traits>::
        stdio_filebuf(int __fd, std::ios_base::openmode __mode, bool __del,
    		  int_type __size)
        {
          _M_file.sys_open(__fd, __mode, __del);
          if (this->is_open())
    	{
    	  _M_mode = __mode;
    	  if (__size > 0 && __size < 4)
    	    {
    	      // Specify unbuffered.
    	      _M_buf = _M_unbuf;
    	      _M_buf_size = __size;
    	      _M_buf_size_opt = 0;
    	    }
    	  else
    	    {
    	      _M_buf_size_opt = __size;
    	      _M_allocate_internal_buffer();
    	    }
    	  _M_set_indeterminate();
    	}
        }
     
      template<typename _CharT, typename _Traits>
        stdio_filebuf<_CharT, _Traits>::
        stdio_filebuf(std::__c_file* __f, std::ios_base::openmode __mode, 
    		  int_type __size)
        {
          _M_file.sys_open(__f, __mode);
          if (this->is_open())
    	{
    	  _M_mode = __mode;
    	  if (__size > 0 && __size < 4)
    	    {
    	      // Specify unbuffered.
    	      _M_buf = _M_unbuf;
    	      _M_buf_size = __size;
    	      _M_buf_size_opt = 0;
    	    }
    	  else
    	    {
    	      _M_buf_size_opt = __size;
    	      _M_allocate_internal_buffer();
    	    }
    	  _M_set_indeterminate();
    	}
        }
    } // namespace __gnu_cxx
     
    #endif /* _EXT_STDIO_FILEBUF */
    Apparement C++ flirt avec le C , mais en cachète.
    A vrai dire C++ n' est qu' une version intellectuelle de rendre le C plus agréable dans la communication homme / machine .
    Mais je me demande si finalement dans cette art de la clarification, on y n' y réintroduit pas de complexités.

    On arrive à cette situation que je redoutais, où plus c' est clair, plus c' est complexe.

    Ce n' est pas pour faire de la philosophie de bazard que je l' affirme, mais aprés avoir étudié une multitude de langages.

    Ne m' en veuillez-pas si ces propos ne relèvent pas du pré-fabriqué spontanné.

    Cordialement.

  10. #10
    Expert confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Décembre 2003
    Messages
    3 549
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Décembre 2003
    Messages : 3 549
    Par défaut
    En quoi c'est en caché ?
    Le but de cette extension que propose GCC et justement de constuire un streambuf (l'un des concepts des iostreams) à partir des entrées/sorties standard du C, ce qui peut être utile pour une raison X ou Y pour une interaction entre des codes qui utilisent les deux.
    Ce qui est clairement dit en commentaire.

    Lorsque que l' on me dit que les handle de fichiers, ce n' est plus à la mode
    Mais c'est quoi encore ces conneries ?

    A vrai dire C++ n' est qu' une version intellectuelle de rendre le C plus agréable dans la communication homme / machine .
    Mais je me demande si finalement dans cette art de la clarification, on y n' y réintroduit pas de complexités.
    Tu peux voir tous les langages de programmation comme une version intellectuelle de l'assembleur si ça te chante.
    Et bien sûr, pour simplifier la programmation, la flexibilité, la maintenabilité etc. il faut introduire des mécanismes plus sophistiqués.
    L'assembleur ou le C, c'est simpliste, mais assez chiant à utiliser (surtout l'assembleur). Le C++, c'est compliqué, mais bien plus agréable.

  11. #11
    Expert confirmé

    Inscrit en
    Novembre 2005
    Messages
    5 145
    Détails du profil
    Informations forums :
    Inscription : Novembre 2005
    Messages : 5 145
    Par défaut
    Citation Envoyé par dj.motte
    Lorsque que l' on me dit que les handle de fichiers, ce n' est plus à la mode,
    On ne t'a pas dis que ce n'était plus à la mode, on t'a dit que ce n'était pas une interface définie par le C++ ni par le C d'ailleurs. C'est une interface définie par certains OS.

Discussions similaires

  1. Réponses: 29
    Dernier message: 14/01/2013, 10h40
  2. tutoriel : La programmation de l'API Windows en C++ par Bob
    Par Aurelien.Regat-Barrel dans le forum Windows
    Réponses: 19
    Dernier message: 21/06/2008, 14h34
  3. [TImage] Transfert de Picture par pixels.
    Par H2D dans le forum Langage
    Réponses: 9
    Dernier message: 25/10/2003, 14h37
  4. Affichage en passant par un buffer...
    Par Sirotilc dans le forum MFC
    Réponses: 5
    Dernier message: 27/05/2002, 21h00

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo