Re : Les micro-nuggets à la Française

[Olivier_L]

Je suis totalement d'accord avec la solution de JB.

Je préfère également ne pas utiliser l'erreur comme source d'arrêt, surtout dans le cas où il y'a un log ou une remontée des erreurs.

Et la destruction de la référence à la fin est plus propre, car l'utilisation d'un timing peut être un peu aléatoire. Après, je conçois que dans le cas de sous VIs séparés, il est bien moins aisé de gérer ce cas de destruction de la référence.

[ouadji]

Le but est le partage des manières de faire.

oui, oui ... moi aussi. Juste un échange de nos boîtes à outils    c'est très chouette et très constructif.

Je vois ton code.

Avec un "retour" des lignes d'erreur avant le "Release", là, pas de soucis, ça tourne tip-top.

Pour être franc ... oui ... sur le principe, je préfère "aussi" avec une Notification. C'est plus "dans les règles".

Mais c'est vrai, que via l'erreur, ça fonctionne très bien aussi (et ça simplifie le code)

Le point faible avec la Notification d'arrêt est qu'il est plus difficile de rendre les boucles totalement indépendantes. (comme dans mon 2eme exemple sur le sujet)

Il faut être certain que toutes les boucles sont bien stoppées avant de faire le "Release"... et dans ce cas, pas moyen d'utiliser la ligne d'erreur comme confirmation d'arrêt.

Ceci dit, ce n'est pas impossible. Il faudrait une "Notification d'arrêt" dans un sens ... et une "Notification de confirmation d'arrêt" dans l'autre sens.

Il doit y avoir moyen de faire ça ... mais là, on arrive dans du code (inutilement) compliqué ! ... pour faire "ça", je change complètement de système d'arrêt et j'utilise un booléen dans une FGV.

"Set" pour le Master, "Get" pour les slave. Dans le jeu d'échec, j'utilise une FGV sur l'erreur ... et dès qu'il y a la moindre erreur (n'importe où dans le code) tout s'arrête, c'est très efficace (et facile).

Je te souhaite une belle journée JB et merci pour ton intérêt sur le sujet.

[edit] une belle journée pour Olivier également [/edit]

[JB]

En alternative à la notification des sous-VIs vers le VI master servant à indiquer leur arrêt, voici comment je procède parfois en cas d'utilisation de la même notification dans plusieurs VIs.

Le VI master :

• au démarrage, appelle dynamiquement les sous-VIs
• au moment de quitter, envoie la demande d'arrêt par la notification
• attend que les sous-VIs soient fermés (lecture de leur état par leurs références). Si nécessaire, les "tue" après expiration d'un délai.
• détruit la référence de la notification

Ceci dit, j'utilise plus généralement des queues (type bien connu avec un cluster contenant un enum définissant le type de message et un variant avec les données) qui offrent plus de souplesse.

[ouadji]

oui, les solutions sont multiples. Tes deux dernières solutions sont tout à fait efficace également.

bien ... que je n'aime pas trop l'idée de fait "aboart" après un délai (c'est un détail, chaque développeur à son propre feeling sur le sujet)

L'idée n'était pas de faire un exposé exhaustif sur toutes les bonnes pratiques pour stopper des boucles en //

mais simplement d'en donner "une" qui permet facilement :

- de cadencer,  de stopper,  et de stopper en interrompant la tempo de cadencement en cours.

Mais, au delà de "ça", j'aime beaucoup les solutions que tu as proposés.

[JB]

Entièrement d'accord :

1. L'abort est une solution de dernier recours, en principe jamais exécutée, qui sert uniquement à éviter un plantage du SW dans les situations anormales.
2. Ton exemple de départ est très intéressant et instructif et j'en ai bien compris le but. Les échanges qu'il a suscité montrent que le code devient rapidement plus complèxe si on désire implémenter une autre solution - que certains considéreront plus propre - que l'arrêt par le cluster d'erreur.

[ouadji]

sans oublier les dernières technologies     (je taquine    )

[ouadji]

une dernière ... qui rencontre tous les avantages de la 1ere solution proposée :

- arrêt boucles multiples

- cadencement

- arrêt de la tempo de cadencement en cours

ET ... qui fonctionne avec le send d'une vraie info événementielle (et non un arrêt par le biais d'une erreur)

[ouadji]

Pour comptabiliser le nombre de "sous-chaine" dans une "chaine"

Sans regex, sans boucle ... et point de vue vitesse, c'est très rapide.

[Michael.C]

Joli détournement :).

Seul modification que j'apporterais à ton VI, c'est de mettre le tableau au format Chaine %s 😉

En effet, tu n'utilises en sortie que la taille du tableau, alors pourquoi ajouter une étape de "transformation" inutile 🙂

Bonne journée.

[ouadji]

Bonjour Michael,

oui, j'ai testé avec "%s" (approche qui me semblait également plus logique) ... mais curieusement, la vitesse maxi ne se trouvait pas là.

Sur une chaîne de 10E+6 caractères contenant 40% de chaînes à rechercher :

entrée array type = array U32  -  %d = 0,57sec    %s = 0,96sec

avec un format "%s", si tu veux retrouver le 0,57 sec, alors tu dois placer l'entrée "array type" avec un "array de string"

comme ceci :

rem : 0,56 / 0,55 ... les temps sont variables entre ces deux chiffres,

il n'y a donc pas de différence significative entre ces 2 chiffres (avec 0,93, là, oui)

Pour conserver la vitesse maximum et en même temps " l'aspect logique" ...on peut choisir "array string + %s"

(même vitesse que "array U32 + %d" ... mais "extérieurement" plus logique)