LOCODUINO

Le monde des objets (2)

Des objets partout !

Le 1er février 2015. Par : Dominique, Thierry

Retourner à l'article

Vous répondez à :

16 Messages

• Le monde des objets (2) 2 février 2015 20:38, par DDEFF

  Commentaire.Allumer()
  Merci Dominique et Thierry,
  Les esprits chagrins pourraient dire : tout ça pour allumer une LED…
  Mais, justement, parce que le problème est connu de tous, sa solution par les classes est très claire et facile à comprendre. Bravo !
  Commentaire.Eteindre()

  Répondre

  • Le monde des objets (2) 2 février 2015 22:29, par Dominique

    Je dois humblement avouer que c’est Thierry qui a tout écrit.
    Mon statut de co-auteur est minuscule !

    Répondre

• Le monde des objets (2) 2 février 2015 20:42, par Thierry

  Merci.

  PS : tu as oublié d’initialiser ta classe avec Led Commentaire(13) ! :))

  Répondre

• Le monde des objets (2) 22 avril 2017 07:55, par Denis

  Bonjour, je suis très en retard au vue de la publication mais je suis complètement séduit par cette approche de la programmation objet en C++.
  Bravo à vous.
  Juste une remarque pour voir si j’ai bien compris, pour la méthode Rafraichir() lorsque vous écrivez
  digitalWrite(pin, Etat ^ aMontageInverse) ne faut-il pas écrire plutôt
  digitalWrite(pin, etat ^ aMontageInverse) i.e la variable "état" sans majuscule ??
  Et deuxième petite question, est-ce une bonne pratique de commencer toutes les méthodes par des majuscules (Raffraichir(), Eteindre(), etc…) ?? ou ne doit-on pas réserver ceci au constructeur de la classe ?
  Merci encore pour cet article et les autres bien sur.

  Répondre

  • Le monde des objets (2) 13 janvier 2018 10:32, par Thierry

    Bonjour

    Avec presque trois ans de retard, je vais quand même répondre aux questions !

    La ligne devrait en fait être
    digitalWrite(pin, etat ^ montageInverse);
    Merci de me l’avoir fait remarquer. C’est corrigé dans l’article.

    Pour les majuscules sur les noms de fonction, c’est une question de conventions. Il n’y a pas de règle établie, vous faites ce qui vous semble juste. De mon côté, les fonctions ont toujours une majuscule pour commencer. Les seuls noms qui commencent par une minuscule sont les variables locales (internes à une fonction) et les données membres privées :

    class test
{
public:
  int Toto;

private:
  int titi;

public:
  void Fonction(int aTutu);

private:
  void FonctionInterne();
};

void test::Fonction(int aTutu)
{
 int tete = 0;

 tete = aTutu;
 titi = tete * 2;

// ou mieux

 this->titi = tete * 2;
}

    Tout est question d’habitudes, de conventions, de règles entre développeurs lorsque vous faites partie d’un groupe comme c’est mon cas au boulot ou ici. L’intérêt de ces règles est de permettre une relecture facile et une compréhension plus rapide du code lu.

    Répondre

• Le monde des objets (2) 1er septembre 2017 09:12, par debutante69

  Bonjour,
  Je découvre Arduino et ses subtilités et merci pour vos articles très bien expliqués.
  .
  Cependant, est-ce que l’ accolade point-virgule à la ligne 17
  ne devraient-ils pas être
  à la ligne 56 /// fin de la classe Led , avant le commentaire ?
  .
  PS : je ne suis pas arrivé à représenter l’accolade

  Répondre

  • Le monde des objets (2) 1er septembre 2017 14:26, par Thierry

    Il est en effet possible de coder toutes les fonctions directement dans la déclaration de la classe, mais ce n’est pas la façon de faire adoptée ici. Si la classe avait été incluse dans un fichier hpp et utilisée à divers endroits, le premier source compilé n’aurait pas posé de problème, mais le deuxième et les suivants auraient rouspété en signalant que les fonctions de la classe décrite et codées dans le hpp existaient déjà ! En séparant la classe de ses fonctions, on évite le problème. Et puis une fonction incluse dans une déclaration de classe est potentiellement ’inline’ au bon vouloir du compilateur, c’est un risque que je n’ai pas voulu courir. Une fonction ’inline’ est une fonction dont l’appel sera remplacé par son code avant la véritable compilation. Mais si le code en question est un peu lourd, le multiplier par autant d’appels va grever la mémoire programme, et ce peut être un problème.

    Répondre

