question curiosité ofstream ifstream

Version imprimable

19/09/2007, 15h28
hibiscuit

question curiosité ofstream ifstream
Bonjour,

Comme je le dis en titre, ce n'est qu'une question de curiosité dont la réponse ne me servira que pour ma culture perso, à moins qu'elle ne soit positive (dans ce cas là, j'appliquerai la réponse quand j'aurai le temps)

Dans mes programmes, en général j'ai un tas de fichiers que je crée ou lis et j'ai donc dans mon main, tout un tas d'ouverture de fichiers, ce qui prend de la place et gêne la lisibilité de mon programme (enfin je trouve) car à chaque fois j'écris tout ça :
Code:

1 2 3 4 5 6 7 8 ifstream Fdata; Fdata.open("hd180642.dat"); if (!Fdata) { cout<<"Error opening Fdata file"<<endl; return 1; }
Et 7 lignes multipliées par x fichiers, ça fait beaucoup.

Alors, je me pose une question, est ce qu'il est possible de sortir de mon programme principal toutes ces ouvertures de fichiers pour les mettre dans un autre fichier que je pourrai appeler via #include, un peu comme on fait avec les définitions de fonctions ?
J'aurai tendence à penser que non mais comme j'ai peu d'expérience et donc peu de connaissances, je préfère vous le demander...

Et si oui, cela ne gène pas que les fermetures des fichiers restent dans mon programme principal ?

voilà voilà :oops:

;)
19/09/2007, 15h38
poukill

Citation:

Envoyé par hibiscuit

Dans mes programmes, en général j'ai un tas de fichiers que je crée ou lis et j'ai donc dans mon main, tout un tas d'ouverture de fichiers, ce qui prend de la place et gêne la lisibilité de mon programme (enfin je trouve) car à chaque fois j'écris tout ça :

J'ai envie de dire que si t'as tout un tas d'ouverture de fichier dans ton main, tu as effectivement un problème... de conception a priori.
En effet, si tu répètes n fois la même action, alors il y a de forte chance qu'une abstraction t'aie échappée. -> construction d'une classe.

Dans un main, tu ne devrais pas avoir grand chose. L'idéal étant un programme où il n'y a pas vraiment de programme principal (enfin si quand même, y'a forcément un main mais c'est pas ce que je veux dire). Le programme devrait être composé de modules au maximum indépendants, chacun réalisant un petit truc bien précis...
Ton main devrait alors être très court.

Personnellement, le main du projet que je viens de terminer (plus de 30 000 lignes de code) est le plus petit de tous les fichiers de mon projet. :mrgreen:

Salut,

La premier principe qu'il faut apprendre et veiller à respecter avant tout, lorsque l'on apprend à programmer tient en deux phrases:

Déléguer tout ce qui peut être délégué
une fonction n'a qu'une responsabilité (ou un nombre restreint de responsabilités)

Et cela, même si on travaille en procédural (en "non orienté objet")

Ainsi, main qui va quand même mettre toute la machine en branle, devrait dans bien des cas pour ainsi dire se contenter d'un
Code:

1 2 3 4 5 6 7 8 int main() { Initialisation(); Travail(); Liberation(); return 0; }
La fonction Initialisation aura pour but de s'assurer que l'on dispose de tout ce qu'il faut, la fonction Travail fournira le plus souvent une boucle du genre de "tant qu'on ne m'a pas dit d'arrêter, je continue" et la fonction Libération s'occupera de veiller à ce que toutes les ressources allouées pour le travail ont été correctement libérées.

Dans ton cas, la fonction d'initialisation devra sans doute se charger de la création d'une liste de fichiers, éventuellement, avec certaines informations concernant le type de données que chaque fichier est sensé contenir.

On pourrait estimer comme probable (à adapter à ta situation propre) qu'il existe un fichier qui reprend l'ensemble de ces informations sous une forme proche, par exemple de
Code:

