Typecasting message queue data for DQGoop Inheritance

[Tomi_Maila]

I modified a dqGOOP class to allow inheritance using data flattened as string and being placed to the queue following the ideas of my previous post. It was not a complete dqGOOP class but a fast test that proved the concept to function correctly with at least a few data types i.e. strings and I32. The child class also inhereted all the changes in the data structure of the base class because I placed the base class data structure typedef inside the child class data structure typedef as the first member. I didn't get any crashes either. I don't know if I can post the example here, since according to the dqGOOP license, one cannot modify the software. Pierre, you can mail me if you want. Address is tomi dot maila at helsinki dot fi.

LV 8.0 projects are very handy with dqGOOP classes. One can create class as a labview library (not the same thing as LLB). This encapsulates a new namespace for the class. Then when one copies the library, one can make a copy of the class with new namespace. There are no name collisions because of separate namespaces. A GOOP wizard is not necessarely needed if one always creates a new class by creating a copy of the base class library. I didn't get the dqGOOP wizard to function with LV 8.0, but was easily able to make new classes by duplicating the containing library using the above mentioned method.

[PierreDelvart]

I tried something else, I tried with no variant ending datas, please have look.

I installed LV8 evaluation and tested it and I had no crash.

The problem with flattened strings is that datas have to be contiguous in memory and then the system have to move blocks... well i am not sure of what I am saying but try it with arrays and I guess you will lose performances.

I am sure about some thing : complete OOP is possible with labview...

Pierre

[JanK]

FYI. The Endevo GOOP provides inheritance. Send me an email if you like to try it out.

jan.klasson@endevo.se

/Jan

Endevo

[pmn]

I tries to implement this idea of references without typecasting the queue data, since I guess the functionality relies on the implementation of the Queue function. This requires a queue for every subclass, but then there should not occure any non labview problems (one has to be careful how the queues is handled in error cases, I have not looked into that issue). I like the fact that it is pure labview code. Please give your comment. (Pierre, I hope you don't mind I stole your example).

Best regards

Peter