Discussion :

[KonTiKI]

Bonjour à tous.

Je vous ai pas mal sollicité durant ces derniers jours. Et je vous remercie pour votre aide.

J'aurais souhaité vous proposer mon premier code en C++ pour recueillir vos observations et surtout valider ma compréhension de l'esprit C++ au travers de cette fonction.

Elle doit aboutir à la lecture d'un fichier settings.ini qui donne notamment le chemin et le nom du fichier bdd, ainsi que les paramètres de connexion d'un ftp local. Les valeurs lues sont ensuite passées à un map parametres pour exploitation ultérieure.

L'entête :

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
 
#ifndef INITIALISATION_H
#define INITIALISATION_H
 
#include <map>
 
class initialisation
{
public:
    initialisation();
private:
    bool checkInit();
    std::map<std::string,std::string> parametres;
    std::map<std::string,std::string>::iterator itparam;
};
 
#endif // INITIALISATION_H

le source :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
 
#include "initialisation.h"
#include <iostream>
#include <string>
#include <fstream>
 
 
initialisation::initialisation()
{
    if(!checkInit()) // 1 - vérifier si settings.ini existe.
    {
        std::cout << "le fichier settings.ini est absent, illisible ou incomplet" << std::endl;
        //ici procédure de paramétrage
    }
    else
    {
        std::cout << "le fichier settings.ini est present" << std::endl;
        //ici procédure de connexion
    }
}
 
bool initialisation::checkInit()
{
    std::ifstream i("settings.ini", std::ios::in);
    std::string ligne, str_to_find = "=", membreGauche, membreDroit;
    if (!i) {
        return(false);
    }
 
    while(std::getline(i, ligne))
    {
        if (ligne.find(str_to_find) != std::string::npos)
        {
          membreGauche = ligne.substr(0,ligne.find("="));
          membreDroit = ligne.substr(ligne.find("=")+1);
 
          if(membreGauche == "" || membreDroit == "")
          {
              return(false);
          }
          parametres [membreGauche] = membreDroit;
        }
    }
 
    i.close();
 
    return(true);
}

Le fichier settings.ini :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
[DB_SETTINGS]
PATH=/.
FILENAME=WesData.db
 
[WES]
IP=192.168.1.99
PORT=21
IDENTIFIANT=admin
MDP=motdepasse

Merci pour vos remarques.

PS : j'ai tenté le passage du fichier dans un buffer, mais le while ne fonctionnait pas sur le buffer. Comme ce fichier n'est lu qu'une fois, j'ai opté pour une lecture directe du fichier.

[Pyramidev]

Bonjour.

Première remarque :
Ta fonction initialisation::checkInit signale les erreurs à la fonction appelante sous la forme d'un simple booléen. Ce booléen, quand il est faux, n'informe pas sur la cause de l'erreur.
Une solution plus adaptée serait de lever une exception. Plus d'informations dans la FAQ C++.

Deuxième remarque, indépendante du langage :
Ta classe initialisation cumule trop de rôles. A mon avis, il faudrait au moins trois classes différentes :

• Une classe qui modélise n'importe quel fichier INI, pour éviter de recoder la même chose chaque fois qu'il faut traiter un nouveau type de fichier INI :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  class FichierIni
  {
  private:
      std::map< std::string, std::map<std::string,std::string> > m_sectionClefValeur;
  public:
      FichierIni();
      explicit FichierIni(const std::string& adresseFichier); // Lève une exception en cas de problème de format.
      std::string getValeur(const std::string& section, const std::string& clef) const;
      void        setValeur(const std::string& section, const std::string& clef, const std::string& valeur);
      void        ecrireFichier(const std::string& adresseFichier) const; // Lève une exception en cas d'échec d'écriture.
      // ...
  };

  Il faudra d'ailleurs vérifier si cette classe n'existe pas déjà dans les bibliothèques que tu utilises. Cela évitera de réinventer la roue.