1 2 3 4 5 6 /* exemple de fichier "liste.txt*/ <nom> <type de donnee> monfichier.dat data1 fichier2.dat data2 fichier3.dat data3 ...
(où le type de données serait, pourquoi pas, une simple énumération permettant de savoir ce qu'il en est ;))

Tu aurais donc une structure du genre de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 struct FileInfo { enum type { data1, data2, data3, data4/*,...*/ }; std::string filename, type t; };
Et la fonction Initialisation deviendrait alors
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 std::vector<FileInfo> Initialisation() { std::vector<FileInfo> ret; std::ifstream ifs("liste.txt"); std::string str while( std::getline(ifs,str)) { std::stringstream ss; ss<< str; TypeInfo temp; ss>>temp.filename; ss>>temp.t; ret.push_back(temp); } return ret; }
La fonction Travail() deviendrait quelque chose prenant la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Travail(const std::vector<TypeInfo>& tab) { for(size_t i=0;i<tab.size();i++) { switch(tab[i].t) { case data1: ReadFileDataType1(tab[i].name); break; case data2: ReadFileDataType2(tab[i].name); break; case data3: ReadFileDataType3(tab[i].name); break; case data4: ReadFileDataType4(tab[i].name); break; /* case ... */ } } }
(ou les fonctions ReadFileDataTypeN seraient à chaque fois une fonction prenant en charge un type particulier de fichier)

et donc, main deviendrait
Code:

1 2 3 4 5 6 7 8 int main() { std::vector<FileInfo> todo=Initialisation(); Travail(todo); /* ici, pas besoin de "nettoyage"... enfin... selon les cas ;-) */ return 0; }
Evidemment, le fait de passer en version orientée objet peut permettre quelques trucs sympa... et je n'ai rien mis concernant la gestion éventuelle d'erreur (un fichier qui n'existe pas, par exemple).

Mais cette manière de travailler te permettra de garder en permanence des fonctions les plus petites possibles, et donc de gagner énormément en lisibilité ;)

19/09/2007, 19h55
hibiscuit

Le travail risque d'être plus compliqué que je ne pensais :lol::lol:
Merci pour vos conseils. Je savais déjà que le main doit être tout petit par rapport aux différents modules du programme mais c'est vrai que pour moi qui débute (toute seule en plus :( ), j'ai quelques difficultés à le conserver petit...

J'avais déjà commencé à alléger mon main en écrivant un tas de fonctions que je ne vais plus tarder à mettre dans plusieurs fichiers .cpp (maintenant qu'elles sont écrites et qu'elles fonctionnent)
Il est vrai que pour le moment, je ne suis pas au top niveau lisibilité du main, mais je m'améliore et j'espère que je vais continuer à m'améliorer (il va bien falloir, car la programmation sera presque la seule chose que j'aurai apprise pendant ma thèse et du point de vue des employeurs, ce sera le seul truc potable que je pourrai mettre en avant.... vive les études dans des domaines pointus qui n'ont aucune application dans la vie de tous les jours...... :lol: .... il me reste deux ans.... viiiite !! )
Bref, je m'égare.....

J'ai d'ailleurs une nouvelle question : J'ai tout un tas de variables, paramètres, compteurs, tableaux, etc. à déclarer pour pouvoir utiliser mes fonctions. Pour le moment, elles sont toutes dans mon main... naturellement......
Est-ce qu'il est possible de les mettre (en partie ?) dans un fichier .h ? J'ai aperçu cette pratique en fouillant le net.
J'ai fait un essai basique en incluant dans mon fichier.cpp un fichier.h dans lequel j'avais juste écrit

Code:

int i

et dans mon main, en gros, il n'y avait que ça :

Code:

i = 2;

Ca avait l'air de marcher mais est-ce que c'est "propre" comme façon de faire ?
Désolée, je suis un peu paumée... :oops:

Et sinon, vous savez où je peux trouver des sources de programmes en C++ (pas trop compliqués non plus) pour m'inspirer de la structure du programme ?

Est-ce que vous pensez que je devrais renommer l'intitulé de mon premier message comme je suis en train de m'éloigner du sujet principal ?

;)
19/09/2007, 20h19
koala01

Salut,

De manière générale, il vaut mieux éviter ce que l'on appelle les "variables globales", pour toute une série de raisons que l'on peut t'expliquer si tu en fait la demande (sinon, tu peux te contenter de savoir que c'est à éviter :D:roll:)

Or, il faut savoir que, si tu déclare une variable en dehors de toutes fonction, tu en fais, "de facto" une variable qui sera globale pour tous les endroits où le fichier d'en-tête (*.h) est inclus, et cela comprend le phénomène d'inclusion en cascade (c.h qui inclus b.h qui inclus a.h fait si une variable globale est déclarée dans a.h, elle sera déclarée partout où tu aura une inclusion de c.h)