• Le monde des objets (2) 17 décembre 2017 20:18, par Eric

  Bonjour,

  Tout d’abord, je "bosse" sur raspberry, mais je ne vois pas de grosses différences avec l’arduino, excepté la fonction setup() et loop() dont on ne peut se passer sur celui ci.
  Grace a vous, j’ai pu enfin adapter mon code c, qui gère les interruptions, en POO.
  J’ai donc deux types de classes, une Actionneur et une Capteur.
  Au niveau de la classe Capteur, je souhaiterai ajouter une propriété privée qui est l’adresse de la routine d’interruption, qui est passée en paramètre lors de la création de l’objet.
  Mais je ne sais pas comment m’y prendre.
  Pour que mon programme fonctionne je suis obligé de passer l’adresse de la routine d’interruption dans la méthode conf qui elle est publique.
  je ne sais pas d’où vient le problème mais aléatoirement lorsque j’allume un relai (avec un bouton), une led qui est utilisée dans mon programme pour s’allumer lorsqu’il n’y a plus de lumière s’illumine.
  Je serais ravis de pouvoir vous montrer mon code afin d’avoir un avis sur la question

  Voir en ligne : Mon petit site sur raspberry

  Répondre

• Le monde des objets (2) 18 décembre 2017 10:39, par Thierry

  Bonjour

  Votre problème ne traite d’aucun des sujets que nous souhaitons ici, l’Arduino et le modélisme ferroviaire. Je vous conseille donc de faire des recherches ciblées sur les pointeurs de fonction en C++. Vous ne devriez pas avoir de problème à trouver des réponses, les callback sont légion en développement.

  Répondre

• Le monde des objets (2) 12 janvier 2018 23:36, par trimarco232

  Bonjour,

  si j’ai bien suivi ?
  dans le 1er /// Déclaration de la classe Led
  ligne 45 :
  il y a ’if (aMontageInverse == true)’
  il faut ’if (montageInverse == true)’

  cela semble se confirmer dans le Code complet, ligne 49

  Répondre

  • Le monde des objets (2) 13 janvier 2018 10:34, par Thierry

    C’est vrai, c’est corrigé. Merci de votre attention !

    Répondre

    • Le monde des objets (2) 13 janvier 2018 13:37, par trimarco232

      l’erreur fut sans conséquence
      l’intérêt est des plus mérités : je recommande vivement la lecture de tes articles !

      Répondre

• Le monde des objets (2) 20 avril 2018 00:00, par BoBillier Eric

  Bonjour merci pour cet article. Juste une petite coquille. Dans le bout de code après le texte :
  Plutôt que d’avoir un constructeur qui va tout mettre à 0, puis un Setup qui va vraiment faire l’initialisation, répartissons mieux les rôles. On peut ajouter à la classe un constructeur avec des arguments :
  Vous avez oublié "Led: :" devant le constructeur.
  Cette erreur est par contre corrigée dans le code complet.
  Cordialement
  Eric

  Répondre

  • Le monde des objets (2) 20 avril 2018 09:05, par Thierry

    C’est corrigé, merci de votre vigilance !

    Répondre

• Le monde des objets (2) 20 avril 2018 09:24, par Bobillier Eric

  Bonjour. Je m’interroge aussi sur un point de votre exposé.Vous indiquez que le constructeur n’accepte pas de valeur de retour, et vous déclarer Led::Led() sans même de type void devant.
  Cependant dans le chapitre suivant (Le monde des objets(3)) , vous déclarez dans le bout de code après le texte " Cette led particulière ayant deux pins différentes à piloter, il faut en ajouter une à celle déjà présente dans la classe de base, c’est pin2, et l’initialiser dans le constructeur :",le constructeur de la classe ledBicouleur avec un type void devant. D’où ma question : est-ce que les 2 écritures sont valides (avec ou sans type void devant), ou s’agit-il d’une petite coquille ?
  Cordialement
  Eric

  Répondre

• Le monde des objets (2) 20 avril 2018 14:10, par Thierry

  Non, c’est bien une coquille qui vient d’être corrigée… A ma connaissance, il ne faut jamais spécifier de valeur de retour sur un constructeur, même void !

  Répondre