LOCODUINO

Transcription d’un programme simple en programmation objet

. Par : Dominique, Guillaume, Jean-Luc

Pourquoi parler de codage avant d’avoir spécifié les besoins d’un réseau ? Quand nous concevons un réseau, en tout cas pour ma part, mon souhait est de diversifier les tâches. En effet, coder, poser les voies, faire les bâtiments, tout cela dans un but de non monotonie. Bref, comment donc coder sans avoir défini entièrement le réseau ? Nous (…)

Retourner à l'article

Vous répondez à :

Bravo pour cette article !

J’avoue toutefois n’avoir pas compris le sens de la petite note ?

...quand nous comparons un random avec un if dans une boucle infinie, l’effet pseudo-aléatoire est anéanti...

Il me paraît tout à fait logique de stocker le résultat de l’appel à random dans les variables telles que tempspause, tempsflash car ces temps ne doivent pas changer jusqu’à ce qu’ils se soient écoulés. Ensuite seulement on réévalue de nouvelles valeurs aléatoires pour ces temps.

Meilleures salutations.
Marc-Henri

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

9 Messages

  • Transcription d’un programme simple en programmation objet 17 octobre 2015 09:26, par Zebulon91

    Bravo ... belle approche ;) !

    Répondre

  • Bravo pour cette article !

    J’avoue toutefois n’avoir pas compris le sens de la petite note ?

    ...quand nous comparons un random avec un if dans une boucle infinie, l’effet pseudo-aléatoire est anéanti...

    Il me paraît tout à fait logique de stocker le résultat de l’appel à random dans les variables telles que tempspause, tempsflash car ces temps ne doivent pas changer jusqu’à ce qu’ils se soient écoulés. Ensuite seulement on réévalue de nouvelles valeurs aléatoires pour ces temps.

    Meilleures salutations.
    Marc-Henri

    Répondre

    • Logique oui et non.
      Dans la logique pour éviter de stocker et de prendre de la place avec des variables de temps, on pourrait simplement mettre un if(time>random()) (version abrégée), mais la l’effet disparaît d’où cette petite note. Et donc ne pas comparer un random à un autre truc dans if ou toute autre condition.

      Au contraire un delay peut être rempli par random. Ca le fait qu’une fois, c’est plus simple et moins de lignes à écrire.

      Répondre

  • Merci Guillaume pour ces précisions.

    Je pense que nous partageons le même point de vue. Si on n’utilise qu’une fois le résultat du random, on peut l’utiliser directement sans le sauver dans une variable. En revanche, si on a besoin plusieurs fois du même résultat d’un random, dans le cas d’un if appelé à chaque itération, une variable est nécessaire.

    Meilleures salutations.
    Marc-Henri

    Répondre

  • Excellent article !

    Ce qui est frappant avec les objets, c’est qu’on peut découper un programme "fourre-tout" en morceaux parfaitement distincts, comme des briques.

    Chaque brique-fonction s’occupe d’un problème qui peut être très simple, mais qui peut aussi être plus complexe.
    Quand on rédige une "brique", on ne s’occupe que du problème lié à cette "brique". Cet aspect, qui va de soi quand on sait programmer en objet, n’est pas du tout évident au départ.

    Et on n’écrit chaque brique qu’une seule fois.

    C’est un énorme gain en lisibilité (et donc en déplantage si nécessaire).
    En particulier, le "programme principal" fond littéralement.

    La difficulté se répartit dans les différents objets, bien rangés.

    Répondre

  • Se passer de la methode begin 31 janvier 2018 10:21, par Franck Demongin

    Découvrant Arduino et la prog en C++, vos articles sont une mine d’infos. Merci.
    Une question concernant l’organisation du code dans celui ci : est-ce qu’on ne peut pas se passer de la méthode begin ?
    Le constructeur pourrait faire le même boulot...

    Hummm, je regardais en parallèle le contenu de la méthode init (wiring.c) appelée en premier dans le main. Sans comprendre grand chose à son contenu, je me doute que son taf est important !
    Je crois que je vais rentrer sagement dans le rang et initialiser mes objets dans setup...

    Répondre

    • Se passer de la methode begin 31 janvier 2018 12:48, par Jean-Luc

      Bonjour,

      On peut faire des choses dans le constructeur mais pas tout. En effet, si il s’agit d’un objet global, le constructeur est appelé bien avant l’exécution de main (qui fait setup() puis itérativement loop()). Or, à cet instant, beaucoup de choses ne sont pas initialisées et, si le constructeur repose sur une de ces choses, ça ne fonctionnera pas. D’où le begin qui est exécuté dans setup et donc après que tout dans l’Arduino ait été initialisé.

      Répondre

  • Transcription d’un programme simple en programmation objet 19 avril 2018 23:23, par BoBillier Eric

    Bonjour. Merci pour cet article. Cependant , le lien indiqué pour passer à l’article 114 sur la la construction d’un objet Led, semble défectueux.
    Eric

    Répondre

Rubrique Programmation

Les derniers articles

Les articles les plus lus