• Une classe qui modélise settings.ini :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  class SettingIni
  {
  public:
      explicit SettingIni(const std::string& adresseFichier);
          // Utilise la classe FichierIni pour lire le fichier,
          // vérifie que les infos obligatoires y sont et
          // vérifie que ces infos sont cohérentes.
          // Lève une exception en cas d'erreur.
   
      std::string getCheminDatabase() const; // valeur de la clef PATH de la section [DB_SETTINGS]
   
      // ...
  };

• Une classe pour se connecter à la base de données et interagir avec :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  class Bdd
  {
  public:
      Bdd(/* parametres */); // Se connecte à la base de données.
      ~Bdd(); // Se déconnecte de la base de données, si pas déjà déconnecté. Écrit dans un log en cas d'échec de déconnexion.
      void deconnexion(); // Se déconnecte de la base de données. Lève une exception en cas d'échec de déconnexion.
      // ...
  };

[KonTiKI]

Réponse très didactique, j'apprécie beaucoup.

Les exceptions : c'est vrai que je ne suis pas encore arrivé à ce chapitre dans ma lecture (mais il s'approche). Donc je repasse en mode lecture et je recompose le code en fonction.

La lecture des fichiers ini : j'ai beaucoup cherché, mais rien trouvé. j'en suis très étonné d'ailleurs. On en trouve des toutes faites dans le Cbuilder et en VB et VisualC++. De surcroît Microsoft donne des fonctions de compatibilité pour les OS 16bit, mais précise que les fichiers ini ne doivent plus être et qu'il faut maintenant utiliser la base de registre, ce que je ne veux pas faire.

Quant à en faire plusieurs classes, oui j'y avais pensé. J'ai aussi trouvé que ça faisait beaucoup de petits codes dans beaucoup de fichiers. J'ai d'ailleurs pu évoquer dans un autre post le fait de créer une bibliothèque perso pour les agréger.

Je continue dans mon apprentissage mais visiblement tu n'as pas levé d'incohérence (plutôt des optimisations) dans ce que j'ai proposé.

Merci.

[bacelar]

et qu'il faut maintenant utiliser la base de registre, ce que je ne veux pas faire.

Il y a bien des avantages à la base de registre.

Les primitives de lecture pour les fichiers ini dans Win32 fonctionnent toujours, pourquoi réinventer la roue ?

Ok, la roue de M$ est pas super-ronde non plus.

[KonTiKI]

Les primitives de lecture pour les fichiers ini dans Win32 fonctionnent toujours, pourquoi réinventer la roue ?

Parce que la roue semble avoir été crevée...

Car vraiment, j'ai cherché une réponse mais rien à faire.

Ce seraient des fonctions telles que GetPrivateProfileString( ) ou WritePrivateProfileString() ?

Merci pour les précisions.

PS : j'avais bien trouvé ceci : http://docwiki.embarcadero.com/RADSt...nd_TMemIniFile mais j'ai été dans l'incapacité de le mettre en œuvre.

[bacelar]

GetPrivateProfileString( ) ou WritePrivateProfileString()

Oui, entre autres.

[foetus]

Ce seraient des fonctions telles que GetPrivateProfileString( ) ou WritePrivateProfileString() ?

Chaque bibliothèque à son interprétation d'un fichier ini

Par exemple, Microsoft n'autorise pas d'espaces en début de lignes. D'autres si.

[bacelar]

Par exemple, Microsoft n'autorise pas d'espaces en début de lignes.

C'est pire que ça, c'est pas fonction de M$ ou pas, c'est fonction de la version de l'OS, du Service Pack, etc...
Oui, c'est bien pourri, c'est en grande partie pour cela que les .ini, c'est caca.

[KonTiKI]

Tout ça fait quand même beaucoup de travail pour garder trace de l'emplacement d'un fichier de bdd et des paramètres de connexion à un ftp, non ?

