Missing cRIO dependencies due to inheritance

[bokorpet]

Hello,

I use LVOOP on a RT target where following dependencies are missing:

Class A{

  b: class B

}

In this case, a class C inheriting from B is not among the dependencies, unless C used explicitely.

This can cause to error, for example, if an instance of A is serialized and sent to the target.

It would be safe to add all classes inheriting from B to the dependencies. Instead, LabVIEW ignores these dependencies alltogether.

Is it a bug or a feature? Does LabVIEW support adding such dependencies?

Thanks,

Peter

[crossrulz]

This is a feature.  It is this way with Windows executables as well.  It can only add objects and files that I knows for sure is used.  Otherwise your executable would be huge and filled with items that are not needed.

You should be able to "always include" on the RT build.  Don't have a project in front of me right now to find the exact settings in the build spec.

[bokorpet]

Thanks! Is it something I have to update manually? Say I add another class D inheriting from B. If C is "always included", do I have to add D manually? Or can I make LabVIEW automatically include all inherited classes?

Peter

[nathand · Accepted solution]

There is no way to make LabVIEW automatically include all class that are children of a specific class, because LabVIEW doesn't track that dependency. Inheritance is a one-way relationship: a class knows about its parents but not its children. This makes it possible to add new child class at run-time, for example a plugin that inherits from an existing class.

[bokorpet]

You mean inheritance is a one-way dependency in the LabVIEW implementation, right? My parents know me, for example 🙂 I mean, it doesn't seem to me a global rule in OOP. Am I missing something?

Loading the class runtime is not an option in our case, I'm afraid. It's the "Unflatten from String" VI (deserialize), which throws an error if a class that is being deserialized is not loaded.

Is it really such an exotic use case?

Thanks,

Peter

[crossrulz]

With a dependency scheme, the parents do not depend on the children.  Since you are only calling the parents, LabVIEW sees no reason to load the children.  If you explicitly call the child somewhere, then the parent should also be included since that is a concrete dependency.

It's not that it is an exotic case.  It is just that we can't say that you actually need the child.  This is actually one of the reasons for the Packed Project Library.  You can create your child class there and to be able to use it you dynamically load it.  And it can use any of the parent's wires.

[bokorpet]

Well, one reason for LabVIEW to pre-load a child is that it may be used during the execution. I see that it's static analysis and as such leads to over-approximation. But it's not a brute force over-approximation as you only need to load the children.

Anyway, I understand the point you're making and if LabVIEW doesn't offer a direct solution, I have to live with it 🙂

Thanks for your help and discussion!

Peter

[nathand]

---

@Bokor wrote:

You mean inheritance is a one-way dependency in the LabVIEW implementation, right? My parents know me, for example 🙂 I mean, it doesn't seem to me a global rule in OOP. Am I missing something?

---

This is true of all OOP implementations I've seen, in several languages. Inheritance is an "Is A" relationship - you can always substitute a child for the parent, but not vice versa. It would be impossible for a parent to know about ALL its children, since they could be added after the parent class is complete, and what good would it be for the parent to know about only some of its children, or to have a dependency on only those that existed prior to some point in time?

---

Bokor wrote:

Loading the class runtime is not an option in our case, I'm afraid. It's the "Unflatten from String" VI (deserialize), which throws an error if a class that is being deserialized is not loaded.

---

I wasn't trying to say that you should load the class at runtime, I was trying to explain that it is one reason that parent classes cannot have a dependency on their children. Here's another, somewhat complicated example where someone doesn't want the parent to include child classes automatically: http://lavag.org/topic/16714-class-dependency-linking/