Discussion :

[hibiscuit]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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à

[poukill]

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.

[koala01]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

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
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 :

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
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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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é

[hibiscuit]

Le travail risque d'être plus compliqué que je ne pensais
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...... .... 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 :

Sélectionner tout - Visualiser dans une fenêtre à part

int i

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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...

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 ?

[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 )

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

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 )

*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

[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

[hibiscuit]

Merci vous deux pour vos encouragements !!

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
Sans doute que ça doit être expliqué dans tous les bons cours qui parlent de variables globales ?

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.

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...
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...

*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++.

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

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.

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.

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

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 !

[koala01]

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
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 )

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

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

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 .

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

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

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

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++.

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++

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

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...

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.

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

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 )

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

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

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 )

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