Aide pour liaison de class

Version imprimable

Voir 40 message(s) de cette discussion en une page

03/07/2025, 15h40
ludoiphone

faut que je retourne un bool dans l'objet gainable , par exemple : bool froid pour pour lancer l'objet froid avec une boucle while dans main avec if (froid == true) {objet froid}

mais ce que j'arrive pas trop a faire c'est les parametres de class et des fonctions .

Quand le code commence à être conséquent en taille, il vaudrait mieux utiliser des dépôts de code en ligne comme Github ou Gitlab.
Comme vos questions sont plus de l'ordre de la conception, poster une version "réduite" du code n'est vraisemblablement pas encore très pertinent.

Citation:

pour pouvoir faire un heritage entre l'objet Gainable et l'objet Froid

Attention avec l'héritage.
C'est le lien le plus fort entre des classes en C++, rendant ces classes très interdépendantes.
Généralement, on cherche à découpler le plus possible les classes.
Généralement, on utilise l'héritage quand on veut profiter du LSP ( https://alfps.wordpress.com/2012/03/...rinciple-in-c/)
Je ne crois pas que cela soit le cas entre un objet "Gainable" et un objet "Froid".
A moins qu'un "Froid" soit un type particulier de "Gainable" ?

La règle "est un" entre une classe mère et une classe fille (la classe fille "est une" spécialisation de la classe mère) n'est qu'une simplification d'une vraie règle plus complexe.
Cette simplification peut être trompeuse : un carré est un rectangle en mathématique mais tu ne devrait pas faire hériter ta classe "carré" d'une classe "rectangle".
Idem pour les classes "Point" et "PointColoré".
Mais en première analyse, la règle "est un" peut convenir.

Donc, faire hériter "Froid" de "Gainable", je suis très circonspect.

Citation:

pour integré les pins de la class gpiopin dans le gainable.h

Pourquoi "intégrer" gpiopin dans la classe gainable ???

Le code que vous avez posté le 03/04/2005 à 15h40 semble montrer un code proche d'une implémentation+utilisation d'un Design Pattern "Singleton".
C'est une bonne idée de faire appel à ce type de Design Pattern, mais je vous conseille de regarder comment les implémenter de manière plus simple et plus fiable avec quelques recherches via Google (ou peut-être avec nos nouveaux amis IA).
Avec le nom du Design Pattern, vous aurez des implémentations, mais aussi les limitations à leur usage, tout cela en interrogeant Google ou une IA.

Moi, je vous conseille de circonscrire les fonctions liées au hardware dans un espace de noms dédié.
Si vous changez de hardware, vous n'aurez qu'à changer le code dans cet espace de noms sans avoir à changer le reste de votre code.
Mais pour cela, il faudrait que vos fonctions soit plus simple d'utilisation, sans avoir à connaitre comment le hardware fait ça tambouille.
Code:

