Discussion :

[ludoiphone]

coucou les amis , non j'ai fait une pause et je me suis aider de chatGPT et apres j'ai fais tous seul .

dite moi ce que vous en pensez ?? la en ce moment je rencontre des deconnexion du wire aleatoirement et je n'arrive pas a cibler la cause ?

mon Git: https://github.com/ludoiphone/gainable-en-fabrication

[bacelar]

Les #include au début des fichier montrent qu'il y a un début d'organisation des fichiers dans différents répertoire : cela correspondrait aux modules que j'avais mentionné précédemment.
Mais votre dépôt Git est "tout" plat. Tout foutu en vrac dans un seul répertoire.
Essayez de faire en sorte que votre dépôt Git ressemble à l'arborescence de votre environnement de développement. Pour pas vous prendre la tête avec des bugs cheloux, et ça serait aussi plus lisible pour les relecteurs de votre code.
Faites en sorte que l'arborescence de fichiers corresponde à l'architecture de votre solution logicielle.

Les conventions de nommage des fichiers, c'est pas ça.
Avoir des conventions de nommage différentes entre les grandes parties du projet, ça peut être utile, mais là, c'est un peu un capharnaüm.
Utilisation de pointeurs nus, que je trouve pas très justifié.
Réinvention de certains machins plutôt que de reprendre le travail d'autres, via des librairies, comme votre classe de Log, qui n'est pas "mauvaise" mais très lourdes à utiliser et il existe, au bas mots, des dizaines de libraires du Log 'plus portable, plus safe, plus simple à utiliser, etc...).
Votre code est extrêmement verbeux et assez monolithique. Essayez assez rapidement de sortir les valeurs "en dur" à l'extérieur du code (ressources embarquées, ou dans des fichiers de configuration, par exemple).
En utilisant correctement les valeurs par défaut, les constructeurs par défaut, etc... vous auriez un code bien plus court et bien plus lisible.

Faites des fonctions plus courtes et évitez d'avoir plusieurs "retourn" dans ces fonctions à rallonge.
Essayez d'utiliser des outils d'analyses statique de code ou de qualimétrie.
Découper une classe dans plusieurs .cpp, très moyen.
"catch(...)" à éviter comme la peste.
Il y a des #include de fichiers en trop dans des .h. (comme dans Relay.hpp)

[ludoiphone]

salut les amis , donc j'ai essayer d'améliorer mon code :https://github.com/ludoiphone/gainable-en-fabrication dit moi tous merci .

[bacelar]

Beaucoup mieux.
Je crois qu'il a un peu de ménage à faire dans le répertoire "build" qui contient beaucoup de fichiers intermédiaires, qui ne sont pas des sources (voire même des fichiers de log).
J'aurai mis toute la configuration dans un seul fichier plutôt que de dispatcher tout cela dans plusieurs fichiers.
Un petit fichier "readme.md" dans la home page du projet, avec une présentation succincte et les indications de construction serait du meilleur effet.
Je crois qu'il reste des sections "#include" dans des fichiers d'en-tête un peu trop long comme dans "Temporisations.hpp".
Ces mêmes sections montrent que le découpage en module n'est pas encore finalisé : du "hardware" qui inclus du "logique" et vis-vers-ça, idem pour "core", etc...
Les "dépendances" devraient être que dans un sens.
J'aurais renommé le répertoire "ui" en "Qt" ou "ui/Qt" car il s'agit d'une implémentation "100% Qt".
Toujours un petit syndrome "NIH" pour votre classe de Logger un peu bricolé.

[ludoiphone]

Ces mêmes sections montrent que le découpage en module n'est pas encore finalisé : du "hardware" qui inclus du "logique" et vis-vers-ça, idem pour "core", etc.." :

Peux-tu être plus précis ? merci.

Toujours un petit syndrome "NIH" pour votre classe de Logger un peu bricolé." :

As-tu une bibliothèque a me proposer ?

[bacelar]

Peux-tu être plus précis ? merci.

Une façon simple de voir si le découpage est "sain" : c'est de faire un schéma où chaque module (ici, c'est vos sous-répertoire de "niveau 1" : hardware, logique, core, etc...) apparaît sous la forme d'un rectangle et de faire des flèches allant du module du .h "source" (contenant le #include) vers le module où est le fichier "cible" (vers le fichier indiqué par le #include).
Il y a des outils de qualimétrie qui font ce type de schéma avec un peu de paramétrage.
Si votre architecture tient un minimum la route, vous ne devriez pas avoir de cycle.
Le contenu des modules devraient être "logique" pour une personne connaissant un peu le domaine.
Ici, j'ai pas l'impression de retrouver mes petits juste en regardant le nom des répertoires/module, mais je n'ai vraisemblablement pas la connaissance minimales pour en juger vraiment.

As-tu une bibliothèque a me proposer ?

Ça fait longtemps que je n'ai pas fait de "prospection" sur le sujet, je suis resté depuis très longtemps sur Log4Cxx (surtout lié aux similarités avec Log4J Java que les équipes connaissent bien), pour les log "fonctionnels".
Pour les "Logs" de débugging/développement "à l'arrache", comme je développe principalement sous Windows, j'utilise "OutputDebugString" (ou les MACROs correspondantes), qui est très souple, très directe, avec pas mal d'outillage "ad hoc".

Notre ami Google donne ça :
https://stackoverflow.com/questions/...rk-suggestions
Un point de départ pour une prospection de framework coïncidant avec vos besoins spécifiques.