Implement STL like standard containers (Data Structures) in LabView

[Bun]

Most languages I have worked in have had a library for common data containers (Tree, Linked List, Stack/Queue, Hash Table, Map, Etc.). I understand that these data structures can be made by using an array and storing array indexes.

Lets face it, it stinks to have to write your own data container evry time you can't force a queue to do something it was clearly not meant to do be able to do, like be a stack.

The advent of classes in labeled was great & I have spent plenty of time creating data structures classes, but the problem is that without templates, or the ability to have more than one kind of dynamic dispatch terminal in a VI, you end up having to write a wrapper to box & unbox your data.

The other problem that I have found is that generally all data must be put into a array for storage. This makes inserting and deleting items from trees and link lists tricky.

I think a set of native data containers along with the operators/methods to manipulate them should be added to labview. It would be nice if upon creation there was a polymorphic terminal that would allow you to wire up any basic primitive type (numeric, double, boolean, string, cluster, references, etc.) as well as classes (not just the LV object, but a template like approach) and variants.

[Mr.Mike]

I really like this idea, but I that before we implement it we need templates like your other idea.  Otherwise we'd be stuck with the builtin types.

I disagree that you would count a tree as a common data container.  It's a common data concept, but there are so many different types of trees.  Here's a good argument against trees as "common" data containers.

As for linked list...I'm not so sure....maybe it'd be better as an arraylist.  Linked lists are easy data structures, but not particularly fast to index.

Stack / Queue / Hash Table / Map: sounds good.

[AristosQueue (NI)]

Mike: Let's not quibble. Kudos the idea. I'll take any of the above!

Bun: I've wished for these for years, but they never quite reach the top of the priority list for LV features.

[Bun]

I agree with Mike that there are several kinds of specializations for most containers (especially trees, an other example would be a priority queue or a doubly linked list), and while it wouldn't be feasible to create a container for every specialization, I think it would be feasible to create the most commonly used containers. Even when I am coding in C++, STL never covers everything, but it generally covers what I need about 90% of the time. When it doesn't I go and build a custom structure. But that means that 90% of the time I don't have to spend my time creating a container.

It would be nice to have my time freed up when I code in Labview instead of always having to make a basic container. The only other 2 bummers are:

1) When I make a new container, I can't reuse it for other data types without copying the class and making it in to a new one, which makes maintenance a nightmare because there is no code reuse.

2) I generally have to stuff all of my data for my container into an array, and handle index updates for deletions and insertions of new data elements.

[beuvink]

I have been busy for some time to define my own kind of datastructure that combines some common stuff into something I think is almost an ultimate memory structure...

It is tightly integrated to a lot of stuff I made so I cannot provide a simple example but here is some outline... The idea is to have a tree as a basic structure that combines the ease of pointers in C, combining paths like in a file-folder structure, read-ability (with the correct tools) as an XML document, the possibility to dump/import/move/copy subsection of the tree and the freedom of an ini-file.

The concept is a tree where instead of pointers as in C labels for each node are used. Each node can have children that can be a subtree or contain items. Each item has 3 properties: a name, a type description and a value. Any item in the tree can be accessed by it's name and names can be combined as if they are a path. Of course all functions that you would normally expect from a tree are availiable.

I have added some additional cherries such as events that are generated when items change so you do not need to poll. I am still busy developing this concept further but I intended it as a way to handle large and flexible datastructures in a parallel programming way.

If there is serious interest in this concept I will see if I can free up some time to make it possible to be used outside my own stuff. The current implementation is based on the LV tree control.

The picture shows a screendump of the debug window that contains some physical data.

[tst]

Before you proceed with this, you might want to check out some of the implementations people have already put out there. You could start by looking at the Lapdog group on this site and by searching the LAVA forums for things like "tree", "linked list", "structure", etc.

On a side note, the sentence "The current implementation is based on the LV tree control" is a red flag - the tree VIs are meant for a UI control and as far as I know are pretty slow and not something you should build on.

[beuvink]

I know the UI tree is a big red flag 😉 altough I am suprised how fast it actually works as long as the display isn't open. I have made the architecture such that I can replace this UI element by a faster implementation in the future.

At this moment I am mainly looking to stuff such as 'how to interface this with code in such a way that it is easy' and the event handling structure.

Thanks for the LAVA tip, I will see if there is something I can use for a better implementation.

[AristosQueue (NI)]

I recently posted a high-efficiency implementation of a priority queue. You can download it here.

[GarryG]

Hash Table would be awesome in LabVIEW! Using variant attributes just doesn't cut it performance wise.

[AristosQueue (NI)]

GarryG: I agree with you. Having said that, Variants can be made to have better performance than most people get from them. As a workaround today, I suggest reading this: https://decibel.ni.com/content/groups/large-labview-application-development/blog/2012/09/04/using-va...