Il faut savoir que l'idéal reste toujours de ne déclarer une variable (quelle qu'elle soit) que quand tu en a réellement besoin, et que, si tu travailles dans une optique orientée objet, l'idéal est même de mettre en oeuvre le paradigme que l'on nomme RAII(Ressource Aquisition Is Initialisation), qui implique qu'il faille attendre, avant de déclarer une variable d'un type personnalisé, de disposer de l'ensemble des informations permettant de l'initialiser correctement :P

Essaie aussi de créer des structures correctes en regroupant les valeurs qui sont destinées à fonctionner en même temps (une personne, c'est un nom, un prénom et un age, et le tout est étroitement lié...Même si les types de données utilisés pour représenter chacune de ces informations est différent :D:P)

*Envisage* peut être la programmation orientée objet, car, après tout, C++ est un langage ayant une excellente capacité Orientée Objet. Cela te permettra d'aller d'autant plus loin dans le principe énoncé plus haut ;)

Juste à titre informatif, quelles études as-tu entreprises, où cela, et sont-elles finies :question:
19/09/2007, 21h38
poukill

Je plussoie complètement Koala...
Mais je mettrai quand même un bémol. C'est à toi de voir si tu veux t'améliorer un peu dans la programmation, ou bien beaucoup. Donc en gros, est-ce simplement un outil passager, ou bien est-ce une composante principale dans ton métier.
Pour ma part, étant dans le traitement du signal, c'est indispensable de "bien" programmer (RAII, orienté objet, etc...). A toi de voir si c'est ton cas aussi.
Car tout ce que vient de t'expliquer Koala demande un peu (beaucoup) de temps de pratique passé à ça. Dans le cadre d'une thèse, tu ne peux peut-être pas te permettre de perdre trop de temps en programmation "pure". Un code approximatif suffirait pour une analyse physique s'il n'est pas destiné à être repris. (ça me fait mal de dire ça mais c'est la triste vérité).

En tout cas, si tu souhaites te mettre sérieusement à la programmation, tu trouveras tout ce que tu as besoin dans les forums et dans la FAQ !

Bonne continuation
20/09/2007, 13h57
hibiscuit

Merci vous deux pour vos encouragements !!

Citation:

Envoyé par Koala01

De manière générale, il vaut mieux éviter ce que l'on appelle les "variables globales", pour toute une série de raisons que l'on peut t'expliquer si tu en fait la demande (sinon, tu peux te contenter de savoir que c'est à éviter )

Oh moi je suis toujours intéressée de savoir pourquoi c'est à éviter mais je ne veux pas non plus abuser de ton temps et de ta gentillesse :oops:
Sans doute que ça doit être expliqué dans tous les bons cours qui parlent de variables globales ?

Citation:

Envoyé par Koala01

Il faut savoir que l'idéal reste toujours de ne déclarer une variable (quelle qu'elle soit) que quand tu en a réellement besoin, et que, si tu travailles dans une optique orientée objet, l'idéal est même de mettre en oeuvre le paradigme que l'on nomme RAII(Ressource Aquisition Is Initialisation), qui implique qu'il faille attendre, avant de déclarer une variable d'un type personnalisé, de disposer de l'ensemble des informations permettant de l'initialiser correctement

Merci du conseil. Je vais me renseigner sur le RAII.

Citation:

Envoyé par Koala01

Essaie aussi de créer des structures correctes en regroupant les valeurs qui sont destinées à fonctionner en même temps

Oui, ça c'est une très bonne idée. En fait, j'ai découvert les structures ... la semaine dernière... :lol:
j'en avait déjà vaguement entendu parler mais je n'en avais jamais utilisé. Il va falloir que j'en crée d'autres, ça va éclaicir l'utilisation de certaines de mes fonctions...

Citation:

Envoyé par Koala01

*Envisage* peut être la programmation orientée objet, car, après tout, C++ est un langage ayant une excellente capacité Orientée Objet. Cela te permettra d'aller d'autant plus loin dans le principe énoncé plus haut

Oui, je crois que sur ce point, j'ai encore tout à apprendre. Parfois je me dis que c'est du C que je fais et pas du C++. :oops:

Citation:

Envoyé par Koala01

Juste à titre informatif, quelles études as-tu entreprises, où cela, et sont-elles finies

Citation:

Envoyé par poukill

Donc en gros, est-ce simplement un outil passager, ou bien est-ce une composante principale dans ton métier.

