Inplace Typecast

[gbecker]

The current typecast function does do a buffer allocation and copy operation even if a inplace typecast would be possible.

Please optimize the current function or provide an advanced version of the it.

Original discussion: Lava - Inplace Typecast possible?

[GregR]

This doesn't require a new node. The existing node could be smarter, it just isn't and part of the reason it isn't is a philosophical one.

Typecast has always been treated more as a backdoor than first class functionality. (Internally it is sometimes referred to as the meat grinder. Effective but not elegant.) It allows for some interesting use cases, but in the end using it signifies that your data was not being treated as the correct type to begin with.

So why is it that your data was not being treated as the correct type to begin with?

[JimboH]

I like the idea. In response to GregR or anyone else that comes across this, my most typical usage of typecasting is networking. It seems pretty hard to avoid in that case ...

[GoofyWires]

Beside efficiency casting changes the properties on the wire like UID which I believe many users don't expect until they see their code fails.

Closed and undocumented code turns a language into a Voodoo tool.

LVlacks documentation to how they implemented their closed code.

I bet there is closed code for patent reasons but I also bet a lot of code is closed since they are ashamed of it.

Inplace is just one of many examples but it is a good and important one.

If you want to script actions over your controls will you endlessly case test each control or try to cast it to the relevant type and search for errors???

Maybe NI wants us to put each cast inside an in place structure but at the moment their performance tools don’t analyze it correctly, thus, more documentation is needed so we could at least know what to complain about

[rolfk]

@ GoofyWires: The operation of Typecast (and Flatten/Unflatten) of which Typecast is a subset really is fully documented. No they don't give you the C source code that implements it, but I'm sure that would be almost incomprehensible for most but real diehard C cracks. Because it deals with all the various LabVIEW datatypes in a truely recursive manner. LabVIEW always has treated stream type data (flattened) as Big Endian, which is probably your issue about the UID being changed when you pass it through Typecast. This is documented and many times discussed. Flatten/Unflatten used to be Big Endian too, but got in LabVIEW 8 an extra input to select the endianess of the flattened data. Typecast never got this addition as it has been always a limited version of the Flatten/Unflatten.

@JimboH: Your use case is actually not a candidate for inplace operation. On one side you have a LabVIEW string (or if some LabVIEW elves get their way one day a byte array) and on the other side you have a LabVIEW native datatype. A string is a handle, any other datatype except arrays are not a handle. There is no way LabVIEW could convert a handle into a non handle data type or vise versa without doing actually a copy, unless they redesigning the entire internal datatype handling (and cause lots of backwards compatibility issues).

I believe where the better smartness of Typecast could come in play is if you for instance typecast an int32 into a sgl or an int64 into a dbl. Or arrays of these. And for the String to Byte Array and vv. you should of course use the special nodes for that which do the right thing.

[nathand]

GregR - to answer your question about the data not being the correct type to begin with, sometimes we don't get a choice. For example, the only data type you can get out of TCP Read is a string. (Yes, I realize this is a reply to a note posted two years ago.)

[QFang]

NOTE : I'm voting based on having to deal with VISA and TCP read/write 'string' input and outputs. 

-Also, mulling over if 'string to byte array' is an inplace memory operation and thus has less overhead than a type-cast string to U8 array..  I can't quite decide based on the (phrasing of) the help documentation available...