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

 C++ Discussion :

au sujet de l'intérêt des bonnes pratiques


Sujet :

C++

  1. #1
    Invité
    Invité(e)
    Par défaut au sujet de l'intérêt des bonnes pratiques
    Cette réponse dérive du la discussion " Problème lecture d'un fichier de 500 Ko
    Citation Envoyé par koala01 Voir le message
    Mais, par pitié, sur le forum C++, la première chose à faire, c'est de veiller à donner des solutions C++...

    Cela signifie que dés que l'on remarque FILE, fread, fwrite, fopen, fclose ou même char* (plus toutes les choses auxquelles je ne pense pas), il faut tirer un signal d'alarme et bien faire comprendre à la personne qu'il travaille en C.
    Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

    Quant à char*, quelle drôle d'idée!

    FILE appartient au C++, tout comme "football" est un mot français d'origine anglaise. L'utiliser pour lire des fichiers, c'est sans doute pas très standard (comme on parle un français "non standard" dans plein de régions du monde), mais de là à "tirer un signal d'alarme"?

    Ca me rappelle ces parisiens qui se moquent des marseillais, ou des québecois, parce qu'ils trouvent qu'ils parlent mal français.

    (Et non, je n'utilise pas FILE, je préfère les fstream, et oui je suis parisien).

    Citation Envoyé par koala01 Voir le message
    D'un coté, tu utilises un fichier dont l'extension est en *.txt, ce qui fait penser que tu utilise un fichier considéré comme étant un fichier contenant... du texte (des chaines de caractères, en fait), et de l'autre, tu ouvre ton fichier en mode "binaire", ce qui fait penser que tu souhaite gérer le contenu du fichier comme ... des données brutes...
    Mode binaire ou mode texte, ca dépend essentiellement de la façon dont les fichiers sont structurés, pas des données qu'ils contiennent ou de leur utilisation future (et encore moins de leur extension).

    En mode texte, on s'attend à voir des lignes de longueur variables, séparées par des retours à la ligne, et parfois des séparateurs intermédiaires. On lit ligne à ligne (ou champ à champ) sans se préoccupper de la position où l'on se trouve, et on fait en général des getline, qui lisent jusqu'au prochain délimiteur. A chaque lecture, ces délimiteurs sont supprimés: l'utilisateur n'y a jamais accès.

    En mode binaire, on doit spécifier, à chaque lecture, le nombre d'octets qu'on lit. Ceci est donc adapté à des fichiers où les champs ou les enregistrements sont de longueur fixe (mais qui peuvent parfaitement contenir des chaines de texte). Et on utilisera alors des read. Ces positions fixes permettront également plus facilement de se déplacer dans le fichier sans le lire avec des seekg par exemple.

    Le choix entre mode texte et mode binaire ne dépend pas de la nature ou de l'utilisation qu'on va faire des données, mais seulement de la façon dont elles sont organisées dans le fichier. Un grand nombre de fichiers textes sont formattés "en ASCII colonné", et se lisent en mode binaire.

    En pratique, la lecture en more binaire est toujours plus rapide que le mode texte: un read n'a pas besoin de contrôler la présence de délimiteurs, on peut allouer ses tailles de structures unitaires de lecture à l'avance, etc...

    Et, une fois de plus, ca n'a pas grand chose à voir avec le C: on fera en C++.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    ifstream fdat.open("mon_fichier.txt",ios::binary);
    Francois
    Dernière modification par Invité ; 21/05/2009 à 14h46.

  2. #2
    Membre averti
    Profil pro
    professeur des universités à la retraite
    Inscrit en
    Août 2008
    Messages
    364
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : professeur des universités à la retraite

    Informations forums :
    Inscription : Août 2008
    Messages : 364
    Points : 439
    Points
    439
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

    Quant à char*, quelle drôle d'idée!
    D'autres que moi, plus expérimentés, répondront sans doute de façon plus élaborée et argumentée. Cela dit, il me semble que tu fais complètement fausse route : si les outils du C sont disponibles en C++ c'est avant tout pour permettre une compatibilité avec du code antérieur existant et en aucune façon parce que cela serait recommandé ou souhaitable de les utiliser dans des programmes nouveaux lorsque ce n'est pas indispensable pour une raison bien précise.
    Quant aux pointeurs et tableaux, ils constituent une des difficultés et sources d'erreur majeure du C et un des avantages du C++ c'est de permettre de les éviter dans un grand nombre de cas et de construire ainsi du code plus lisible, plus facile à maintenir et moins 'error-prone', ce qui est un des objectifs majeurs du C++

  3. #3
    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 : 49
    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
    Points : 16 213
    Points
    16 213
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...
    L'idée n'est pas de dire que ce n'est pas standard, mais de dire que si le but est de faire du C++, il y a des alternatives supérieures.
    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.

  4. #4
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut au sujet de l'intérêt des bonnes pratiques
    Cette discussion a été ouverte comme digression de la question portant sur la lecture de fichier

    message original
    Citation Envoyé par fcharton Voir le message
    Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

    Quant à char*, quelle drôle d'idée!
    Le fait est que, venant du C, on a vite fait d'assimiler un char* à... une chaine de caractères (comprend: de caractères "imprimables", composée d'un tableau de caractères terminé par '\0')

    Je veux pour preuve de cette affirmation la toute récente discussion tableau d'element hexa tronqué qui n'est qu'une illustration supplémentaire (le problème se pose très régulièrement) de la confusion si facile à faire en C
    FILE appartient au C++, tout comme "football" est un mot français d'origine anglaise. L'utiliser pour lire des fichiers, c'est sans doute pas très standard (comme on parle un français "non standard" dans plein de régions du monde), mais de là à "tirer un signal d'alarme"?

    Ca me rappelle ces parisiens qui se moquent des marseillais, ou des québecois, parce qu'ils trouvent qu'ils parlent mal français.
    Il ne s'agit pas de dénigrer le C, qui est un langage que j'utilise moi même souvent, mais simplement d'attirer l'attention aussi souvent que possible sur le fait que:
    • oui, C++ hérite du C, et propose, de ce fait, toute la palette des possibilités issue du C mais
    • non, il ne faut pas considérer C++ comme "du C avec des classes" ( C with classes)
    • il est possible de trouver une possibilité propre à C++ qui sera généralement bien plus simple, sécurisante et facile à lire à l'ensemble pour quasi la totalité des possibilités issues du C
    Mode binaire ou mode texte, ca dépend essentiellement de la façon dont les fichiers sont structurés, pas des données qu'ils contiennent ou de leur utilisation future (et encore moins de leur extension).

    En mode texte, on s'attend à voir des lignes de longueur variables, séparées par des retours à la ligne, et parfois des séparateurs intermédiaires. On lit ligne à ligne (ou champ à champ) sans se préoccupper de la position où l'on se trouve, et on fait en général des getline, qui lisent jusqu'au prochain délimiteur. A chaque lecture, ces délimiteurs sont supprimés: l'utilisateur n'y a jamais accès.
    Je connais bien la différence entre un fichier dit (d'ailleurs de manière erronnée) "binaire" (que l'on devrait plutôt qualifier de "fichier contenant des données brutes) et un fichier que l'on qualifie volontiers de "fichier texte"...

    Je sais aussi que l'extension n'a a priori rien à voir avec le contenu réel du fichier.

    Par contre, je te rappelle que le but de l'extension est, sommes toutes, de permettre à l'utilisateur, et dans une certaine mesure au système d'exploitation, de déterminer avec quelle application ouvrir le fichier...

    Or, classiquement, un fichier portant l'extension *.txt sera ouvert avec... un éditeur de texte "simple" (bloc note sous windows, gedit, nano, emacs ou similaire sous linux) qui vont considérer chaque byte comme étant... des caractères exclusivement.

    Et c'est là qu'apparait le problème de l'ouverture du fichier:

    Si tu essaye de gérer le contenu d'un fichier de type dit "texte" en tant que données brutes, ou celui d'un fichier de type dit "binaire" en tant que caractères, tu t'expose à un tas de problème: tes entiers qui ne dépasseront jamais 9999 ou des bips et autres caractères cabalistiques (dans le meilleur des cas), selon le cas

    En mode binaire, on doit spécifier, à chaque lecture, le nombre d'octets qu'on lit. Ceci est donc adapté à des fichiers où les champs ou les enregistrements sont de longueur fixe (mais qui peuvent parfaitement contenir des chaines de texte). Et on utilisera alors des read. Ces positions fixes permettront également plus facilement de se déplacer dans le fichier sans le lire avec des seekg par exemple.

    Le choix entre mode texte et mode binaire ne dépend pas de la nature ou de l'utilisation qu'on va faire des données, mais seulement de la façon dont elles sont organisées dans le fichier. Un grand nombre de fichiers textes sont formattés "en ASCII colonné", et se lisent en mode binaire.
    Je n'en disconvient pas, mais rien dans la question de Youry ne donne la moindre information nous permettant d'envisager seulement que ce fut le cas...

    Dans le doute, il est donc important de lui permettre de donner des précisions sur le sujet, et, le fait de lui indiquer l'incohérence "ressentie" entre son code et ses explications est une possibilités (peut être pas la meilleure ) pour l'inciter à apporter des précisions
    Citation Envoyé par ptyxs Voir le message
    D'autres que moi, plus expérimentés, répondront sans doute de façon plus élaborée et argumentée. Cela dit, il me semble que tu fais complètement fausse route : si les outils du C sont disponibles en C++ c'est avant tout pour permettre une compatibilité avec du code antérieur existant et en aucune façon parce que cela serait recommandé ou souhaitable de les utiliser dans des programmes nouveaux lorsque ce n'est pas indispensable pour une raison bien précise.
    Quant aux pointeurs et tableaux, ils constituent une des difficultés et sources d'erreur majeure du C et un des avantages du C++ c'est de permettre de les éviter dans un grand nombre de cas et de construire ainsi du code plus lisible, plus facile à maintenir et moins 'error-prone', ce qui est un des objectifs majeurs du C++
    Citation Envoyé par JolyLoic Voir le message
    L'idée n'est pas de dire que ce n'est pas standard, mais de dire que si le but est de faire du C++, il y a des alternatives supérieures.
    ptyxs et JolyLoic mis le doigt sur le but de mon intervention...

    Il faut bien comprendre, fcharton, que nous sommes visiblement en présence de quelqu'un qui:
    1. débute en C++
    2. n'a qu'une connaissance parcellaire du C

    ( @ Youry : il ne faut pas te sentir agressé par cette phrase: nous sommes tous passés par là, et ce n'est une constatation finalement assez objective de la situation )

    Or, s'il y a une seule série de pièges à c** dans lequel tous les programmeurs devront, s'ils doivent répondre honnêtement, avouer être tombés à un moment ou un autre en C, c'est, très clairement, ceux qui concernent la gestion de pointeurs, de l'allocation dynamique et de fuites mémoire.

    Et je sais par expérience qu'il est d'autant plus difficile d'abandonner une (mauvaise) habitude qu'elle a été pratiquée longtemps

    Dés lors, il est presque de notre devoir de donner les bonnes habitudes "aussi vite que possible", et ca passe par celle... de ne pas utiliser l'allocation dynamique de la mémoire si on peut l'éviter
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  5. #5
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Les lectures à base de FILE sont effectivement des héritages du C, mais tous les compilateurs C++ (que je connais) les reconnaissent, les acceptent, et les fournissent dans leurs bibliothèques standard. Si on va par là, c'est plus standard que Boost...

    Quant à char*, quelle drôle d'idée!
    Le fait est que, venant du C, on a vite fait d'assimiler un char* à... une chaine de caractères (comprend: de caractères "imprimables", composée d'un tableau de caractères terminé par '\0')

    Je veux pour preuve de cette affirmation la toute récente discussion tableau d'element hexa tronqué qui n'est qu'une illustration supplémentaire (le problème se pose très régulièrement) de la confusion si facile à faire en C
    FILE appartient au C++, tout comme "football" est un mot français d'origine anglaise. L'utiliser pour lire des fichiers, c'est sans doute pas très standard (comme on parle un français "non standard" dans plein de régions du monde), mais de là à "tirer un signal d'alarme"?

    Ca me rappelle ces parisiens qui se moquent des marseillais, ou des québecois, parce qu'ils trouvent qu'ils parlent mal français.
    Il ne s'agit pas de dénigrer le C, qui est un langage que j'utilise moi même souvent, mais simplement d'attirer l'attention aussi souvent que possible sur le fait que:
    • oui, C++ hérite du C, et propose, de ce fait, toute la palette des possibilités issue du C mais
    • non, il ne faut pas considérer C++ comme "du C avec des classes" ( C with classes)
    • il est possible de trouver une possibilité propre à C++ qui sera généralement bien plus simple, sécurisante et facile à lire à l'ensemble pour quasi la totalité des possibilités issues du C
    Mode binaire ou mode texte, ca dépend essentiellement de la façon dont les fichiers sont structurés, pas des données qu'ils contiennent ou de leur utilisation future (et encore moins de leur extension).

    En mode texte, on s'attend à voir des lignes de longueur variables, séparées par des retours à la ligne, et parfois des séparateurs intermédiaires. On lit ligne à ligne (ou champ à champ) sans se préoccupper de la position où l'on se trouve, et on fait en général des getline, qui lisent jusqu'au prochain délimiteur. A chaque lecture, ces délimiteurs sont supprimés: l'utilisateur n'y a jamais accès.
    Je connais bien la différence entre un fichier dit (d'ailleurs de manière erronnée) "binaire" (que l'on devrait plutôt qualifier de "fichier contenant des données brutes) et un fichier que l'on qualifie volontiers de "fichier texte"...

    Je sais aussi que l'extension n'a a priori rien à voir avec le contenu réel du fichier.

    Par contre, je te rappelle que le but de l'extension est, sommes toutes, de permettre à l'utilisateur, et dans une certaine mesure au système d'exploitation, de déterminer avec quelle application ouvrir le fichier...

    Or, classiquement, un fichier portant l'extension *.txt sera ouvert avec... un éditeur de texte "simple" (bloc note sous windows, gedit, nano, emacs ou similaire sous linux) qui vont considérer chaque byte comme étant... des caractères exclusivement.

    Et c'est là qu'apparait le problème de l'ouverture du fichier:

    Si tu essaye de gérer le contenu d'un fichier de type dit "texte" en tant que données brutes, ou celui d'un fichier de type dit "binaire" en tant que caractères, tu t'expose à un tas de problème: tes entiers qui ne dépasseront jamais 9999 ou des bips et autres caractères cabalistiques (dans le meilleur des cas), selon le cas

    En mode binaire, on doit spécifier, à chaque lecture, le nombre d'octets qu'on lit. Ceci est donc adapté à des fichiers où les champs ou les enregistrements sont de longueur fixe (mais qui peuvent parfaitement contenir des chaines de texte). Et on utilisera alors des read. Ces positions fixes permettront également plus facilement de se déplacer dans le fichier sans le lire avec des seekg par exemple.

    Le choix entre mode texte et mode binaire ne dépend pas de la nature ou de l'utilisation qu'on va faire des données, mais seulement de la façon dont elles sont organisées dans le fichier. Un grand nombre de fichiers textes sont formattés "en ASCII colonné", et se lisent en mode binaire.
    Je n'en disconvient pas, mais rien dans la question de Youry ne donne la moindre information nous permettant d'envisager seulement que ce fut le cas...

    Dans le doute, il est donc important de lui permettre de donner des précisions sur le sujet, et, le fait de lui indiquer l'incohérence "ressentie" entre son code et ses explications est une possibilités (peut être pas la meilleure ) pour l'inciter à apporter des précisions
    Citation Envoyé par ptyxs Voir le message
    D'autres que moi, plus expérimentés, répondront sans doute de façon plus élaborée et argumentée. Cela dit, il me semble que tu fais complètement fausse route : si les outils du C sont disponibles en C++ c'est avant tout pour permettre une compatibilité avec du code antérieur existant et en aucune façon parce que cela serait recommandé ou souhaitable de les utiliser dans des programmes nouveaux lorsque ce n'est pas indispensable pour une raison bien précise.
    Quant aux pointeurs et tableaux, ils constituent une des difficultés et sources d'erreur majeure du C et un des avantages du C++ c'est de permettre de les éviter dans un grand nombre de cas et de construire ainsi du code plus lisible, plus facile à maintenir et moins 'error-prone', ce qui est un des objectifs majeurs du C++
    Citation Envoyé par JolyLoic Voir le message
    L'idée n'est pas de dire que ce n'est pas standard, mais de dire que si le but est de faire du C++, il y a des alternatives supérieures.
    ptyxs et JolyLoic mis le doigt sur le but de mon intervention...

    Il faut bien comprendre, fcharton, que nous sommes visiblement en présence de quelqu'un qui:
    1. débute en C++
    2. n'a qu'une connaissance parcellaire du C

    ( @ Youry : il ne faut pas te sentir agressé par cette phrase: nous sommes tous passés par là, et ce n'est une constatation finalement assez objective de la situation )

    Or, s'il y a une seule série de pièges à c** dans lequel tous les programmeurs devront, s'ils doivent répondre honnêtement, avouer être tombés à un moment ou un autre en C, c'est, très clairement, ceux qui concernent la gestion de pointeurs, de l'allocation dynamique et de fuites mémoire.

    Et je sais par expérience qu'il est d'autant plus difficile d'abandonner une (mauvaise) habitude qu'elle a été pratiquée longtemps

    Dés lors, il est presque de notre devoir de donner les bonnes habitudes "aussi vite que possible", et ca passe par celle... de ne pas utiliser l'allocation dynamique de la mémoire si on peut l'éviter
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  6. #6
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Le fait est que, venant du C, on a vite fait d'assimiler un char* à... une chaine de caractères (comprend: de caractères "imprimables", composée d'un tableau de caractères terminé par '\0')
    Même en C++ d'ailleurs... Le problème de fond, c'est que le nom de ce type natif entretient cette confusion entre 'variable signée d'un octet' et 'caractère'. Et c'est pas le développement de l'unicode qui va arranger les choses...

    Citation Envoyé par koala01 Voir le message
    [*]non, il ne faut pas considérer C++ comme "du C avec des classes" ( C with classes)
    Même si je partage cette opinion, je souris toujours quand je la lis... C With Classes n'était il pas justement le nom donné au C++ par son créateur? et C++, le nom suivant (et définitif) ne proclame-t-il pas cette filiation?

    Je me demande souvent dans quelle mesure cette attitude relève de la 'foi des convertis'. Un certain nombre de professionnels qui pratiquent aujourd'hui le C++ viennent du C, et ne se sont ralliés au C++ qu'assez tard...

    Citation Envoyé par koala01 Voir le message
    Or, classiquement, un fichier portant l'extension *.txt sera ouvert avec... un éditeur de texte "simple" (bloc note sous windows, gedit, nano, emacs ou similaire sous linux) qui vont considérer chaque byte comme étant... des caractères exclusivement.

    Et c'est là qu'apparait le problème de l'ouverture du fichier:
    Pas forcément, et c'était justement mon propos... Un ASCII délimité s'ouvrira sans difficulté sur un éditeur de texte, mais sa structure en fera, pour un programme qui devrait le lire, un excellent candidat à une lecture en "mode binaire".

    Francois

  7. #7
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Même en C++ d'ailleurs... Le problème de fond, c'est que le nom de ce type natif entretient cette confusion entre 'variable signée d'un octet' et 'caractère'. Et c'est pas le développement de l'unicode qui va arranger les choses...
    Et c'est pour cela qu'il est important de faire la distinction dés que possible:
    • std::string ou similaires pour ce qui est... chaines de caractères en tant que telles
    • std::vector<char> (ou autre conteneur éventuellement mieux adapté le cas échéans) pour les données brutes

    Parce qu'il n'y a rien à faire: une std::string et un std::vetor n'ont absolument pas les mêmes fonctions membres, leur but étant conceptuellement différent (mais les deux ont ceci en commun qu'elles évitent la pénible gestion dynamique de la mémoire)

    Tu ne sera en effet pas tenté d'invoquer la fonction substr sur un std::vector, ni d'invoquer push_back sur une std::string
    Même si je partage cette opinion, je souris toujours quand je la lis... C With Classes n'était il pas justement le nom donné au C++ par son créateur? et C++, le nom suivant (et définitif) ne proclame-t-il pas cette filiation?
    C++ revendique clairement la filiation aussi...

    De l'aveu même de stroutrup, ++ est la particule d'incréementation classique, et C++ signifie "du C avec quelque chose de plus"

    Mais il faudrait beaucoup plus parler d'hérédité que de filiation

    Le rapport qu'il peut y avoir à l'heure actuelle entre le C++ et le C tient en effet plus à la transmission hériditaire de chromosomes qu'à la transmission du nom de famille: certaines caractéristiques sont communes, mais personne n'accepte que l'on confonde le père et le fils
    Je me demande souvent dans quelle mesure cette attitude relève de la 'foi des convertis'. Un certain nombre de professionnels qui pratiquent aujourd'hui le C++ viennent du C, et ne se sont ralliés au C++ qu'assez tard...
    Pas de ma part, je peux te l'assurer...

    Cependant, j'admets que beaucoup de profs / cours /tutos / livres basent leur approche sur le fait que ce C++ hérite du C et placent la connaissance du C comme un pré-requis indispensable...

    Or, je peux t'assurer qu'il est possible d'apprendre le C++ sans même avoir jamais écrit ne serait-ce qu'une ligne de code en C...

    J'ai d'ailleurs réussi à convaincre un prof qu'il devrait presque commencer son cours de C++ par
    Vous avez appris le C, et vous l'avez compris...
    C'est très bien...
    Pour apprendre le C++, vous commencez par tout oublier
    Pas forcément, et c'était justement mon propos... Un ASCII délimité s'ouvrira sans difficulté sur un éditeur de texte, mais sa structure en fera, pour un programme qui devrait le lire, un excellent candidat à une lecture en "mode binaire".

    Francois
    A ceci près qu'il reste un point que tu passe sous silence:

    La lecture d'un fichier n'a souvent que peu de sens si ce n'est pas pour récupérer les informations qu'il contient en vue d'un traitement quelconque

    Un fichier ASCII délimité est donc un candidat idéal à l'ouverture et à la lecture en "mode binaire", mais nécessitera derrière tout un processus de conversion des informations "numériques" en types adéquats...

    Que ce soit en C (avec FILE fscanf et consort) ou en C++ (avec ifstream, getline et >> ), je ne suis pas sur que le fait de séparer les deux processus permette de gagner énormément de temps par rapport à une lecture séquentielle "classique" (comprend: convertissant les informations au fur et à mesure de la lecture)
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  8. #8
    Alp
    Alp est déconnecté
    Expert éminent sénior

    Avatar de Alp
    Homme Profil pro
    Inscrit en
    Juin 2005
    Messages
    8 575
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations forums :
    Inscription : Juin 2005
    Messages : 8 575
    Points : 11 860
    Points
    11 860
    Par défaut
    Citation Envoyé par fcharton Voir le message
    Même si je partage cette opinion, je souris toujours quand je la lis... C With Classes n'était il pas justement le nom donné au C++ par son créateur? et C++, le nom suivant (et définitif) ne proclame-t-il pas cette filiation?
    Oui, au tout début des années 80, quand le C++ n'était justement que du C avec des classes...

    Puis il y a eu bien de choses en plus : exceptions, templates, la SL et la STL, j'en passe et des meilleures. En gros, la standardisation en 1998 du langage C++ par un commité ISO a définitivement mis fin à cette vue du C++.

    Aujourd'hui, le C++, c'est le "C++ Moderne" tel qu'on essaye de l'expliquer/enseigner sur le forum C++ de Developpez, où l'on ne voit des pointeurs que quand on est obligé, on utilise le RAII, on utilise à bon escient l'orienté objet, etc...

  9. #9
    Invité
    Invité(e)
    Par défaut
    En fait, j'ai l'impression qu'il y a eu au moins trois étapes...

    1- à la fin des années 80, et au début des années 90, une utilisation du C++ comme un C étendu : fonctions membres qui étendent les structs, gestion de la mémoire simplifée (avec les new typés au lieu des mallocs sur void), iostream qui remplacent les printf(), déclarations de variables où l'on veut, exceptions, et l'habitude d'utiliser davantage le compilateur pour détecter les erreurs dans le code.
    2- pendant le gros des années 90, la POO comme unique doctrine, avec les hierarchies de classes de plus en plus complexes, un accent mis sur l'héritage et le polymorphisme, les surcharges, etc...
    3- depuis une dizaine d'année, une vision du C++ comme langage "presque de haut niveau", avec des bibliothèques de plus en plus complètes, et la programmation générique qui remplace la POO comme paradigme central.

    A mon avis, si le C++ survit encore quelques décennies (je n'en suis pas certain, car il me semble que la tendance actuelle consistant à vouloir en faire un langage de haut niveau pourrait bien le rendre obsolete à assez court terme, un peu comme le pascal objet a tué le pascal...), on verra apparaitre de nouveaux paradigmes, que la génération suivante de programmeurs définira comme le "vrai C++". Les programmeurs Fortran et Cobol (autres vieux langages) racontent des histoires similaires sur l'évolution des bonnes pratiques.

    Mais il y a dans tout cela une grosse part de mode. Pour répondre à Koala01, je pense que si dans les années 90, on avait effectivement tendance à présenter le C++ comme un raffinement du C, le dogme actuel, qui fait du C++ quelque chose de "complètement différent" n'est pas plus tenable.

    Et j'avoue sourire en voyant arriver de jeunes programmeurs qui ont un peu peur des pointeurs, qui se signent avant d'écrire un cast (et sont probablement persuadés que reinterpret_cast<> est une invention du diable), ou qui, quand on leur pose un problème, n'importe lequel, froncent les sourcils et disent : on ne pourrait pas utiliser boost? Ca me fait un peu penser à ces autres spécialistes qui, quel que soit la question posée, répondent "BDD relationelle + SQL".

    Je pense que le C++ est un langage très riche, permettant des approches variées (d'un langage procédural à la C à de la POO assez pure, à des choses plus fonctionnelles ou génériques), et que sa longévité s'explique partiellement par cette richesse, qui lui permet de survivre aux modes (là où des langages plus objet, plus procéduraux, plus génériques passent). Et je soupçonne que si l'on regardait les programmes C++ écrits aujourd'hui, on retrouverait cette variété de styles et de dialectes. Je ne crois pas que ce soit une mauvaise chose.

    Maintenant, je reste d'accord avec la nécessité de parler un C++ 'mainstream', cela évite de longues discussions, et ca permet d'intégrer dans des équipes des programmeurs de générations et d'origines différentes. J'ai juste du mal avec ces "pratiques modernes' qui me paraissent toujours relever de ce que Brooks appelle les "silver bullets".

    Francois

  10. #10
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    J'ai l'impression que l'on ne se comprend pas, du moins, dans les intentions que tu me prêtes...

    Je reconnais parfaitement l'héritage du C que peut avoir le C++...

    Mais, à l'heure actuelle, lorsque l'on voit tout ce qui fait partie du C++ et qui ne fait pas partie du C, on ne peut vraiment plus considérer le langage comme "du C avec un petit plus"(même s'il y a deux petits plus )...

    Or, je suis partisan, comme en témoigne ma signature, de la doctrine qui veut que la solution la plus simple soit la meilleure

    Cela implique peut être de définir "la solution la plus simple"

    Pour moi, la "solution la plus simple" en programmation est la solution
    • qui ne me fait pas passer par Moscou pour relier Paris à Lyon
    • qui m'évite au maximum les problèmes
    • qui me permet, en cas de problème, de le retrouver "facilement"
    • qui me permet, en cas de problème, de le résoudre "facilement"
    • qui rendra la relecture et la compréhension la plus simple possible
    • accessoirement qui me fera en faire le moins possible
    Il faut avouer que, de ce point de vue, les possibilités propres au C++ ont un réel avantage sur celles issues du C

    Je ne suis, en toute honnêteté, pas partisan ni de l'utilisation de boost, ni de la généricité à tout prix...

    Mais, si ma solution " de simplicité " passe par l'un ou l'autre, surtout dans le cadre du dernier point exposé, je n'hésiterai pas une seconde à les utiliser

    Par contre, je ne trouve aucune raison suffisante pour envisager l'utilisation des possibilités issues du C
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  11. #11
    Membre averti
    Profil pro
    professeur des universités à la retraite
    Inscrit en
    Août 2008
    Messages
    364
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : professeur des universités à la retraite

    Informations forums :
    Inscription : Août 2008
    Messages : 364
    Points : 439
    Points
    439
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Pour moi, la "solution la plus simple" en programmation est la solution
    • qui ne me fait pas passer par Moscou pour relier Paris à Lyon
    • qui m'évite au maximum les problèmes
    • qui me permet, en cas de problème, de le retrouver "facilement"
    • qui me permet, en cas de problème, de le résoudre "facilement"
    • qui rendra la relecture et la compréhension la plus simple possible
    • accessoirement qui me fera en faire le moins possible
    Il faut avouer que, de ce point de vue, les possibilités propres au C++ ont un réel avantage sur celles issues du C
    Pour aller dans le même sens, on pourrait sans doute ajouter aussi :
    • qui rendra mon code plus aisé à lire, à comprendre et donc à maintenir, à faire évoluer, à déboguer pour d'autres qui viendraient après moi ou avec qui je collabore...

  12. #12
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par ptyxs Voir le message
    Pour aller dans le même sens, on pourrait sans doute ajouter aussi :
    • qui rendra mon code plus aisé à lire, à comprendre et donc à maintenir, à faire évoluer, à déboguer pour d'autres qui viendraient après moi ou avec qui je collabore...
    Il est difficile de n'être pas d'accord.

    Mais là, j'ai l'impression qu'il s'agit plus d'un pb de management, ou de ressources humaines que de langage. Les codes les plus faciles à lire sont généralement écrits par des gens qui "pensent comme toi", soit qu'ils aient les mêmes origines, le même bagage, soit qu'ils aient lu les mêmes livres.

    Si tu travailles avec des gens qui viennent du C, et qui ont appris le C++ sur le tas, il y a de grosses chances qu'un code C avec de petits bouts de C++ dedans (une forme de C++ hérétique, je veux bien l'admettre, mais du C++ malgré tout) soit plus lisible et donc maintenable par le plus grand nombre.

    Si tu travailles avec des gens un peu plus jeunes, qui ont été éduqués dans les normes POO les plus strictes, il y a des chances que l'équipe ait bâti une super hiérarchie de classes maison, et ton programme sera d'autant plus lisible qu'il suivra cette hiérarchie (aussi mal gaulée et peu évolutive soit elle).

    Si tu travailles avec des gens formés (ou reformés) plus récemment, un code utilisant autant que possible la STL, ses algorithmes et éventuellement Boost, passera pour "plus lisible".

    A ce stade, il faudrait aussi ajouter les librairies 'communes': un code horriblement compliqué écrit avec la librairie graphique obsolète mais que tout le monde connait est plus lisible et plus maintenable que le meilleur code écrit dans une librairie que seul son auteur utilise...

    A mon avis, le seul moyen, dans une équipe, pour avoir du code lisible et maintenable par d'autre, c'est de s'arranger pour que
    1- tous les membres de l'équipe aient les mêmes origines, ou aient lu les mêmes livres
    2- tous les membres s'accordent à parler un idiome assez limité du C++ (d'autant plus limité que l'équipe est grande)
    3- l'équipe soit très petite (deux ou trois), si elle est plus grande, un des membres doit avoir le dernier mot sur tous les problèmes de "style".
    4- dans le cas d'une programme assez gros, une personne est chargée, périodiquement, de "remettre au propre" le code du programme (éventuellement le sien), de façon à conserver l'unité stylistique du programme (ses décisions sont bien sur sans appel...)

    Ce n'est pas vraiment lié, à mon avis, à la nature du C++ utilisé.

    Francois

  13. #13
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par ptyxs Voir le message
    Pour aller dans le même sens, on pourrait sans doute ajouter aussi :
    • qui rendra mon code plus aisé à lire, à comprendre et donc à maintenir, à faire évoluer, à déboguer pour d'autres qui viendraient après moi ou avec qui je collabore...
    Citation Envoyé par fcharton qui a répondu Voir le message
    <snip>
    Aussi, mais, là, nous entrons dans un autre débat

    Ce sur quoi je voulais surtout insister, c'est sur le fait que C++ fournit tout ce qu'il faut pour rendre le travail plus simple et plus "sécurisant" (comprenez: de nature à éviter un maximum de bugs pour lesquels le risque est important si l'on utilise les possibilités issues du C)

    De ce seul fait, il est cohérent d'estimer que la solution la meilleure passera d'office par l'utilisation adéquate des possibilités propres au C++ de préférence à toute autre issue du C.

    Et ce forum est le lieu idéal pour permettre au plus grand nombre de prendre les habitudes qui leur faciliteront la vie.

    C'est la raison pour laquelle vous remarquerez souvent que certains participants (dont je fais partie) plaideront de manière systématique pour l'utilisation des possibilités issues du C++.

    Et c'est aussi la raison pour laquelle ceux qui se basent sur "ce qui se faisait au siècle dernier" et refusent d'admettre que les choses ont bien changé depuis (et changeront d'ailleurs peut être encore) rendent en définitive un très mauvais service aux gens qui viennent poser leur question
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  14. #14
    Membre émérite

    Inscrit en
    Mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut
    Pour moi, la "solution la plus simple" en programmation est la solution

    * qui ne me fait pas passer par Moscou pour relier Paris à Lyon
    * qui m'évite au maximum les problèmes
    * qui me permet, en cas de problème, de le retrouver "facilement"
    * qui me permet, en cas de problème, de le résoudre "facilement"
    * qui rendra la relecture et la compréhension la plus simple possible
    * accessoirement qui me fera en faire le moins possible
    Hmm, c'est un bien bel objectif, mais j'ai peur que la librairie iostream soit loin d'être un tel parangon...

    Au fond la question de l'OP est : Comment lire l'intégralité d'un fichier texte dans un buffer ?
    La réponse de la faq convient très bien pour la lecture de fichier texte formatée. Mais si l'on veut juste charger un fichier brut dans un vector de char ? Quel est la "solution la plus simple" ? Peut être avec des filebuf ?

    Edit : D'ailleurs, même avec les ifstream en mode formaté, y a t'il un moyen simple d'éviter de passer par un stringstream intermédiaire et de charger directement dans un vector de char ?

  15. #15
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par Arzar Voir le message
    Edit : D'ailleurs, même avec les ifstream en mode formaté, y a t'il un moyen simple d'éviter de passer par un stringstream intermédiaire et de charger directement dans un vector de char ?
    Ce n'est pas à cela que servent les istream_iterators ? Quelque chose du genre

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    vector<int> v;
    ifstream fdat("data.txt");
    copy(istream_iterator<int>(fdat),istream_iterator<int>(),back_inserter(v));
    Ca marche avec des données séparées par des blancs (espaces, tabs, retour chariot, etc...), mais je serait étonné qu'on ne puisse pas l'adapter à des fichiers et des structures plus complexes...

    Et pour l'écriture, tu as des choses commes

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    ofstream fdat("res.txt");
    copy(v.begin(),v.end(), ostream_iterator<int>(fdat,";"));
    Là les données de ton vecteur sont séparées par des point virgules, façon fichier csv...

    EDIT : 'scuse, j'avais pas vu "vecteur de char", là, il y a une ruse : il faut empêcher la librairie de sauter les espaces, en enlevant le flag ios::skipws de ton stream... Pour cela tu utilises le manipulateur noskipws...
    Et là, un unique

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    copy(istream_iterator<char>(fdat),istream_iterator<char>(),back_inserter(v));
    EDIT (bis) : pour des données binaires, il vaut mieux utiliser des vector<unsigned char> que des vector<char>. Sur de nombreux systèmes, les char sont signés, et cela provoque toutes sortes d'effets de bords, quand un élément d'un vector<char> est malencontreusement converti en int, par exemple...

    J'ai bon, là?
    Francois, fossile...
    Dernière modification par Invité ; 24/05/2009 à 23h23.

  16. #16
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Arzar Voir le message
    Hmm, c'est un bien bel objectif, mais j'ai peur que la librairie iostream soit loin d'être un tel parangon...
    Et pourtant...

    Le simple fait que les classes *fstream applique le RAII et la libération des ressources à la destruction est déjà fortement de nature à simplifier les choses...

    Lorsque tu ouvre un flux sur un fichier, tu sais que, quoi qu'il arrive, il sera fermé lorsque tu quittera la portée dans laquelle il est déclaré

    Rien que cela plaide déjà en faveur de l'utilisation des i/o fstream par rapport à celle de FILE
    Au fond la question de l'OP est : Comment lire l'intégralité d'un fichier texte dans un buffer ?
    La réponse de la faq convient très bien pour la lecture de fichier texte formatée. Mais si l'on veut juste charger un fichier brut dans un vector de char ? Quel est la "solution la plus simple" ? Peut être avec des filebuf ?
    De la même manière, l'utilisation systématique d'un std::vecto<char>, même si elle te demande de passer par la fonction resize() pour être sur d'éviter les innombrables réallocations internes que pourrait nécessiter une lecture "byte à byte" du fichier est bel et bien "la solution la plus simple" comparée à la gestion manuelle de la mémoire que peut nécessiter un simple char*
    Edit : D'ailleurs, même avec les ifstream en mode formaté, y a t'il un moyen simple d'éviter de passer par un stringstream intermédiaire et de charger directement dans un vector de char ?
    Il y a effectivement moyen... mais ne passant par un fichier binaire (comme je l'ai déjà dit, il ne faut pas ouvrir un fichier contenant des données brutes en mode "texte" )

    (ceci dit, il y a moyen de le faire en ouvrant un fichier de type "texte" en mode texte, mais nous courrons le risque de rencontrer certains problèmes au niveau de la représentation des caractères de fin de ligne, si le fichier a été créé sur un système différent (créé sous linux et lu sous windows, ou inversement)
    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
    void foo()
    {
        // nous avons besoin d'un tableau pour récupérer les données
        vector<char> toread;
        // et du flux de fichier, ouvert en mode "binaire" (le mal nommé)
        ifstream ifs("fichier.dat",ios_base::binary);
        // sauvegarder la position courante dans le fichier
        long pos=ifs.tellg();
        // se placer en fin de fichier
        ifs.seekg( 0 , std::ios_base::end );
        // récupérer la nouvelle position = la taille du fichier
        long size = ifs.tellg() ;
        // restaurer la position initiale du fichier
        ifs.seekg( pos,  std::ios_base::beg ) ;
        /* NOTA: tout ce que l'on a fait jusqu'ici aurait de toutes manières
         * du être fait en C aussi  ;)
         */
        /* redimentionons le tableau en une seule fois à la taille ad-hoc */
        toread.resize(size);
        /* Et lisons "d'une seule traite" l'ensemble du fichier */
        ifs.read(&toread[0],size);
    }
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  17. #17
    Membre émérite

    Inscrit en
    Mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut
    Aaaah oui, c'est vrai, il y a aussi la fonction read. C'est donc ça que voulait dire la faq par :

    "La taille du buffer peut être différente de celle du fichier si le fichier n'a pas été ouvert en mode texte (en utilisant le mode std::ios_base::binary). Il est aussi possible d'utiliser la fonction read de std::ifstream en ayant au préalable alloué un buffer suffisamment grand. Pour connaître la taille à allouer, consulter la question Comment calculer la taille d'un fichier. "

    Ok, a posterio c'est logique.
    Peut-être pourrait-on modifier un peu la faq pour la rendre un peu plus explicite ? Je propose de rajouter un item "Comment effectuer une lecture binaire de l'intégralité d'un fichier dans un buffer ?" après le dernier item Comment effectuer des lectures / écritures binaires dans un fichier ?


    Comment effectuer une lecture binaire de l'intégralité d'un fichier dans un buffer ?


    Pour charger l'intégralité d'un fichier dans un buffer par une lecture binaire, il faut ouvrir le fichier avec le mode std::ios_base::binary et utiliser la fonction read de std::ifstream. Le buffer doit au préalable avoir été alloué de manière à possèder une taille suffisante.
    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
    #include <fstream>
    #include <iostream>
     
    int main()
    {
        // on ouvre le fichier en lecture
        std::ifstream fichier( "fichier.txt", ios_base::binary );
     
        // ce vecteur nous servira de buffer
        vector<char> buffer;
     
        if ( fichier ) // ce test échoue si le fichier n'est pas ouvert
        {
           // calcul de la taille du fichier 
           //(voir FAQ : Comment calculer la taille d'un fichier ?)
           long pos = Fichier.tellg();
           fichier.seekg( 0 , std::ios_base::end );
           long size = Fichier.tellg() ;
           fichier.seekg( pos,  std::ios_base::beg ) ;
     
          // redimensionne le vecteur à la taille du fichier 
          buffer.resize(size);
          // et lit l'intégralité du fichier
          fichier.read(&buffer[0], size);
        }
    }

  18. #18
    Membre éprouvé
    Avatar de Antoine_935
    Profil pro
    Développeur web/mobile
    Inscrit en
    Juillet 2006
    Messages
    883
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur web/mobile

    Informations forums :
    Inscription : Juillet 2006
    Messages : 883
    Points : 1 066
    Points
    1 066
    Par défaut
    Citation Envoyé par koala01 Voir le message
    Cela signifie que dés que l'on remarque FILE, fread, fwrite, fopen, fclose ou même char* (plus toutes les choses auxquelles je ne pense pas), il faut tirer un signal d'alarme et bien faire comprendre à la personne qu'il travaille en C.
    Je ne suis pas tout à fait d'accord.
    Est-il formellement interdit de se servir d'autre chose que de la stl en c++ ?
    Quand je dois faire des concaténations de nombreux strings je ne me sers pas de la classe mais bien d'un char*, c'est à la fois plus simple et plus rapide. Mais peut-être que j'ai raté une méthode utile.

    Cela dit, je suis entièrement convaincu de l'intérêt de la stl sur les machines habituelles. Elle est par contre un peu trop lourde à mon goût pour le développement embarqué. On pourrait me répondre que je peux bien faire du C alors, mais l'orienté objet a de la valeur à mes yeux. Il en va ainsi pour beaucoup de choses qu'apporte le c++, même sans la stl.

  19. #19
    Expert éminent sénior
    Avatar de koala01
    Homme Profil pro
    aucun
    Inscrit en
    Octobre 2004
    Messages
    11 612
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 52
    Localisation : Belgique

    Informations professionnelles :
    Activité : aucun

    Informations forums :
    Inscription : Octobre 2004
    Messages : 11 612
    Points : 30 611
    Points
    30 611
    Par défaut
    Citation Envoyé par Antoine_935 Voir le message
    Je ne suis pas tout à fait d'accord.
    Est-il formellement interdit de se servir d'autre chose que de la stl en c++ ?
    Bien sur que non, ce n'est pas interdit...

    Mais c'est très fortement déconseillé
    Quand je dois faire des concaténations de nombreux strings je ne me sers pas de la classe mais bien d'un char*, c'est à la fois plus simple et plus rapide.
    Crois tu vraiment que le fait de devoir vérifier s'il te reste suffisemment de place pour effectuer la concaténation et devoir réallouer de la mémoire le cas échéans soit facile
    Mais peut-être que j'ai raté une méthode utile.
    Peut être simplement les opérateurs + et += redéfinis pour la classe string, qui fonctionnent aussi très bien avec des char*
    Cela dit, je suis entièrement convaincu de l'intérêt de la stl sur les machines habituelles. Elle est par contre un peu trop lourde à mon goût pour le développement embarqué. On pourrait me répondre que je peux bien faire du C alors, mais l'orienté objet a de la valeur à mes yeux. Il en va ainsi pour beaucoup de choses qu'apporte le c++, même sans la stl.
    Fais déjà attention à la différence (effectivement subtile) qui existe entre la SL (qui contient entre autre la classe string) et la STL qui manipule les modèle

    Je n'ai, à mon grand dam, encore jamais eu l'occasion de travailler dans l'embarqué, mais, en théorie, l'utilisation des modèles ne devrait pas vraiment avoir d'impact particulier par rapport à une structure identique "classsique" étant donné que tout est fait au moment de la compilation...

    La bonne question étant de savoir si, effectivement, la structure même des collections de la STL sont intéressante en embarqué... et, sur ce point, je ne suis pas en mesure de faire ma propre idée
    A méditer: La solution la plus simple est toujours la moins compliquée
    Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
    Compiler Gcc sous windows avec MinGW
    Coder efficacement en C++ : dans les bacs le 17 février 2014
    mon tout nouveau blog

  20. #20
    Membre émérite

    Inscrit en
    Mai 2008
    Messages
    1 014
    Détails du profil
    Informations forums :
    Inscription : Mai 2008
    Messages : 1 014
    Points : 2 252
    Points
    2 252
    Par défaut
    Citation Envoyé par Antoine_935 Voir le message
    Quand je dois faire des concaténations de nombreux strings je ne me sers pas de la classe mais bien d'un char*, c'est à la fois plus simple et plus rapide. Mais peut-être que j'ai raté une méthode utile.
    Et bien, on peut toujours essayer de comparer.
    (Le sujet de départ a été bien traité, on peut se permettre un peu de hors-sujet )
    Pour ma part, je pense que la solution C sera plus rapide, mais pas extrêmement plus rapide...

    Pourrais-tu fournir un exemple de concaténations de nombreuses strings en C avec des char* ? Je prendrais alors ce code comme référence pour comparer à une solution C++.

Discussions similaires

  1. Forum des bonnes pratiques en gestion de projet 2014
    Par QRP-France dans le forum Communiqués
    Réponses: 0
    Dernier message: 20/08/2014, 18h58
  2. Des bonnes pratiques et toujours des questions
    Par dafpp dans le forum Débuter
    Réponses: 29
    Dernier message: 04/12/2013, 01h26
  3. question a propos des bonnes pratiques ACCESS
    Par amne26 dans le forum IHM
    Réponses: 1
    Dernier message: 25/09/2008, 19h52
  4. [XML] Synthèse des bonnes pratiques XML
    Par neuromencien dans le forum XML/XSL et SOAP
    Réponses: 2
    Dernier message: 21/03/2007, 22h55
  5. De la bonne pratique des includes...
    Par say dans le forum C++Builder
    Réponses: 4
    Dernier message: 24/11/2005, 12h15

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