Bien sûr, je ne sais pas le faire donc depuis ce matin c'est un énorme boulot de recherche et de tests (qui ne fonctionnent pas d'ailleurs, mais je vais y arriver.).

N'est-ce pas prendre un marteau pour écraser une mouche là ?

J'ai repris un exemple (https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx)donné par MS que j'ai adapté, mais évidemment, ça ne fonctionne pas (comme très souvent d'ailleurs).

La clef n'est pas crée dans le registre avec un "Access denied". Encore un autre problème à résoudre.

Alors des fois, refaire la roue, non ???

[bacelar]

Tout ça fait quand même beaucoup de travail pour garder trace de l'emplacement d'un fichier de bdd et des paramètres de connexion à un ftp, non ?

Oui, clairement, c'est beaucoup de travail complètement inutile et super pas fiable.
Ça fait plus de 20ans que les .ini sont au cimetière de l'informatique, t'es bi-classé nécromancien ???

Et, il y a 25 ans, on faisait pas dans la fioriture, on avait un fichier .INI qui se baladait à coté de l'exécutable.
On utilisait "GetPrivateProfileString" pour récupérer les informations nécessaires.

Et exceptionnellement, on utilisait "WritePrivateProfileString" pour sauvegarder des données, mais souvent on se faisait pas chier, on demandait à l'utilisateur d'éditer lui-même le fichier INI dans un éditeur de texte.

Donc, tout ce salamalec était réglé en 1 appel, basta.

Mais maintenant, on dispose d'autres choses bien plus souple comme la base de registre ou les .config.
C'est presque aussi simple et c'est bien plus souples que les .INI.

je ne sais pas le faire donc depuis ce matin c'est un énorme boulot de recherche et de tests

C'est toujours un peu comme ça au début.

(qui ne fonctionnent pas d'ailleurs, mais je vais y arriver.).

T'es fort au jeu des 7 différences ?
Ligne 17 et ligne 79, c'est pas pareil.

Là, tranquille, vous essayez de créer un fichier "appname.ini" dans le répertoire "Windows" de votre système, au calme, comme un gros bourrin.
Pas de bol, mais la sécurité de Windows a légèrement été renforcée depuis la guerre de Bosnie. https://en.wikipedia.org/wiki/1995

N'est-ce pas prendre un marteau pour écraser une mouche là ?

Là, c'est plus utiliser une tapette en silex alors que les hommes de Cro-Magnon savaient très bien qu'une queue de bovidé sur une hampe est bien plus efficace.

J'ai repris un exemple (https://msdn.microsoft.com/en-us/lib...%29.aspx)donné par MS que j'ai adapté, mais évidemment, ça ne fonctionne pas (comme très souvent d'ailleurs).

Il faut le comprendre et le texte avant l'exemple n'est pas juste décoratif.
Oui, c'est relou, mais c'est pas moi qui est choisi d'utiliser un truc du siècle dernier.

La clef n'est pas crée dans le registre. Pourquoi... et bien, je cherche. Certainement un problème de droit.

Encore heureux que n'importe quel péquin ne puisse pas modifier des clés aussi sensibles.

Alors des fois, refaire la roue ???

Franchement, c'est le genre de truc qu'on règle en 15 secondes.
Vous utilisez correctement votre programme de génération de MSI pour qu'il demande ces informations lors de l'installation. Le MSI a les droits admin lors de l'installation, il colle ces informations dans la base de registre. Votre programme n'a qu'à les lire dans la base de registre, à l'endroit qui lui est réservé par le respect des conventions d'usage de la base de registre. FINI !!!

[Pyramidev]

PS : j'avais bien trouvé ceci : http://docwiki.embarcadero.com/RADSt...nd_TMemIniFile mais j'ai été dans l'incapacité de le mettre en œuvre.

Tu travailles avec C++ Builder ?
Si oui, TIniFile et TMemIniFile sont appropriés.
Sinon, tu ne peux pas utiliser les classes de Embarcadero.

Ça fait plus de 20ans que les .ini sont au cimetière de l'informatique

De mon côté, j'ai travaillé et je travaille sur des logiciels qui utilisent des fichiers INI.
Dans certains cas, le choix du format INI n'était pas judicieux et il aurait été mieux que ce soit du XML.
Mais, si, les fichiers INI existent encore.

[KonTiKI]

Merci Bacelar pour cette belle volée de bois vert.

Il est évidant que la hauteur de vue entre un professionnel du codage et un débutant tel que je suis qui - en plus - a la prétention de faire une petite application, n'est pas du tout la même. Ce n'est peut-être pas nécessaire de le souligner à ce point.

Maintenant, je souhaite quand même utiliser mon droit de réponse.

Oui, le fichier ini existe toujours et je l'ai rencontré... je n'ai d'ailleurs qu'à parcourir mon disque dur pour en décompter très exactement : 830 ! Et de différentes origines telles que Ati, Firefox, Microsoft (oui eux aussi...), HP, Qt, codeBlocks et d'autres. Toutes ces entreprises sont certainement encore à l'age de pierre et doivent en conséquence avoir de vrais problèmes de "super pas fiable"...

Pour le jeu des différence, je me débrouille. Il est vrai que j'ai modifié le nom du fichier dans la première fonction et pas à la fin. Mais encore aurait-il fallu que cette première fonction ne renvoie pas "acces denied" pour que cela pose un problème à la ligne 79. je commence en général par faire en sorte que ma première fonction marche avant de m'intéresser à la dernière.

Et tant que j'en suis à cette étape, la fonction RegCreateKeyEx fait cela : "Creates the specified registry key. If the key already exists, the function opens it. ". En conséquence je ne suis pas un gros bourrin qui essaye de créer un fichier dans le répertoire windows, mais un gros bourrin qui essaye de créer une clef dans le registre. Pour moi, ça fait une différence.

Maintenant sur le plan de l'application, proposer de paramétrer les informations nécessaires via le programme de génération de MSI implique une installation du programme. Et si mon souhait fut que l'application soit simplement "portable" ? Quelle solution appliquer alors ? Toujours travailler dans le registre ?

Merci en tous cas du temps pris pour me répondre, car j'en ai conscience et j'apprécie.

@piramidev :
Et non, je ne travaille pas avec C++ Builder et je me suis bien rendu compte que je n'avais pas de transposition possible sur un C++ "écrit à la main". Comme ce développement est simplement pour moi un TP d'apprentissage, je reste basique, sans framework ni RAD.

Merci.

[Médinoc]

Maintenant sur le plan de l'application, proposer de paramétrer les informations nécessaires via le programme de génération de MSI implique une installation du programme. Et si mon souhait fut que l'application soit simplement "portable" ? Quelle solution appliquer alors ? Toujours travailler dans le registre ?

Personnellement pour une application dite "portable" j'ai un fichier de config dans le répertoire de l'application qui sert juste à dire si l'application est en mode "portable" ou non. Et là, je décide selon le cas:

• Si l'appli est en mode "portable", alors ce sera un (second) fichier de config dans son répertoire.
• Si elle n'est pas "portable", c'est selon le type d'application:
  
  • Pour une application .Net, c'est un fichier de config XML placé quelque part dans le AppData de l'utilisateur (l'emplacement est choisi automatiquement par le framework .Net)
  • Sinon, en théorie ça devrait être le Registre de l'utilisateur (HKCU\Software\Medinoc\MonProgramme); mais si je suis trop paresseux, je ré-utilise le code pour "fichier de config" en le plaçant dans le AppData de l'utilisateur (via SHGetKnownFolderPath() ou une fonction antérieure si je vise un vieux Windows) plutôt que dans celui de l'exe...

En gros, oui, pour une application disposant d'un mode "portable", le .ini (ou quoi que ce soit qui y ressemble) revient en grande force. Mais il faut aussi qu'elle puisse marcher en mode "normal" (avec la config chez l'utilisateur).

Edit: En fait, on peut même se passer du coup d'avoir deux fichiers de config, si l'on fait comme ceci au chargement du programme:

1. Chercher fichier de config dans répertoire du programme. Si trouvé, on est en mode Portable.
2. Si non-trouvé, chercher dans répertoire utilisateur. SI trouvé, on travaille sur le fichier en question.
3. Si aucun des deux n'est trouvé, il faut donc le créer: Demander à l'utilisateur, en faisant en sorte de récupérer proprement l'erreur si l'utilisateur répond "portable" à tord (penser à régler le Manifest du programme pour ne pas avoir la redirection silencieuse par Windows).
   Optionnellement, on pourrait même vérifier si on a les droits d'écriture sur le répertoire du programme avant de poser la question (et si l'on n'a pas accès, ne pas poser la question du tout).

[foetus]

En fait il faut lire entre les lignes de ce que écrit Medinoc

Ton application est dans un dossier racine.

Si tu as un fichier de configuration (dans un dossier ou pas), cela veut dire que soit il est là suite à une installation "en règle", soit il a été créé par l'application.
Et donc cela pose 2 réflexions:

• Est-ce que le dossier racine à les droits d'écriture ou pas? Dans ce cas là, il faudra soit changer de dossier (par exemple AppData) soit passer par la base de registre
• Pour moi (arf Medinoc a édité ), une application portable, c'est une application qui est capable de détecter si les ressources externes qu'elle utilise (DLL, fichier de configuration ... voire même clef de registre) sont présentes, et dans le cas contraire, de pouvoir les régénérer par défaut, en faisant attention aux droits d'écriture.

C'est pour cela que je proposais de coder un FileManager, pour répondre à toutes les problématiques de dossiers

[Médinoc]

]Pour moi (arf Medinoc a édité ), une application portable, c'est une application qui est capable de détecter si les ressources externes qu'elle utilise (DLL, fichier de configuration ... voire même clef de registre) sont présentes, et dans le cas contraire, de pouvoir les régénérer par défaut, en faisant attention aux droits d'écriture.

Le problème, c'est que "portable" a désormais deux sens: Le vieux sens de "facile à porter pour une autre plate-forme", et le nouveau sens de "tient sur une clé USB, entièrement contenue dans son dossier."

Et dans le second sens, il n'est pas censé y avoir de ressources extérieures au dossier. Une appli "portable" contient dans son dossier une copie de tout ce sont elle a besoin (sauf les prérequis VRAIMENT gros comme le Framework .Net, qui n'est pas utilisable sans l'installer de toute façon).

[KonTiKI]

"tient sur une clé USB, entièrement contenue dans son dossier."

Effectivement, c'est bien dans ce sens que j'utilisais "portable" .

Merci Medinoc et foetus pour votre point de vue.

Je remouline tout ça et je vous proposerai une version qui prenne en compte les conseils que vous m'avez tous donnés.

[bacelar]

Moi, je suis un gros lourd.
Les INI, c'est caca.
Je n'ai pas dit que la base de registre était la panacée, mais quitte à passer par des fichiers, les .config (ou tout autre fichier à base de dialecte XML) sont largement plus souples et moins casse-gueule.

Les INI dans sociétés qui fournissent des drivers non pas grand-chose à voir avec les INI des applicatifs.
Les possibilités dans les drivers/mode Kernel sont bien moins évoluées.
Donc pourquoi prendre les boulets de autres quand on a la possibilité de ne pas se faire prendre la tête avec ?
Aucun des applicatifs utilisant ces INI ne fera plus que ce que je vous ai dit, des "GetPrivateProfileString" et puis c'est tout.

Toutes les propositions de mes voisins du dessus peuvent utiliser des .config à la place des .ini, et cela très avantageusement.
Ce qui fonctionne avec un MSI pour modifier la base de registre, fonctionne tout aussi bien avec un .INI ou un .config (faut juste créer un simple programme pour modifier les fichiers).
Ce qui fonctionne avec un MSI fonctionne avec un Autorun.exe sur une clé, sauf pour les problématiques de droits, mais mes voisins du dessus ont déjà données des méthodes de contournement.

Maintenant, je souhaite quand même utiliser mon droit de réponse.

Faites donc, je n'ai pas la science infuse.

je n'ai d'ailleurs qu'à parcourir mon disque dur pour en décompter très exactement : 830

Age moyen de ces machins, si on enlève les trucs liés aux drivers et au mode Kernel ?
Ainsi que les trucs tout moisi, comme les portages de programmes non Windows par des programmeurs qui ni connaissent rien à Windows, coucou codeBlocks, t'es pas encore mort toi ?

je commence en général par faire en sorte que ma première fonction marche avant de m'intéresser à la dernière.

Pour moi, c'est une grosse erreur de débutant. Oui de débutant.
Quand on modifie un paramètre, on le modifie COMPLÈTEMENT, d'où l'utilité de mettre des constantes à part. (Oui, l'exemple est moisi sur ce truc, mais ce n'est qu'un simple exemple).
On voit directement si le changement de paramétrage est compatible avec le code et pas se prendre une peau de banane après trop de boulot (aversion à la perte ....).

Mais encore aurait-il fallu que cette première fonction ne renvoie pas "acces denied" pour que cela pose un problème à la ligne 79.

Ça, c'est fonction du contexte de sécurité.
On commence par les trucs qui vont merder à tous les coups => jeu des 7 erreurs (et lire la documentation)
Puis on vérifie les contraintes, dont les droits. Et quant on en est à modifier un truc dans HKEY_LOCAL_MACHINE, on sait que les droits seront extrêmement sévère.
Donc la solution qui demande ce type de droit doit être étudié => MSI est mon ami.

En conséquence je ne suis pas un gros bourrin qui essaye de créer un fichier dans le répertoire windows, mais un gros bourrin qui essaye de créer une clef dans le registre.

Tu fais les 2. Cf. "grosse erreur de débutant" ci-avant.
Si faire le gros bourrin pour la base de registre, cela ce gère facilement => MSI.
Faire le bourrin dans le répertoire Windows, c'est du nimportnawak.
Lisez la documentation, non d'un chien. C'est vous même qui l'avait fourni, LISEZ-LA !

Et si mon souhait fut que l'application soit simplement "portable" ? Quelle solution appliquer alors ? Toujours travailler dans le registre ?

Avec un AutoRun.exe, oui, mais avec des limitations sur les droits, car on n'est plus administrateur.
La base de registre marche aussi "bien" que l'écriture dans un fichier, donc assez mal dû aux droits d'accès.
Pour les circonvolutions sur l'endroit où mettre les fichiers (des .config, c'est bien mieux que des .ini tout pourri), mes voisins du dessus ont donnés quelques pistes.
Pour la base de registre, c'est du même ordre.

Mais franchement, vous avez une application où vous devez spécifier "le chemin et le nom du fichier bdd, ainsi que les paramètres de connexion d'un ftp local" et vous ne donnez pas à vos utilisateurs la possibilité d'installé/configurer correctement via un MSI, vous n'êtes pas sympa avec vos utilisateurs.

[Médinoc]

Quelles sont les APIs offertes par Windows aux applications non-.Net pour manipuler les fichiers .config?
Je suis intéressé, je n'ai pas encore regardé ça de près (n'ayant rien programmé de gros en non-managé depuis un moment).

[bacelar]

Quelles sont les APIs offertes par Windows aux applications non-.Net pour manipuler les fichiers .config?

Rien que je connaisse, mais toute librairie XML avec XPath devrait faire largement le job, avec un wrapping très light.
http://stackoverflow.com/questions/5...ettings-in-xml
Il y a pas mal de framework comme Boost ou Qt qui offrent directement des classes "wrapper" de setting XML.