Je fais un doctorat en astrophysique à l'observatoire de paris. Il me reste encore deux ans avant de finir mes études. Et le travail principal de ma thèse, c'est le traitement des données (en gros, sismologie des étoiles). A priori, je suis sensée écrire un code qui à partir du signal de mon étoile me ressort les fréquences d'oscillations de mon étoile (rien de très compliqué a priori)... et si mon code fonctionne bien (et j'ai pas le choix, il doit bien fonctionner) il sera sans doute utilisé par d'autres équipes qui sont nos collaborateurs....... Normalement je devrais déjà l'avoir terminé depuis longtemps mais comme j'ai de grosses lacunes en programmation et qu'en plus, ça coince toujours sur un problème scientifique quelque part, je ne l'ai toujours pas terminé. :?
Ensuite lorsque les données arriveront, j'ose espérer que je n'aurai plus trop à programmer mais je suis presque sûre que je me trompe. Un code a toujours besoin d'être amélioré.....
Ce qui fait que pour ma thèse, c'est pour le moment la composante principale de mon travail.

Une fois ma thèse terminée, je dois avouer que je ne sais pas ce que je ferai : de la recherche ou carrément autre chose ? Tout dépend des deux années qui arrivent. Donc, au cas où je décide de faire autre chose, je me dis que je pourrai peut être dire que je sais [un peu] programmer en C++ et c'est pour ça que je commence à essayer de m'améliorer sérieusement. Ca me fera au moins une compétence en quelque chose. :mrgreen:

Citation:

Envoyé par poukill

Pour ma part, étant dans le traitement du signal, c'est indispensable de "bien" programmer (RAII, orienté objet, etc...). A toi de voir si c'est ton cas aussi.

Comme écrit au dessus, le sujet de ma thèse n'est pas bien loin de ton travail. Et d'ailleurs en astrophysique de manière générale, on n'a que la programmation pour tester des hypothèses, créer un modèle théorique ou extraire d'un signal avec un rapport signal/bruit super faible l'info qu'on cherche... On ne peut pas monter des expériences "au sol" et donc on retrouve la programmation partout... donc bien programmer, c'est assez important.

Citation:

Envoyé par poukill

