Discussion :

[niconol]

Bien le bonsoir,
j'ai oragnisé ma classe

periph

grâce à cette faq:
https://cpp.developpez.com/faq/cpp/?...un-fichier-cpp

avec une déclaration dans classes.h

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
#ifndef CLASSES_H
#define CLASSES_H
#include <string>
/************************************************************************/
/* déclaration d'une classe periph pour les périphérique de stockage USB */
/************************************************************************/
class periph {
  public:
    std::string source;
    std::string target;
    const char* type = "vfat";
    const unsigned long mntflags = 0;
    const char* opts = "";
    int status;
    std::string dir;
  //
    periph() {}
    periph(std::string src, std::string tgt): source(src), target(tgt){}
 
    bool monte();
    bool demonte();
    void mkdirdate();// création d'un dossier "target" horodaté
 
   ~periph() {}
};
 
extern std::string s;
extern std::string t;
extern periph clef(std::string, std::string);
 
#endif

un include dans les fichiers .ccp auxquels je veux donner accés à cette classe

Code :

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

#include "classes.h"

et un classes.cpp pour définir la classe et construire

clef

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
#include "classes.h"
#include "define.h"
#include "file.h"
#include <sstream>
#include <fstream>
#include <sys/mount.h>
#include <sys/stat.h>  //pour ACCESSPERM
 
using namespace std;
/************************************************************************/
/* définition des fonctions de classe périph */
/************************************************************************/
bool periph::monte() {
  ostringstream tmpStr;
  status = mount(this->source.data(), this->target.data(), this->type, this->mntflags, this->opts);
  if (this->status == 0) {
    tmpStr <<  "        clef " << this->source << " montée TRUE";
    out(TERM|SESS,tmpStr.str());
    return true;}
  else {
    tmpStr <<  "        clef " << this->source << " montée FALSE" << this->status;
    out(TERM|SESS,tmpStr.str());
    return false;}
}
 
bool periph::demonte(){
  ostringstream tmpStr;
  status = umount(target.data());
  if (this->status == 0) {//cout <<  "        clef " << this->source << " démontée TRUE" << endl;
    tmpStr <<  "        clef " << this->source << " démontée TRUE";
    out(TERM|SESS,tmpStr.str());
    return true;}
  else {//cout << "        clef " << this->source << " démontée FALSE" << endl;
    tmpStr <<  "        clef " << this->source << " démontée FALSE";
    out(TERM|SESS,tmpStr.str());
    return false;}
 }
 
void periph::mkdirdate() {// création d'un dossier "target" horodaté
  string nom_rep = target;
  date = horodatage();
  nom_rep.append("/");
  nom_rep.append(date);
  this->dir = nom_rep;
  status = mkdir(nom_rep.data(), ACCESSPERMS);
// fichier de log des ccorr directement dans le dossier de photos
  string nom_fichier = nom_rep.data();
  nom_fichier.append("/log.cco");
  logSalve.open(nom_fichier.data());
  out(TERM|SESS|SALV,nom_fichier.data());
}
 
std::string s = "/dev/sda1";
std::string t = "/mnt/tmp";
periph clef(s, t);

les fichiers .cpp contenant des appels du type

clef.demonte();

génèrent cette erreur à la compil:

Code :

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

/.............../pict.cpp|195|error: request for member ‘demonte’ in ‘clef’, which is of non-class type ‘periph(std::string, std::string) {aka periph(std::basic_string<char>, std::basic_string<char>)}’|

le fichier pict.cpp contient bien un include vers classes.h, mais il est vrai que je ne sais pas trop où je dois déclarer et définir clef, et comment le partager entre plusieurs fichier.

Quelqu'un peut-il m'aider svp?

Merci

[dalfab]

En écrivant extern periph clef(std::string, std::string); que penses-tu déclarer?
C'est bien une fonction n'est-ce pas?

[niconol]

ah, ben c pas ce que je veux faire
je souhaitais déclarer l'objet "clef" de la classe "periph"

[niconol]

et forcément, si à la place je déclare comme ceci

extern periph clef

ça marche beaucoup mieux

c'était donc ça ? c'est correct et dans les règles de l'art maintenant?

merci beaucoup dalfab, d'autant que j'apprécie ta réponse en forme de question qui pousse à réfélchir...

[Bousk]

Correct : oui puisque ça compile.
Dans les règles : bof, pourquoi créer un unique objet partagé ainsi qui sera global et ne pas le créer tout simplement dans le main ?

[bacelar]

Réponses rhétoriques.

Correct : oui puisque ça compile.

C'est SYNTAXIQUEMENT correct (et encore, d'autres compilateurs ou d'autres réglages peuvent rendre cela incorrect).
Il faut aussi s’ôter de la tête ce sophisme très répandu chez les débutants "Ça compile donc ça marche".
NON !!!

Dans les règles : bof, pourquoi créer un unique objet partagé ainsi qui sera global et ne pas le créer tout simplement dans le main ?

Illustration du "syntaxiquement correct" est différent du "correct pour faire du code fiable et maintenable dans le temps".

Le questionnement socratique a le vent en poupe ou le pauvre PO @niconol fait-il les frais d'une expérience pédagogique ?

[dalfab]

c'est correct et dans les règles de l'art maintenant?

merci beaucoup dalfab, d'autant que j'apprécie ta réponse en forme de question qui pousse à réfélchir...

Tu ajoutes deux questions.
* Le code est effet correct.
* Et tu demandes aussi si c'est dans les règles de l'art. A ceci tu as obtenu des réponses fournies sur l'utilisation de variables globales. Ici les trois variables s, t et clef non seulement sont globales mais aussi publiques car déclarées dans un fichier d'entête.
Pour une toute-petite application c'est déjà perturbant, imagine une application de centaines de fichiers voire plus (oui on y arrive vite!), tous verraient des variables avec un risque d'oublier leur rôle et leur dynamique. L'idée est de ne rendre visible que ce qui sert aux autres modules, les règles de l'art consistent donc à limiter et même proscrire les globales.
De même ta classe periph a tous ses membres publics. Là aussi les règles de l'art préconisent de ne rendre public qu'une ou deux fonctionnalités fournies par ta classe afin que l'utilisation tes objets periph soit plus limpide pour les futurs lecteurs de ton code dont tu es le plus représentatif.

Alors ici, faut-il conserver la globale clef? Il est vrai que dans un code petit et simple, ce qui est important c'est que tu t'y retrouves et donc pourquoi pas. Dans un code plus "professionnel", elle peut être remplacée par d'autres structures que tu risques certainement de trouver complexe aujourd'hui.