LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Implicit typecast notification, or error, for strict type def

I agree, they shouldn't have been merged, that's why I posted them separate.

0 Kudos
Message 11 of 17
(252 Views)

Hi dgholstein,

 

You can create a DVR (data value reference) or a single-element Queue for each of your C++ pointers, so I don't see where you have a limitation.

But I agree that in your case, it is weird to create a reference to a reference, which you will have to destroy in addition to destroying your C++ object.

Also everytime you want to access your pointer, you need an In Place Element Structure (for the DVR) or a Preview Queue Element (for the queue), which makes your diagram more complex.

 

Also another idea would be to cast your U64 pointer to a string, which would prevent confusion with numeric data, but you can still confuse it with a regular string...

0 Kudos
Message 12 of 17
(237 Views)

I'd be better off with a cluster of one, pointer-sized unsigned; similar, and simpler than a LV class (but without the compatibility check).

 

My anal self though looks at clusters as data structures instead of C++ references, and am bothered by a cluster wire being where a reference should be.

 

I've already written my own version of the Variant libraries, maybe I should find an obsolete refnum type and embed my own U64 in it.  I suspect NI doesn't want to change their refnum type library.

0 Kudos
Message 13 of 17
(219 Views)

You can simply store pointers (32 and 64 bit) in a U64. If it fills with 32 bit values from a pointer sized value, it will correctly cast when used as an input to a pointer sized value...

 

So in LabVIEW you can simply store pointers in a 64 bit integer, it doesn't matter if the values are 32 or 64 bit.

 

This will work until we get 128 bit pointers. That won't happen anytime soon though...

 

Still not exactly sure what you're trying to solve in this two threads.

 

0 Kudos
Message 14 of 17
(216 Views)

Correctamundo on all points, including, not being what I want.

 

I'll look at hacking one of the LV refnum types... 

 

I think the basic answer is, there is no refnum that can be cast to U64 and NI is unlikely create one.

 

Ironically, I drive past their address most weekends, I should call out the window and ask for it 🙄

0 Kudos
Message 15 of 17
(179 Views)

In looking at the flatten results for refnums, I can use omid typeName and omid className to store my C++ Class type and pointer length-type/big end of the 64-bit pointer (in binhex) respectively.  LabVIEW seems agnostic what I name  omid typeName and omid className.

 

I can then write polymorphic VIs to convert (32/64 bit) between refnum and object pointer.

 

This is the flatten results for a refnum

dgholstein_0-1665073963851.png

 

0 Kudos
Message 16 of 17
(190 Views)

Yes, some code is helpful (even if it's just a FP 😁).

 

So you're talking about the refnum types that have an enum in it, right? Like the semaphore:

wiebeCARYA_1-1665131236408.png

These are indeed rather fixated on 32 bit...

 

It would be nicer if they could be used, but there's just no way to do this. (I do have a remove recollection of 'sessions' that can be registered resulting in a reference). A reference is not a pointer...

 

But if it's just strong typed pointers you want, you can use type def cluster with an U64 and an (U8) enum?

wiebeCARYA_0-1665130993191.png

 

This would give you 64/32 bit compatible container that is strongly typed.

 

If you pass the cluster to a CLFN by it's pointer, it probably even works directly...

 

If you need a value, you'd need a cast:

wiebeCARYA_2-1665131584911.png

This would work even if the pointer size is 32 bit.

0 Kudos
Message 17 of 17
(168 Views)