Functional global set as reentrant vi in CLD sample?

[Ben]

Again I'm with you.

One of the first leasosn I teach my rookies is use Bundle by name and type definitions.

Ben

[SteveChandler]

---

@Ben wrote:

The reason it works is all access is sequential.

Ben

---

So is this a Functional Local Variable?

[Ben]

---

@SteveChandler wrote:

---

@Ben wrote:

The reason it works is all access is sequential.

Ben

---

So is this a Functional Local Variable?

---

I would have to agree. Drop two of that VI side-by-side on a diagram doing a write and you would have the same effect. WHo knows which copy would be picked up in the other states.

Ben

[JB]

---

Norbert B a écrit :

You might want to take a look into this KB.

---

Thank you very much.

[altenbach]

I was not able to find the true source of that code. Where does it come from? Who wrote it? Do you have a link?

The VI contains more that one highly flawed FGV:

• Manage accounts.vi
• Manage current function.vi

Both are set to "reentrant (shared clones)" and the code only works because the programmer was lucky. As has been mentioned, the words on the diagram of these two functions even document the settings, so yes, it looks very intentional.

My best guess is that the author did not understand the execution settings at all and got misled by the word "shared", apparently assuming that this is the correct setting if all instances should "share" the data. Bzzzt! Wrong!

(Maybe NI should have come up with a better terminology to avoid all confusion. (e.g. simply "reentrant if needed" or similar). "Shared clones" sounds so sci-fi and alien! :D)

I give the example an F!

There is absolutely no guarantee that it works and it might fail at any time! (quote from the KB: "Initially only two clones are created when the calling VI begins. A caller will use one of these data spaces, but it doesn't know which one, and it may be a different instance on subsequent calls.")

[Ben]

Yepper!

Although the documentaion has been improved it still needs some more help to make it clear.

Ben

[SteveChandler]

---

@altenbach wrote:

I give the example an F!

---

But so as not to scare off people from taking the exam this would not (I think) cause you to fail. The example has good documentation, style and functionality. And apparently at least one horrible bug lurking in the shadows. I don't know how the exams are graded. Can the graders only take one point off of style for this, one for each instance of the vi, or however many they think it is worth?

[altenbach]

Yes, the VI has many things going for it: clear diagram layout, good documentation and structure, so yes, it's just a functional "fail". I don't know what grading they use, but it probably should get an 80%.

The take home message is that even if the code passes all casual tests and everything looks right, there could be bugs lurking deep inside the code that will potentially never be found. Suddenly, in LabVIEW 2020, a slight change in the compiler will expose the bug, but at that time it has been already deployed to ATMs all over the world.

Don't trust code, no matter who wrote it and no matter how well it works. Only a detailed code review by others will hopefully find them. Whenver I dig into one of my old programs, I find subtle errors that are easily corrected. No program is completely error free! A program 😮 without bugs does not exist, it's a myth!

[SteveChandler]

---

@altenbach wrote:

No program is completely error free! A program 😮 without bugs does not exist, it's a myth!

---

A company I once worked for was going through a stack of resumes. One of these looked very good but the guy blew it in the end when he said that he "writes bug free C code". He would have gotten an interview if not for that single bold claim.

[Ben]

---

@altenbach wrote:

....

 No program is completely error free! A program 😮 without bugs does not exist, it's a myth!

---

See myth below

Ben