Need data type 'constants'... or allow output data type to be used...

[sbus]

For standard Labview data types (I32, string, etc.) I'd like to see another class of item - we have control, indicator, constant, reference - we need 'types'.

The idea is that for Type Cast and other functions that require you wire a primitive datatype regardless of content,  it's a pain to have to allocate an instance of a variable just to get type.

I end up creating variables called 'I32 type' etc just to accomplish this, because it is much more correct and clear than wiring some other variable of the correct type that has no real reason to be involved. 

Another way to accomplish this would be to have a property of each function that requires a 'type' variable that... "Use output datatype". It's already wired...

And the compiler wouldn't have to allocate space for the variable that is required only to get type information...

In C I can specify a type without allocatiing space, why can't I do that in Labview?

            (char *) p;

[drjdpowell]

> In C I can specify a type without allocatiing space, why can't I do that in Labview?

The LabVIEW compiler makes lots of optimizations like this.  Look up "constant folding".  I don't know what the complier does with constants used for type definition, but whatever the case, this is a low-level issue that the complier should handle.  The programmer shouldn't need to think about it.  

[AristosQueue (NI)]

> I end up creating variables called

I assume you mean that you create a block diagram constant of the type, not that you create a loca/global/network variable. Yes? Because the constant is sufficient.

> And the compiler wouldn't have to allocate space for the variable that is required only to get type information...

The compiler doesn't allocate space for the constant. It knows that the wire is connected to a type only terminal and throws the value away when deubgging is turned off.

[sbus]

Yes Aristos, a local variable. I don't really care about allocating space; perhaps I should have been more clear.

I care about how misleading the block diagram is to the poor guy who is fixing other people's code. Creating a variable (to me) implies you're going to put something in it - and when you just want to use it to specify data type, that isn't true. I don't like creating variables that AREN'T VARIABLES....!

And DrJDPowell, this has nothing to do with compiler behavior - it has to do with the inherent documentation that a labview block diagram should provide. A type shoud be a TYPE, and not something else. I'd like to be able to right-click on a control, indicator, or constant, and 'Create Type', causing a 'type' object that matches the data type of the object I clicked on to appear on the block diagram which could be used to wire to type cast etc. It's a combination of ease-of-use, and block diagram clarity.

[drjdpowell]

Hi sbus,

You can already use LabVIEW constants for this; right-click 'Create Constant' and wire that constant to the type cast.  I suppose a 'type' object might visually be clearer, but I can't recall ever finding using a constant to be a problem.  So adding a new kind of block-diagram item just for slightly better visuals doesn't seem that great.

BTW, you're use of "variable" is confusing; it isn't clear what your referring to.

[sbus]

I guess the point is that a constant allocates space; a type is an idea. I'd like to have a block-diagram construct that is a TYPE and not a constant, control, or indicator; it would be very clear that it wasn't used for anything EXCEPT typing.

It could be created by a "MakeType" operator that could have a constant, control, or indicator wired to its input, and would create an appropriately data-typed "type" at it's output - or a property of ANY Labview object that allocates storage. The "type" could then be copied and used wherever. Think of it as a C 'typedef' statement implemented for Labview... You could even allow "type"s to be passed to routines that allocate space. The purpose of the type construct would be to pass data type information to whateer it was wired to THAT NEEDED ONLY TYPE, like the "type cast" operator. But... you could create a control of datatype "type" that as it's contents could hold a "type" - which you could then pass to a SubVI for use... This would make creation of variable record formats a snap...

But mostly it would make block diagrams cleaner and clearer. You should still be allowed to connect a storage-allocated constant, control, or indicator to something wanting data type information - OR a "type" construct. The properties of a "type" could be "create constant", "create control", "create indicator" (which would create a const/ctrl/ind of the correct data type), "create type" (which would create a duplicate "type" construct of the same data type), and "datatype as string" (which would create a string containing the data type in english).

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.