le 11-22-2014 04:23 PM
Pourquoi National Instruments encourage-t-il à utiliser un Notifier plutôt qu'une Occurrence ?
Dans mon code, j'utilise une Occurence (je n'ai pas besoin de passer de données)
Cela fonctionne tip-top.
Pourquoi devrais-je utiliser un Notifier ?
Résolu ! Accéder à la solution.
le 11-23-2014 06:19 AM
Essentiellement pour la gestion d'erreur, les fonctions supplémentaires (association par nom notamment), et la gestion dy cycle de vie du notificateur (on sait quand on l'alloue et on le désalloue).
C'est un simple conseil, pas une obligation, le développeur fait ce qu'il veut avec les outils qu'on lui donne ^^ J'utilise aussi parfois les occurrences (mais la plupart du temps pour du code "sale").
A+
--Eric
Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.
le 11-23-2014 08:23 AM
pour la gestion d'erreur (?)
quelle erreur ?
les erreurs (éventuellement) générées par un "wait occurrence" ou un "set occurrence" ?
Penserais-tu au cas ou un "set occurence" ne fonctionnerait pas .... sans générer aucune info à ce sujet ?
Le cycle de vie
oui, on "sait" quand on alloue et quand on désalloue un Notifier.
Mais il semble qu'une occurrence n'ait pas besoin d'être désallouée (?)
(aucune fonction ne semble prévue pour faire un "release occurence" ... close référence ne fonctionne pas)
Alors ... s'il nest pas nécessaire de détruire la référence d'une occurrence, pourquoi se soucier de son cycle de vie ?
les fonctions supplémentaires
oui, retrouver une occurrence par le nom serait "un plus" ... d'accord.
Mais quand on en a pas besoin ...
pour faire du code sale
oups .... à ce point ?
je suis étonné par cette "conclusion" .... car utilisée "proprement", les occurrences fonctionnent parfaitement.
le 11-24-2014 01:54 AM
En y repensant, au regard du fait qu'elles ne contiennent pas de type de données, les erreurs n'ont pas cours (sauf si la référence n'existe pas) pour les occurrences. Par contre, depuis la nuit des temps on utilise le cluster d'erreur pour le flux de données. Une occurrence que l'on souhaite déclencher à un moment précis aura souvent besoin d'une structure séquence ou condition 😕
Cycle de vie : selon moi on devrait toujours avoir la main sur le moment où l'on réserve et libère une ressource. Je suis étonné qu'un fou de l'assembleur dise le contraire... 😛
Code sale : si on repense à un code maintenable et évolutif, l'occurrence n'est pas satisfaisante. Le jour où on veut associer une donnée, on doit tout remplacer... Utiliser une notification avec une donnée débile est donc conseillé 🙂
Eric M. - Senior Software Engineer
Certified LabVIEW Architect - Certified LabVIEW Embedded Systems Developer - Certified LabWindows™/CVI Developer
Neosoft Technologies inc.
le 11-24-2014 04:15 AM
cycle de vie ...Je suis étonné qu'un fou de l'assembleur dise le contraire...
....
j'ai plutôt "essayé" de me "convaincre" du contraire (j'y étais presque arrivé )
J'ai même testé "close reference" sur une Ref d'occurrence ... donc, tu vois !
oui ... ça me fait bizarre d'ouvrir une Reference ... et ensuite de la laisser en l'air comme un électron libre.
les erreurs n'ont pas cours (sauf si la référence n'existe pas)
oui .. et "ça", c'est un soucis.
Par exemple, pour un "wait occurrence",
il n'est pas toujours évident de faire la différence entre un fonctionnement normal et l'ouverture du wait par absence d'une ref valide.
aura souvent besoin d'une structure séquence ou condition oui, exact.
si on pense à un code maintenable et évolutif ... Utiliser une notification avec une donnée débile est donc conseillé suis d'accord.
ok, suis convaincu ... surtout par l'absence qu'une quelconque gestion des erreurs.
J'ai déjà remplacé "la chose" par un Notifier.
ok Eric, super ... comme dab, pointu, pertinent, argumenté ... merci.