Variant (utilité)

[TiTou]

Je te fais une visite guidée ce soir.

[TiTou]

en attendant tu peux faire un recherche dabs les exemples LabVIEW et tu verras que LabVIEW utilise le variant pour la gestion du drag n drop, ça permet d'avoir du polymorphisme.

j'entends déjà ta réponse : ça aurait pu être fait avec une string ou un tableau d'U8 ou n'importe quoi d'autre à la place du variant. Oui, mais ce faisant on se priverait d'une des forces de LabVIEW : la facilité de débuggage ; car entre un variant, qui est "lisible" et un tableau de bytes qui ne l'est pas...

[JB]

 Dans mes applications, l'échange entre les différents modules se fait par des queues. Les types de données échangée par ces modules sont évidemment très variés et nombreux. Sans recourir aux variants, il faudrait réaliser des VIs spécifiques à chacun de ces nombreux types. En utilisant les variants, les choses deviennent beaucoup plus simples ! Au lieu d'une multitude de VIs et de queues, il suffit d'un VI et un type de queue.

Plutôt que mille mots, je t'invite à consulter cet exemple basique qui démontre le principe :

• Format des données : un cluster contenant au minimum (selon la complexité de l'application il est parfois nécessaire d'ajouter d'autres données) :
1. un enum définissant le type de données (indispensable pour savoir comment convertir le variant en données à la réception)
2. un variant qui peut contenir n'importe quel type de données
• Envoi (enqueue) : renseigner le type de données et convertir les données en variant
• Réception (dequeue): sur la base du type de données, convertir le variant en données

Cette manière de faire est un standard très recommandé.

Pour te convaincre de l'utilité des variants, je te laisse implémenter cet exemple sans recourir aux variants. Une fois terminé, la tâche consistera à ajouter dix types de données supplémentaires dans les deux exemples. Après cela, nul doute que tu feras partie des utilisateurs des variants.

PS : Voir aussi les liens de la section "D'autres liens comparables" sur la droite de la page de l'exemple référencé.

[ouadji]

@JB : 

Sans recourir aux variants, il faudrait réaliser des VIs spécifiques à chacun de ces nombreux types.

En utilisant les variants, les choses deviennent beaucoup plus simples ! Au lieu d'une multitude de VIs et de queues, il suffit d'un VI et un type de queue.

Woaww .... je viens d'avoir un flash en lisant ta phrase ... le franc vient de tomber !

Les Variants permettent une certaine forme de polymorphisme.

En fait c'est à la fois une facilité d'implémentation (VI réutilisable au départ de types différents)

et à la fois une utilité "pur code" (VI réutilisable, donc code plus "petit")

La véritable astuce n'est donc pas d'utiliser les variants "de façon brute" dans le Main, (là, je ne voyais pas le "sens" de la chose)

mais bien d'isoler le code qui le contient dans un sous-vi ... ce vi devenant alors polyvalent.

Ensuite, "variant to data", fait le chemin inverse et re-transforme la polyvalence en spécificité.

Je vais aller voir ton exemple JB ... (par curiosité) ... mais je pense avoir compris.

génial  

[ouadji]

@JB :

je viens de regarder ton exemple de code

L'astuce de "l'enum" est absolument géniale.

Voila un code (tout simple) qui "passe" des données de types différents via une seule et même Queue.  

et là ... on est pas dans l'idée (obligatoire) du "sous-vi" ... c'est une utilisation des variants qui peut se trouver directement dans un Main.

y'a plus rien à dire, échec et mat !

[JB]

Heureux si la lumière a été faite.

Ma découverte de ce principe d'échange des données remonte à de nombreuses années et il fait depuis partie des "incontournables" dans mon code.

A part cela je n'utilise pas énormément les variants mais il est bien clair qu'ils s'avèrent aussi utiles pour d'autres fonctionnalités.

Il serait d'ailleurs intéressant de lancer une petite discussion pour voir comment et pour quoi (en deux mots) les uns et les autres les utilisent dans leur code.

[ouadji]

oui ...

dans cette idée de Queue pouvant transmettre des données de types diférents ... l'utilité est évidente (et astucieuse)

mais,

en dehors de tout contexte de Queue ... les utilisations me semblent moins évidentes. (je suis preneur)

hormis cette "facilité" à la mise au point ... quand on développe et que l'on ne sait pas encore très bien quel type sera utilisé.

... dans ce cas un variant permet d'éviter de modifier 50 fois un éventuel type def. (mais là, je fais déjà un effort pour trouver cela utile)

Peut-être cette histoire de "variant attribut" ...  ???

[TiTou]

donc tu avais juste mal compris la réponse de TeamJP34 car il décrivait la même chose que JB...

mais ce qui me surprends le plus de ta part Ouadji, c'est qu'au lieu de passer par un variant on pourrait faire exactement la même chose avec une string en utilisant le flatten into string.

ouvre l'exemple ~\examples\general\function\Cluster & Variant\Flattened String to-from Variant.vi pour t'en convaincre.

variant = solution pour le polymorphisme

les variant attribut c'est des listes référencées par nom, si tu as un grand nombre d'object en mémoire et que tu veux faire des recherches par nom (string), il n'y a pas plus rapide.

j'ai fait des benchmark, c'est impressionnant.

[TeamJP66]

Oui Titou, je l'avais mis mat d'entrée mais il n'a pas voulu aller voir mon exemple qui fait partie des bonnes pratiques de LabVIEW 😄

Pour faire un parallèle à cette réflexion, c'est comme si on te demande l'utilité d'un sous-vi sous LabVIEW? Ce n'est pas irremplaçable ni incontournable, mais c'est ultra pratique et recommandé pour une évolutivité du code. 🙂

Ouadji fais moi plaisir, arrête la philosophie LabVIEW (humour) et présente nous un jeu d'échec plus corriace que le précédent 😄

[TiTou]

une autre utilité des variants?

http://thinkinging.com/2009/02/14/i-couldnt-live-without-array-of-vdata-to-vcluster-video/