Car tout ce que vient de t'expliquer Koala demande un peu (beaucoup) de temps de pratique passé à ça. Dans le cadre d'une thèse, tu ne peux peut-être pas te permettre de perdre trop de temps en programmation "pure". Un code approximatif suffirait pour une analyse physique s'il n'est pas destiné à être repris. (ça me fait mal de dire ça mais c'est la triste vérité).

Oui, malheureusement, la thèse passe trop vite et j'ai bien peur qu'un code approximatif sera une obligation... :( Mais il se doit quand même d'être un minimum rigoureux sur la physique qu'il y a derrière. Pour ma part, j'aimerai quand même qu'il ne soit pas trop mal fait mon code.... peut être que je suis utopique :roll:

Citation:

Envoyé par poukill

En tout cas, si tu souhaites te mettre sérieusement à la programmation, tu trouveras tout ce que tu as besoin dans les forums et dans la FAQ !

Oui, ça m'est bien utile !!

Encore merci ! :D :king:
20/09/2007, 15h18
koala01

Citation:

Envoyé par hibiscuit

Oh moi je suis toujours intéressée de savoir pourquoi c'est à éviter mais je ne veux pas non plus abuser de ton temps et de ta gentillesse :oops:
Sans doute que ça doit être expliqué dans tous les bons cours qui parlent de variables globales ?

Ho, faut pas t'en faire, tu ne me donne nullement l'impression "d'abuser de ma gentillesse" (de toutes façons, je sais qu'elle me perdra :lol:)

Les raisons sont en effet expliqué dans tous les *bons* cours, mais, de manière générale, c'est surtout parce que le principal reproche qu'on puisse leur faire est... d'être accessibles partout :P

De là, dérivent une série de raisons qui font que ce n'est pas *l'idéal* à utiliser, même si, rien n'étant jamais tout blanc ou tout noir, et surtout pas en informatiqe, on peut trouver des cas où c'est bien utile :D

Citation:

Envoyé par hibiscuit

Merci du conseil. Je vais me renseigner sur le RAII.

En fait, c'est un paradigme, donc, une simple manière de concevoir les choses...

Comme la traduction le laisse deviner (Acquisition des Ressources est Initialisation), l'idée générale est de donner immédiatement la valeur correcte à une variable... Mais pour cela, il faut... la valeur à lui donner :P.

L'avantage qu'il apporte, c'est que l'on risque *moins* de se retrouver avec une variable que l'on croit avoir initialisée, alors qu'elle ne l'est pas, et donc que l'on limite le risque d'avoir un résultat aberrant ;)

Citation:

Envoyé par hibiscuit

Oui, ça c'est une très bonne idée. En fait, j'ai découvert les structures ... la semaine dernière... :lol:

j'en avait déjà vaguement entendu parler mais je n'en avais jamais utilisé. Il va falloir que j'en crée d'autres, ça va éclaicir l'utilisation de certaines de mes fonctions...

C'est l'un des buts, en effet... Elles permettront de fournir directement l'ensemble des informations "d'une seule traite", et donc de restreindre le nombre d'arguments à passer ;)

Citation:

Envoyé par hibiscuit

Oui, je crois que sur ce point, j'ai encore tout à apprendre. Parfois je me dis que c'est du C que je fais et pas du C++. :oops:

Le C++ permet tout à fait la programmation en "procédural", et, tant que tu utilises plutôt les méthodes fournies par le C++ et non celles qui se trouvent dans le "sous-ensemble" C... cela peut très bien rester du C++ :D

Mais il est vrai que, l'un dans l'autre, le C++ ayant été étudié pour avoir des capacités objet, ce serait un peu bête de s'en priver :P

Citation:

Envoyé par hibiscuit

Je fais un doctorat en astrophysique à l'observatoire de paris. Il me reste encore deux ans avant de finir mes études. Et le travail principal de ma thèse, c'est le traitement des données (en gros, sismologie des étoiles). A priori, je suis sensée écrire un code qui à partir du signal de mon étoile me ressort les fréquences d'oscillations de mon étoile (rien de très compliqué a priori)... et si mon code fonctionne bien (et j'ai pas le choix, il doit bien fonctionner) il sera sans doute utilisé par d'autres équipes qui sont nos collaborateurs....... Normalement je devrais déjà l'avoir terminé depuis longtemps mais comme j'ai de grosses lacunes en programmation et qu'en plus, ça coince toujours sur un problème scientifique quelque part, je ne l'ai toujours pas terminé. :?
Ensuite lorsque les données arriveront, j'ose espérer que je n'aurai plus trop à programmer mais je suis presque sûre que je me trompe. Un code a toujours besoin d'être amélioré.....
Ce qui fait que pour ma thèse, c'est pour le moment la composante principale de mon travail.

Evidemment, on comprend dés lors tout de suite que tu n'ai pas eu de cours de programmation, ET que tu t'y intéresse... :P

Citation:

Envoyé par hibiscuit

Une fois ma thèse terminée, je dois avouer que je ne sais pas ce que je ferai : de la recherche ou carrément autre chose ? Tout dépend des deux années qui arrivent. Donc, au cas où je décide de faire autre chose, je me dis que je pourrai peut être dire que je sais [un peu] programmer en C++ et c'est pour ça que je commence à essayer de m'améliorer sérieusement. Ca me fera au moins une compétence en quelque chose. :mrgreen:

Accroche toi, je me dis que ce domaine doit être passionnant :mrgreen:

Citation:

Envoyé par hibiscuit

Comme écrit au dessus, le sujet de ma thèse n'est pas bien loin de ton travail. Et d'ailleurs en astrophysique de manière générale, on n'a que la programmation pour tester des hypothèses, créer un modèle théorique ou extraire d'un signal avec un rapport signal/bruit super faible l'info qu'on cherche... On ne peut pas monter des expériences "au sol" et donc on retrouve la programmation partout... donc bien programmer, c'est assez important.

Oui, mais d'un autre côté, tu peux *estimer* que tu disposera le plus souvent d'un programmeur ou d'un informaticien à tes côtés, justement pour que tu puisse te concentrer sur "ce qui t'intéresse particulièrement" (les étoiles :D)

Citation:

Envoyé par hibiscuit

Oui, malheureusement, la thèse passe trop vite et j'ai bien peur qu'un code approximatif sera une obligation... :( Mais il se doit quand même d'être un minimum rigoureux sur la physique qu'il y a derrière. Pour ma part, j'aimerai quand même qu'il ne soit pas trop mal fait mon code.... peut être que je suis utopique :roll:

Non pas utopique... aimer le travail bien fait n'est jamais une utopie :D

Maintenant, il faut avouer que trouver du temps pour se perfectionner dans un domaine se fait le plus souvent au dépends d'un autre... (surtout parce qu'il n'y a que 24 heures dans une journée :P)

Mais comme le dit le proverbe "à coeur vaillant, rien d'impossible" :D