1 2 3 4 5 namespace pins{ void digitalWrite (int pin,int output); int digitalRead (int pin); }
(Il faudrait peut-être réflechir un peu plus à comment rendre l'interaction avec le hardware plus souple)
Le reste devrait être "caché" dans un .cpp dédié.
Citation:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 void compteurFiltreFroid(); void etatMarcheFroid(); void tempoVolets(); void etatVoletsFroid(); void etatControleTemperatureFroid(); void etatDepartCanicule(); void etatDepartFroid(); void etatVentilationsFroid(); void etatVentilationsCanicule(); void etatV4VFroid(); void etatCompresseurFroid(); void etatControleDegivrageFroid(); void etatControleTemperatureDegivrageFroid(); void etatFinDegivrageFroid(); void etatEgouttageFroid(); void etatFinEgouttageFroid(); void etatArretFroid();
Je ne trouve vraiment pas le nom de vos fonctions très explicite.

Il est très rare qu'une fonction "void NomALaNoix()" est une signature très judicieuse.
Citation:
Code:

1 2 3 void Froid::modeFroid() { while (1) {
Une attente active ?
Je ne crois pas que votre code soit vraiment près pour ce genre d'acrobatie, ni pour du multithreading.
Je pense que vous devriez prendre un peu plus de temps pour bien analyser et structurer votre projet.
Vous devriez avoir en tête une architecture simple, au moins au démarrage.

Je crois que vous devriez regarder du côté du Design Pattern "Stratégie".

Essayez de "verbaliser" votre architecture, avec nous, par exemple. Pour voir où des Design Pattern sont nécessaire ou pratique.
Citation:
Code:

1 2 Gainable *mainGainable; mainGainable = new Gainable();
Je ne sais pas où vous avez "appris" à coder comme cela, mais clairement pas ma bonne.
J'avais déjà signalé que votre source/support d'apprentissage du C++ n'est vraiment pas bon.

Code:

Gainable mainGainable{};

03/07/2025, 22h03
ludoiphone

ok merci, je vais essayer de verbaliser tous ca , et je le posterais merci
04/07/2025, 19h36
ludoiphone

1 pièce(s) jointe(s)

j'ai fais ce diagramme , si il ya des choses a modifier je suis a l'ecoute merci

Pièce jointe 668562
08/07/2025, 19h46
bacelar

Il n'y a pas "une" conception correcte pour une situation.
La conception est très dépendante de l'objectif du projet.

Donc, comme on n'a pas tous les tenants et aboutissants du projet, on ne peut pas dire si vous fait fausse route avec cette conception.

Mais :
Votre diagramme ne semble pas suivre à la lettre les recommandations UML.
En UML, ce type de diagramme (objet ? classe ?) n'est pas forcement l'un des premiers à concevoir pour une analyse "sereine".
Les types des attributs semble "complexes".
Vous ne devriez pas avoir de détails d'implémentation visibles dans ce genre de diagramme.
Donc, les attributs, ça devrait être "exceptionnels".
Vous mélangez plusieurs couches/module : IHM ne devrait pas avec les classes/objets "métier".

Votre code devrait fonctionner quelque soit le type d'IHM, console, Qt, GUI natif, etc...

Essayez déjà de verbaliser avec des phrases.
Des diagrammes de séquence ou des "use case diagramme" UML sont plus faciles à faire au début d'un projet.

On commence :
Gainable : ça représente quoi ?
ça fournit quoi comme services (en se fout de comment il implémente ces services) ?
09/07/2025, 14h20
ludoiphone

un gainable est un systeme de chauffage et de refroidissement ; il se trouve dans deux endroits : un compresseur, une vanne 4Voies et un ventilateur a l'exetrieur et un ventilateur et un système de clapets (en fonctions des pieces as chauffer ou as refroidir) a l'interieur dans les combles au dessus du plafond .
les deux parties (exterieur et interieur) sont relier par des tuyau en cuivre pour la circulation du gaz.

le compresseur et les ventilateurs fonctionnent aussi bien en chauffage qu'en refroidissement .
la vanne elle fonctionne qu'en froid.

le tous est gerer via des temporisations et des sondes (ext(nord), unité exterieur , echangeur exterieur , unité interieur et echangeur interieur).
10/07/2025, 10h21
bacelar

Ok, vous décrivez ce que s'est ; pas à quoi va servir le projet.

Si le but est de fournir un panneau de contrôle utilisable par un enfant de 10 ans, ça sert à rien de présenter tous ces détails dans l'interface du "gainable".

Commencez par savoir ce que va offrir votre logiciel => les "use case" devraient être les premiers spécifiés.

Les temporisations doivent-elles être implémentées par votre "système" ou c'est déjà "physiquement" implémenté ?
10/07/2025, 15h12
ludoiphone

le projet vas servir a remplacer ce que j'utilise deja ( un miltitude de regulateur de temperature ) , pour le controle oui il le faudras ,car ma femme ou autre personne ne sont pas a l'aise avec des interface compliquer .

les temporisations son as integré au systeme .

re pour voir le fonctionnement des setter getteur ,
je n'arrive pas as rendre mon bool (true ou false) de l'objet gainable dans l'objet froid .

en faite j'arrive bien as le changer dans ma class gainable mais il ne bouge pas dans la class froid .

je l'affiche avec des qDebug() << "departFroid" << departFroid .

je doit mal mis prendre . merci de m'aider .

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
#include "gainable.h"
#include "froid.h"
 
#include <QDebug>
 
int main(int argc, char *argv[])
{
    Gainable mainGainable;
    Froid mainFroid;
 
    while (1) {
        time_t rawtime;
        time ( & rawtime);
        qDebug() << ctime ( & rawtime);
 
        mainGainable.modesGainable();
        mainFroid.modeFroid();
 
        sleep(1);
    }
    return 0;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
class Gainable
{	    
	public:
	    Gainable();
 
	    ~Gainable();
 
	    bool departFroid;
 
	    void modesGainable();
 
	    void setDepartFroid(bool marcheFroid);
 
	    bool getDepartFroid();

Code:

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
 
#include "gainable.h"
 
#include <QDebug>
 
#include "gpioPin.hpp"
 
#define OFF HIGH
#define ON LOW
 
const int thermostats = 17;
 
Gainable::Gainable()
{
	pinMode (thermostats, INPUT_PULLUP);
}
 
Gainable::~Gainable()
{
 
}
 
void Gainable::setDepartFroid(bool marcheFroid)
{
	departFroid = marcheFroid;
}
 
bool Gainable::getDepartFroid()
{
	return departFroid;
}
 
void Gainable::modesGainable()
{
	setDepartFroid(true);
 
	qDebug() << "departFroid de gainable" << departFroid;

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
#include "gainable.h"
 
class Froid: public Gainable
{
 
public:
    Froid();
 
    ~Froid();
 
    bool degivrageFroid = false;
 
    void modeFroid();
 
private:

Code:

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
 
#include "froid.h"
 
#include <QDebug>
 
#include "gpioPin.hpp"
 
#define OFF HIGH
#define ON LOW
 
const int thermostats = 17;
 
Froid::Froid()
{
    froidDs18b20 = new DS18B20();
 
    pinMode (thermostats, INPUT_PULLUP);
}
 
Froid::~Froid()
{
    qDebug() << "destructeur Froid";
}
 
void Froid::modeFroid() 
{
    qDebug() << "departFroid" << departFroid;

bonjour a vous , donc je me suis inspirer de la patterns strategie , voila ceux que j'ai commencer as faire :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
#include <iostream>
 
#include "gainable.h"
 
using namespace std;
 
int main(int argc, char *argv[])
{
    Gainable mainGainable;
 
    while (1) {
        time_t rawtime;
        time ( & rawtime);
        cout << ctime ( & rawtime) << endl;
 
        mainGainable.modesGainable();
 
        sleep(1);
    }
    return 0;
}

Code:

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
 
#ifndef GAINABLE_H
#define GAINABLE_H
 
#include <iostream>
 
#include "ds18b20.h"
#include "froid.h"
#include "chauffage.h"
 
using namespace std;
 
class Gainable
{
	Froid* gainableFroid;
 
	Chauffage* gainableChauffage;
 
	void SetModes(Froid* froid, Chauffage* chauffage);
 
	DS18B20 *gainableDS18B20;
 
public:
    Gainable();
    ~Gainable();
 
	void modesGainable();
};
 
#endif // COMMANDE_H

Code:

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
 
#include "gainable.h"
 
#include "gpioPin.hpp"
 
#define OFF HIGH
#define ON LOW
 
const int thermostats = 17;
 
Gainable::Gainable(): gainableFroid(), gainableChauffage()
{
	pinMode (thermostats, INPUT_PULLUP);
 
	gainableDS18B20 = new DS18B20();
}
 
void Gainable::SetModes(Froid* froid, Chauffage* chauffage)
{
	if (froid != 0)
	{
		delete gainableFroid;
		gainableFroid = froid;
	}
 
	if (chauffage != 0)
	{
		delete gainableChauffage;
		gainableChauffage = chauffage;
	}
}
 
void Gainable::modesGainable()
{	
	gainableDS18B20 ->tempExt();
 
	if (gainableDS18B20 ->tempExtLue <= 13.5)
	{
		gainableChauffage ->modeChauffage();
	} else {
		gainableFroid ->modeFroid();
	}
}
 
Gainable::~Gainable()
{
	delete gainableFroid;
	delete gainableChauffage;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#ifndef FROID_H
#define FROID_H
 
#include "ds18b20.h"
 
#include <iostream>
using namespace std;
 
class Froid
{
public:
    Froid();
    virtual ~Froid() = 0;
 
    void modeFroid();
};
 
#endif //FROID_H

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#include "froid.h"
 
#include <ctime>
 
Froid::Froid()
{
    froidDs18b20 = new DS18B20();
}
 
void Froid::modeFroid() 
{
    cout << "modeFroid()" << endl;
}
 
Froid::~Froid()
{
    cout << "destructeur Froid" << endl;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
#ifndef CHAUFFAGE_H
#define CHAUFFAGE_H
 
#include <ctime>
 
#include <iostream>
using namespace std;
 
class Chauffage
{
public:
    Chauffage();
    virtual ~Chauffage() = 0;
 
    void modeChauffage();
};
 
#endif //CHAUFFAGE_H

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
#include "chauffage.h"
 
Chauffage::Chauffage()
{
 
}
 
void Chauffage::modeChauffage()
{
    cout << "modeChauffage()" << endl;
}
 
Chauffage::~Chauffage()
{
 
}

16/07/2025, 11h49
bacelar
Citation:

le projet vas servir a remplacer ce que j'utilise deja ( un miltitude de regulateur de temperature ) , pour le controle oui il le faudras ,car ma femme ou autre personne ne sont pas a l'aise avec des interface compliquer .

Je ne vois toujours pas les "use case" dans vos messages.
Il vaut mieux analyser les contraintes et objectifs du projet avant de commencer à coder, surtout quand on a peu d'expériences.

Vous devriez utiliser des méthodes types "diviser pour mieux régler" : découper le projet en parties plus petites avec des objectifs plus faciles, pour commencer.

Ici, dans le code que vous publiez, je ne vois aucun découpage en "sous-projets/modules".

Je vois déjà 2 parties complètement indépendantes dans votre projet : l'IHM du projet, et le pilotage physique du matériel.
Cela devrait être dans au moins 2 modules complétement dissociés, aucune classe ne devrait être à la fois dans l'un et dans l'autre.

Vous devez modéliser votre IHM de manière complètement indépendante du reste.
Vous inquiétez pas, en logiciel, on peut toujours réconcilier des vues différentes d'un "problème".

Vous devriez aussi modéliser comment votre système interagit avec le matériel thermique de manière à ce qu'il soit adaptable à plusieurs systèmes physiques ou à l'évolution de ce système.

Citation:

les temporisations son as integré au systeme .

Alors évitez comme la peste les attentes actives à ase de "while(1)" qui se baladent dans votre code.
Il existe bon nombre de manière de faire : messages à la Qt, pompe à messages, timers avec callback, etc...
Evitez de prendre des solutions qui "bloquent" un peu trop l'évolutivité du projet (comme les signaux Qt qui vous tanque dans Qt only).

Code du "12/07/2025, 22h54" :
Vous n'avez pas du tout compris l'utilisation de l'héritage, mais le code suivant semble montrer que vous avez progressé de vous-même sur le sujet.
L'héritage, il faut sans servir uniquement quand c'est nécessaire, pas pour faire "joli". ;)

Vous utilisez énormément "qDebug()", pensez plutôt à utiliser un débugueur interactif, bien plus pédagogique.

Citation:

while (1)

à moins d'utiliser une pompe à message, à éviter comme la peste.

Citation:

je n'arrive pas as rendre mon bool (true ou false) de l'objet gainable dans l'objet froid .

J'ai l'impression que vous confondez classe et "objet/instance". Il faut que cela soit clair pour vous.
J'ai l'impression que l'objet "mainGainable" et "mainFroid" était liés par un lien "télépathique", il n'y a rien de "télépathique" en programmation.

Vous ne nous avez toujours pas donné votre source principale d'apprentissage du C++. J'ai l'impression qu'elle est de très mauvaise "qualité".
Le cours de C++ en français de Zeste de savoir a très bonne réputation.

Pourquoi les fonctions "modesGainable" et "modeFroid" ? Pourquoi ne pas utiliser les constructeurs ?
Citation:
Code:

1 2 3 4 5 6 7 8 const int thermostats = 17; Froid::Froid() { froidDs18b20 = new DS18B20(); pinMode (thermostats, INPUT_PULLUP); }
ARRETEZ AVEC LES "new", BORDEL !!!

Il y a du copier-coller de code, c'est jamais bon.
Pourquoi "const int thermostats = 17" à 2 endroits ???
Il est bien plus fiable de le mettre à un seul endroit et les 2 codes "inclus" cet endroit (un "pindefs.h" par exemple).
Pourquoi c'est dans "gainable.cpp" et "froid.cpp" et pas dans un simple "Thermostat.cpp" et cacher tout ce qui est lié à un thermostat dans une classe dédiée, quitte à mettre le "DS18B20" dans cet classe (si c'est plus logique, j'y connais rien en chauffage) ?

Vous avez mis des "getteur/setteur" :
Citation:
Code:

1 2 3 void setDepartFroid(bool marcheFroid); bool getDepartFroid();
Mais c'est quoi "DepartFroid" ???
C'est un évènement, pas un "status/variable d'état" de "Gainable", ou cela ne devrait pas l'être.
Quel est l'intérêt pour du code extérieur à la classe "Gainable" de pouvoir lire cet information sur l'état interne de l'objet ?
Savoir que le froid est enclenché, c'est plutôt 'FroidEnabled", non ?
Déclencher le froid, c'est pas plutôt l'objet "Gainable" qui doit savoir quand le déclencher lui-même, non ?

Code du "13/07/2025, 21h43" :
C'est mieux car vous ne faite pas de l"héritage "pour rien".
Mais vous avez de très grosses lacunes déjà signalées sur le poste d'avant.
Zeste de savoir est ton ami.

Le pattern "Stratégie" est assez mal compris, mais il faut avoir une bonne maitrise de la POO ((en particulier, la notion d'interface) pour l'utiliser correctement.
Et je ne suis pas sûr qu'il soit adapté à votre problème, vu que vous ne verbalisez toujours pas votre projet. ((du code, c'est pas une description du projet)
Vous vous lâchez sur les pointeurs "nus" (toto* ), alors que vous NE devriez PAS utiliser de pointeurs.
Je le redis, le cours sue vous suivez pour apprendre le C++ est une catastrophe, même si je ne le connais toujours pas.

Quels sont les services offerts par la classe "DS18B20", par la classe "Gainable" par la classe "Froid", par la classe "Chauffage" ?
Pour moi, c'est vraiment pas clair.

Commencez par analyser la problématique/ le projet avant de pisser du code (et changez de cours de C++ RAPIDEMENT).

j'ai appris un peux a droite et gauche sur google et apres tous seul en faisant pas mal d'essais.

pour le use case je vois pas par ou commencer , j'ai tous dans ma tete , je vais essayer d'en creer un .

les temporisations sont tres nombreuse dans mon projets ; je connais que celle avec timer(NULL)
Code:

1 2 3 4 5 6 7 if (time(NULL) - chrono >= deltaT) { chrono = time(NULL); mainDS18B20.tempExt(); cout << "tempExtLue " << mainDS18B20.tempExtLue << endl; }
pour les "new" c'est pour eviter les fuite de memoires d'apres certain cours en poo.

j'ai changer les qdebug par cout <<"test"<<endl;

pour les DS18B20 , je le mettait dans les deux ,car j'en avais besoin pour lire le fichier qui contient les relever de temperature sondes par sondes
la aussi peut-etre que mon code pour les sondes est pas bon non plus .:oops:

j'ai transformer ce que j'ai fais plus haut , avec une class thermostat.
mais avec des news pris sur l'exemple que j'ai trouver sur developpez.net (strategie AI)

j'aimerais un lien ou on apprend bien le c++ si vous en connaisser (zeste de savoir) par exemple .

desoler de vous demoraliser , avec la maniere que j'ai apris , mais c'est quand meme difficile as distance et surtout sur forum . mais bon ca m'aide quand meme .
vous aller finir chauve comme moi a se tirer les cheveux avec des debutant comme moi :ptdr:

attention encore 2 new

Code:

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
 
#include <iostream>
#include <ctime>
 
#include "thermostat.h"
#include "ds18b20.h"
 
time_t rawtime;
 
const int deltaT = 2;
unsigned long long chrono;
 
int main(int argc, char *argv[])
{
    Thermostat mainThermostat;
    DS18B20 mainDS18B20;
 
    while (1) 
    {
        time ( & rawtime);
        cout << ctime ( & rawtime) << endl;
 
        if (time(NULL) - chrono >= deltaT)
        {
            chrono = time(NULL);
            mainDS18B20.tempExt();
            cout << "tempExtLue " << mainDS18B20.tempExtLue << endl;
        }
 
        mainThermostat.lectureTemperatureExt(mainDS18B20.tempExtLue);
        mainThermostat.productions();
    }
    return 0;
}

Code:

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
 
#ifndef THERMOSTAT_H
#define THERMOSTAT_H
 
#include <iostream>
 
#include "commande.h"
#include "froid.h"
#include "chauffage.h"
 
using namespace std;
 
class Thermostat
{
    double m_tEL;
 
    Commande* thermostatCommande;
 
    void SetCommande(Commande* commande);
 
public:
    Thermostat();
    ~Thermostat();
 
    void lectureTemperatureExt(double tEL);
    void productions();
};
 
#endif // THERMOSTAT_H

Code:

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 "thermostat.h"
 
#include "gpioPin.hpp"
 
#define OFF HIGH
#define ON LOW
 
const int thermostats = 17;
 
Thermostat::Thermostat() : thermostatCommande()
{
	pinMode (thermostats, INPUT_PULLUP);
}
 
void Thermostat::productions()
{
	if (digitalRead(thermostats) == ON)
	{
		if (m_tEL < 13.5) {
			cout << "modeChauffage" << endl;
			SetCommande(new Chauffage);
		} else {
			cout << "modeFroid" << endl;
			SetCommande(new Froid);
		}
		thermostatCommande ->modes();
	}
} 
 
void Thermostat::SetCommande(Commande* commande)
{
	if (commande != 0)
	{
		delete thermostatCommande;
		thermostatCommande = commande;
	}
}
 
void Thermostat::lectureTemperatureExt(double tEL)
{
	m_tEL = tEL;
}
 
Thermostat::~Thermostat()
{
	delete thermostatCommande;
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
#ifndef COMMANDE_H
#define COMMANDE_H
 
#include <iostream>
using namespace std;
 
class Commande
{
 
public:
    void modes();
 
    virtual ~Commande() = 0;
protected:
    virtual void Analyser() = 0;
    virtual void Appliquer() = 0;
 
};
 
#endif // COMMANDE_H

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#include "commande.h"
 
void Commande::modes()
{
	Analyser();
	Appliquer();
	cout << "======" << endl;
}
 
Commande::~Commande()
{
 
}

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
#ifndef FROID_H
#define FROID_H
 
#include <iostream>
using namespace std;
 
#include "commande.h"
 
class Froid: public Commande
{
    void Analyser();
    void Appliquer();
};
 
#endif //FROID_H

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
#include "froid.h"
 
#include <ctime>
 
void Froid::Analyser()
{
    cout<<"controle temperatures"<<endl;
}
 
void Froid::Appliquer() 
{
	cout<<"fabrication du refroidissement"<<endl;
}

17/07/2025, 20h17
Obsidian

Merci de nous avoir une fois encore partagé ton code. Quelques remarques :

Citation:

Envoyé par ludoiphone

pour les "new" c'est pour eviter les fuite de memoires d'apres certain cours en poo.

C'est le contraire. Il reste sûr — en soi — d'utiliser new si c'est justifié, à condition d'être certain de l'avoir associé à un delete quelque part et de s'être assuré que le delete en question est atteignable. Si tu utilises new sans delete (et que tu ne te trouves pas dans un framework qui gérerait ça pour toi, ce qui resterait sale), tu introduis automatiquement une fuite de mémoire.

Si tu n'en as que quelques uns dans ton code et que la durée de vie de tes objets est celle de l'application, tu ne t'en rendras pas compte parce que le système fera le ménage pour toi. Il reste que ces fuites sont bien présentes et, ce qui est plus grave, même si la mémoire sera libérée par le système (ce qui n'était pas garanti sur de très vieilles plateformes comme les premières versions de DOS), les éventuelles actions à mener au préalable par le destructeur ne le seront jamais.

Par ailleurs, new te renvoie un pointeur sur l'objet concerné, pointeur que tu vas déposer dans une variable. C'est une bonne pratique de nettoyer le contenu de la variable (la remettre à NULL) après avoir libéré l'objet avec delete. La règle est valable également en langage C avec malloc() et free(), par exemple.

Citation:

j'aimerais un lien ou on apprend bien le c++ si vous en connaisser (zeste de savoir) par exemple .

Regarde le bandeau de haut de page, tu y trouveras plein de ressources :

F.A.Q. C++
Cours et tutoriels C++
Livres C++
etc.

Citation:

desoler de vous demoraliser , avec la maniere que j'ai apris , mais c'est quand meme difficile as distance et surtout sur forum . mais bon ca m'aide quand meme . vous aller finir chauve comme moi a se tirer les cheveux avec des debutant comme moi :ptdr:

En fait, et pour rebondir sur la précédente question, j'ai regardé un peu le contenu de ton code et même si je vois que tu l'as rédigé du mieux que tu le pouvais, une question me vient à l'esprit : es-tu au clair sur la notion de « classe » en soi et sur l'héritage en particulier ?

Cela ne pose pas de problème en l'état. Tu définis tes classes en isolant bien chaque notion l'une de l'autre et les seules fois où elles héritent, cela n'est que pour les besoins de Qt. Donc rien de critique en soi pour le moment, mais cela vaut peut-être le coup de commencer par là…
18/07/2025, 12h13
ludoiphone

1 pièce(s) jointe(s)

j'ai fais un petit "use case"

Pièce jointe 668836

dite moi ci cela convient ou ci cela vous parle

Citation:

j'aimerais un lien ou on apprend bien le c++ si vous en connaisser (zeste de savoir) par exemple .

https://zestedesavoir.com/tutoriels/...-en-c-moderne/
Une version plus avancée en POO peut-être ici :
https://zestedesavoir.com/contenus/b...-en-c-moderne/

Citation:

j'ai appris un peux a droite et gauche sur google et apres tous seul en faisant pas mal d'essais.

Je pense que, malheureusement, quelques-unes de ces sources soient plus o moins frelatés. :aie:
Prenez un peu de temps à désapprendre des choses en lisant attentivement le cours de Zeste de Savoir sur le C++.

Citation:

pour le use case je vois pas par ou commencer , j'ai tous dans ma tete , je vais essayer d'en creer un .

Vous n'avez pas à vous prendre la tête normalement.
Pas besoin d'être exhaustif au départ.
Les cas simples en premier :
- Comportement du système sans action humaine s'il fait à l'extérieur 0°C à 7h, 15°C à 12h, 18°C à 17h ...
- Comportement du système si l'utilisateur appuie sur le bouton "A" quand il fait 0°C dehors et 20°C à l'intérieur
etc...

Vous n'avez pas à savoir comment ça fonctionne mais comment le système est sensé réagir et savoir les paramètres extérieurs pertinents pour le projet.

Citation:

les temporisations sont tres nombreuse dans mon projets ; je connais que celle avec timer(NULL)

C'est un peu limité. :aie:
C'est une brique de base, très très bas niveau. Mais l'avantage, c'est que ça marche tout le temps, mais avec pas grand-chose de fait pour vous aider à l'utiliser "correctement" (cf. usage avec des Framework graphiques, etc...).
Mais maintenant, le C++ (le C semble plus "conservateur" dans le domaine) contient énormément d'outils de bien plus haut niveau, comme "std::async" (https://en.cppreference.com/w/cpp/thread/async.html).
Mais comme tout outil de haut niveau, il faut analyser si c'est tel ou tel outil qui faut prendre en fonction du besoin "réel".
=> Analyser les besoins "concrets" du projet.
En vous lançant directement dans le code, vous risquez de faire des "choix" (ou des non-choix par ignorance) qui hypothèqueront potentiellement grandement la suite du projet.
En utilisant une attente active "while(true){...}", vous réduisez grandement les possibilités d'utiliser des solutions techniques de "haut niveau".

Citation:

pour les "new" c'est pour eviter les fuite de memoires d'apres certain cours en poo.

La réponse de @Obsidian est apparu pendant la rédaction de cette réponse.
Je suis assez d'accord avec, sauf que je suis bien plus circonspect sur la justification de l'usage de pointeurs "nus".

Citation:

j'ai changer les qdebug par cout <<"test"<<endl;

Il faudrait que vous preniez l'habitude d'"être fainéant". :mouarf:
Plutôt que de changer tout votre code à chaque fois qu'on vous indique de changer tel machin ou tel autre, faites en sorte que la modification soit "efficace".
Ici, si vous avez vraiment besoin de trace (Je réitère que pour du débuging "précoce", les points d'arrêt dans un débugueur interactif est bien plus productif), il vaudrait mieux utiliser une MACRO type "TRACE(level,msg)".
Ainsi, vous n'avez qu'à changer l'implémentation de la MACRO pour vous adapter, et préparer un passage vers un "vrai" Framework de trace.
Citation:
Code:

1 2 3 4 5 6 if (time(NULL) - chrono >= deltaT) { chrono = time(NULL); mainDS18B20.tempExt(); cout << "tempExtLue " << mainDS18B20.tempExtLue << endl; }
Ça l'avantage d'être simple, mais, dans ce cadre, comment gérer l'affichage d'une IHM qui demandes des entrées utilisateurs ? Comment gérer des temps de temporisations différentes ? Comment gérer des interactions avec d'autres programmes (IPC), le réseau (perte de connectivité, etc...), des alertes ou alarmes de niveau système, etc ... ? Comment gérer le fait que des périphériques ne répondent pas instantanément ? Comment gérer le fait que des périphériques "push" l'information et n'attendent pas que votre bidule les "poll" ? etc...
=> Analyser le projet avant de faire des "choix". :aie:

En profitant de l'utilisation des getteurs, ce code devrait être bien plus simple :
Code:

1 2 3 4 5 6 7 8 if (time(NULL) - chrono >= deltaT) { chrono = time(NULL); Temperature temp_ext = mainDS18B20.getTempExt(); TRACE(TRACE_LEVEL_DEBUG,temp_ext); }
"getTempExt" appelle "tempExt" si nécessaire.

Citation:

pour les DS18B20 , je le mettait dans les deux ,car j'en avais besoin pour lire le fichier qui contient les relever de temperature sondes par sondes

Le fait "dans avoir besoin" es une très mauvaise justification.
Votre conception doit essayer de modéliser le "réel".
Si vous n'avez qu'un seul "DS18B20", vous ne devriez avoir qu'un objet "DS18B20".
Si vous en avez X, vous devriez avoir que X objets "DS18B20".
Si vous avez besoin du même "DS18B20" dans des instances d'autres objets, vous pouvez toujours "partager" l'accès à celui-ci via des procédés comme les références ou le Design Pattern Singleton.
Si vous avez plusieurs objets "DS18B20" pour le même élément "physique", lequel d'entre eux aura les informations les plus à jour, aura les bons paramètres pour interagir avec le matériel, etc...
Ne choisissez pas une "solution" parce qu'elle semble marcher au début mais choisissez une solution qui "modélise" la "réalité" et qui convient aux besoins que l'analyse du projet à identifier.

Google m'a dit qu'un "termostat", c'est pas la même chose qu'une sonde thermique. :aie:
Soit la sonde thermique est "logiquement" (pas forcément physiquement donc) dans ce que vous modéliser sous le terme de "termostat", et alors votre "SondeThermique" est un champ de la classe "Thermostat".
(J'utilise "SondeThermique" plutôt que "DS18B20" car je pense que des types de sonde thermique sont facilement interchangeable. =>"DS18B20" classe fille de "SondeThermique")
Si c'est des entités disjointes, il ne faut pas faire de la sonde thermique un champ de la classe "Thermostat". Quitte à modéliser comment ils interagissent entre eux dans le code de votre projet.

"Modélisez" le "réel" avant d'essayer de le piloter. :mrgreen:

Citation:

j'ai transformer ce que j'ai fais plus haut , avec une class thermostat.

Votre classe "Thermostat" modélise-t-elle un élément "physique" (couche Data/Hardware) ou est-ce un élément logiciel (couche Métier/Business), produit de votre projet ?
Si c'est le premier cas, faites en sorte que vos objets correspondent à la "réalité", pas à un truc pour vous simplifier la vie.

Citation:

mais avec des news pris sur l'exemple que j'ai trouver sur developpez.net (strategie AI)

Pas tout compris. :aie::aie::aie:

La modification d'implémentation du Design Pattern "Statégie" semble montrer que vous avez assez bien compris l'idée de ce DP.
Mais je ne suis pas sûr que ce soit le bon Design Pattern à suivre dans votre cas. Je vous l'avais proposé comme exemple de DP qui peut grandement simplifier du code, mais il doit être adapté à votre problématique, que vous n'avez toujours pas verbalisez.
Citation:
Code:

1 2 3 4 time_t rawtime; const int deltaT = 2; unsigned long long chrono;
On évitera de mélanger les constantes et les variables.
On évitera aussi l'utilisation des variables globales. :aie:
Citation:
Code:

1 2 Thermostat mainThermostat; DS18B20 mainDS18B20;
Ok si c'est 2 objets "physiques" disjoints.
Mais si c'est 2 objets "physiques" "liés":

Code:

Thermostat mainThermostat

Si c'est lié, "Thermostat" devrait être en capacité de faire le lien tout seul.

Si "Thermostat" est un objet "logique" et qu'il a besoin d'accéder aux informations d'un objet physique :
Code:

1 2 DS18B20 mainDS18B20; Thermostat mainThermostat(mainDS18B20);
Comme ça, mainThermostat n'aura besoin de personne d'autres pour avoir accès aux informations et piloter le périphérique physique.
Citation:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 while (1) { time ( & rawtime); cout << ctime ( & rawtime) << endl; if (time(NULL) - chrono >= deltaT) { chrono = time(NULL); mainDS18B20.tempExt(); cout << "tempExtLue " << mainDS18B20.tempExtLue << endl; } mainThermostat.lectureTemperatureExt(mainDS18B20.tempExtLue); mainThermostat.productions(); } return 0;
Beaucoup de "bruit" pour rien.

En attendant de connaitre vos réels besoins en "temporisation" :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 std::tuple<bool, int> getTempo(time_t& chrono) { { ... } .... .... bool fin{ false }; time_t chrono = time(NULL); ... do{ mainThermostat.tick(); const auto& [fin_, tempo] = getTempo(chrono); sleep(tempo); fin = std::move(fin_); }while (!fin) ; return 0;
L'implémentation de la classe "Thermostat" me semble "correct" bien qu'elle ne soit pas thread-safe contrairement au code de votre Github.
Comme le code de votre Github est très lié à Qt, la "thread-safeness" est peut-être important.
Mais dans du code "Console" lié au métier (sans Qt), la "thread-safeness" est vraisemblablement superfétatoire.
Mais il faut structurer votre projet pour maintenir le fait que le code métier n'est pas à être "thread-safeness" quel que soit le choix du Framework d'IHM.

Je ne vois toujours pas l'utilité de cette classe et l'utilisation du DP Stratégie est peut-être "overkill" ou inadapté, non ?
Quelle est la fonction de cette classe ? (Modéliser un objet physique ? Créer des automatisme logicielle ? etc...

-----------------------

Citation:

es-tu au clair sur la notion de « classe » en soi et sur l'héritage en particulier ?

Le changement d'implémentation du Design Pattern Stratégie dans le code qu'il a posté ici semble montrer qu'il a bien progressé sur le sujet. :D

@Obsidian, attention à l'usage de "NULL" qui n'est plus là que pour de la rétrocompatibilité avec le C et l'usage d'API C. En C++ on lui préférera "nullptr".
De plus, l'utilisation de pointeurs "nus" en code C++ "moderne" est plutôt rare, quand il est justifié.

EDIT :
Le fichier "Sans titre_0.pdf" est bien plus qu'un simple cas d'usage.
Il présente plus un schéma d'ensemble qui permet d'avoir d'information sur l'ensemble du projet.

Il y a pas mal de composants physiques (volets, sondes thermiques, compresseurs, vannes etc...).
Je commencerais par mettre en place une couche "hardware", capable de communiquer avec ces composants de manière simple.
Après, j'implémenterai la logique en charge de coordonner ces composants pour atteindre les objectifs du projet (régulations, etc...) : une couche métier.
Après, je mettrais en place une IHM qui afficherait les informations pertinentes, sous une forme lisible pour l'utilisateur "lambda", et des composants d'interaction (boutons, etc...) pour piloter le machin : une couche IHM.

18/07/2025, 16h47
Obsidian

Citation:

Envoyé par bacelar

La réponse de @Obsidian est apparu pendant la rédaction de cette réponse.
Je suis assez d'accord avec, sauf que je suis bien plus circonspect sur la justification de l'usage de pointeurs "nus".

On est d'accord. ;)

J'estimais simplement que ça ne valait pas le coup d'encombrer le précédent commentaire avec ça directement, et qu'on le ferait si on en avait à traiter du sujet en particulier.

Citation:

@Obsidian, attention à l'usage de "NULL" qui n'est plus là que pour de la rétrocompatibilité avec le C et l'usage d'API C. En C++ on lui préférera "nullptr".

Ah oui ! oui ! effectivement, j'ai posté un peu trop tard hier et j'ai omis ce détail. :aie:

Ça m'ennuie d'ailleurs car je suis précisément en train d'essayer de me remettre proprement à jour après m'être fait prendre au piège beaucoup trop longtemps dans un projet web, comme pas mal de monde. J'ai toute une série d'items que j'ai écrits moi-mêmes en me basant sur chaque évolution de la norme par rapport à la précédente (principalement C++11 en fait, mais également sur les suivantes) et qu'à ce titre, « nullptr » fait l'objet d'un item dédié.
20/07/2025, 09h21
ludoiphone

salut , ca fait beaucoup d'informations a la fois .

pour le comportement sans action humaine : si un des thermostats(chambre1,2,3,4 ou salon) est ON le volet de un des thermostat qui est sur ON s'ouvre;
le programme doit faire une pause de 15 seconde (pour que le volet est bien ouvert puis il controle la temperature exterieur ( 1 sondeExterieur) pour selectionner le mode de fonctionnement (chauffage ou froid).
pour chaque mode il doit actionner les differents relais pour faire fonctionner les organes electrique (compresseur , vanne 4voie , ventilateur exterieur et ventilateur intererieur).
les organes sont actionner soit par une consigne temperature(via 4 sondes (sondes 2 UniteExterieur, 3 EchangeurExterieur, 4 UniteInterieur et 5 EchangeurInterieur)) ou par une temporisation

et entre le mode chauffage et le mode froid il y as la vanne 4 voie qui est alimenter , les consignes de temperature des 4 sondes et les temporisations qui change.

pour le mode utilisateur (via l'ecran tactile) il peut arreter le fonctionnement, le remettre en marche et modifier certaine consigne de fonctionnement .

voila pour le comportement physique et programme(automatsime).

les 5 thermostats sont relier en parallele a une seul pin du raspberry (2 pins pour etre exact + et -)
les 5 sondes sont relier a une seule pin du raspberry (3 pins pour etre exact + , - et data)
20/07/2025, 11h16
ludoiphone

au finale je comprend que les noms des objets sont brouillons "mainThermostat" , mainDS18B20 par exemple.
je vais revoir le tous en faisant par DS18B20 temperatureExt;

c'est + logique .

pour les chronos : au demarrage je temporise le temp que le ou les volets s'ouvre puis je lance la ventilation apres je temporise pour lancer la vanne 4 voies puis nouvelle temporisation pour lancer le compresseur puis je temporise pour faire des controles de temperature tous les minutes pour lancer le degivrage si il y as besoin .
et apres le degivrage pareil je temporise pour l'egouttage .

Voir 40 message(s) de cette discussion en une page