11-17-2011 11:12 PM
Hi - I understand that if a class is used in two projects then it is locked - to edit it you need to close one of the projects. But if a class is used in a single project but on two targets (say a PC and a cRIO) then the class is still locked. So is it then true that to make a change to the class I need to close the whole project every time? This doesn't seem right - but maybe this is just the way it is? What if is a communication class you are developing that for instance can only be tested properly when used on two separate targets?
Does anyone have any insights into this?
Thanks.
11-18-2011 07:55 AM
@AnthonV wrote:
Hi - I understand that if a class is used in two projects then it is locked - to edit it you need to close one of the projects. But if a class is used in a single project but on two targets (say a PC and a cRIO) then the class is still locked. So is it then true that to make a change to the class I need to close the whole project every time? This doesn't seem right - but maybe this is just the way it is? What if is a communication class you are developing that for instance can only be tested properly when used on two separate targets?
Does anyone have any insights into this?
Thanks.
Insight? Ideas maybe.
LabVIEW does a wonderful job of protecting itself from ... us. It is not fool proof (there is nothing fool proof to a cleaver fool, as I have learned repeatedly from LV R&D*).
What would happen if you deploy and run a class on one target and then edit the class to change the data type and then run it on the other node?
The locking behaviour make perfect sense to protect against me doing something stupid*.
Ben
* I once type cast a class as an arry of its parent class and got away with it for mile of wire and code and only failed when it came time to write it to disk. Feedback from R&D ws "Don't do that!'.
11-18-2011 10:04 AM
Thanks for the thoughts Ben, I suppose next you are going to break the news to me that LabVIEW will never give us a pointer (I'm still holding thumbs for that one ).
Yes I do see the logic behind it, but nothing stops you from updating a typedef used in more than one application instance (last time I checked) so I cannot see why classes would be different.
Anthon
11-18-2011 10:18 AM
@AnthonV wrote:
Thanks for the thoughts Ben, I suppose next you are going to break the news to me that LabVIEW will never give us a pointer (I'm still holding thumbs for that one ).
Yes I do see the logic behind it, but nothing stops you from updating a typedef used in more than one application instance (last time I checked) so I cannot see why classes would be different.
Anthon
Although I can not cite a reference I get the impresion that the VLOOP people look at type defs as a flawed implementation of LVOOP. It is too late to fix the type definitons but LVOOP can still be saved (from us).
Ben
11-18-2011 11:04 AM
Ironically I erased the following from my previous reply before sending: "After all, classes are just typedefs dressed up in a fancy wrapper". But I suppose I might be stepping on a couple of toes if I typed that...
11-18-2011 11:10 AM
@AnthonV wrote:
Ironically I erased the following from my previous reply before sending: "After all, classes are just typedefs dressed up in a fancy wrapper". But I suppose I might be stepping on a couple of toes if I typed that...
And what a wonderful elegant wrapper it is.
Ben
11-18-2011 11:51 AM
But seriously, I've been delaying using GOOP for years even though I used OOP extensively in other languages. This was mainly as I was expecting it being more trouble than it was worth and just a wrapper for typedefs (and also as it was impossible to get the training course to run at the local office). However, since I've been committing to it (slowly at first) there is no going back for me. I mostly code for performance critical real-time apps and if you apply the same performance principles (preventing copies etc) there is no reason to get worse performance (I think).
Are there any docs that discuss performance considerations with GOOP, GOOP and RT, etc?
Anthon
11-18-2011 12:00 PM
I avoided GOOP for the smae reason but LVOOP is a different animal. From What I recall, dynamic dispatched VIs will introduce a small performance hit but its small and I mention it not to mislead.
There are some papers and I belive the title was something like "LVOOP the decisions behind.." Its here somehwere.
LVOOP unlike the old GOOP is perfectly capbale of working "in-place" with data copies only occuring on wire branches.
DVR will help with those situation where a class needs to be accessed from parallel threads.
Ben
11-18-2011 12:24 PM
11-19-2011 08:06 AM