Standardize representation of integer numbers used for size, position, bounds, etc. to I32

[dsloan]

It sure would be nice if the representation of all numbers that will only be integers were all I32 (same as used for loop iteration, array index, etc.)  It is annoying to me when I need to get a window size, a control width, a splitter position, an indicators bounds, etc. and then do some math with them only to find that one is I32, another is I16, then another is U32 ......  the result is lots of red coercion dots and sometimes wacky things can happen with the math if you don't convert everything to the same representation.  Same thing for settings like cell positions in tables and list boxes. 

[WG-]

I disagree. You as a programmer are then just lazy in my opinion. In the beginning memory on computers was very scare, nowedays it is not. Unfortunately this however leads and has already lead to bad programs. Why declare I32 variable when you know that the variable will always be in the range of 0-10? Use a U8 then. It takes less memory and is more energy efficient. Programmers should always try to create the best algorithm possible which minimizes running time, memory, energy, cost. What you are now suggesting is just to forget all those principles just because you find it inconvient to work with different datatypes. In my opinion those factors seperate the real programmers with the script kiddies. In my opinion LabVIEW should change certain datatypes... Why has the for-loop a I32 input for how many times the loop runs? Can it loop -343 times? No it can't! Why use a I32 then? Use a U32. Same counts for index arrays and more.

[dsloan]

I can understand you point - but in this case I also disagree with it.  If it is a trade off between saving some memory space or saving my time, which in this case it is, I'll take saving my time.  The amount of memory being saved by not making some numbers I32 instead of U8 is nothing (well, very close to nothing).  The amount of my time that it takes to determine what the representation is and then converting it to something else takes time away form what I really want to be doing.  I want to be spending my time focusing on my application, not on converting numbers to different representations.  Being able to spend more time focusing on your task and less time on some of the programming minutiae - hey isn't that what LabVIEW is all about?? 

[GregSands]

I'm hesitating to kudo this until I know what the memory cost will be.  How many integer properties are in a typical LabVIEW program?  If it's 10^4, then changing everything to I32s may increase memory by ~20kB.  If it's 10^7, that's ~20MB.  The first is fine (a large program may be 100x that, so 2MB), the second is definitely wasteful as WouterG says.  It's not just the integers that the program uses that need to be I32s, it's the internal storage of every integer.

Given all that, if the total is "low", I'd say the benefit of a standard representation is well worth it, although for future-proofing I'd suggest that I64s would be even better (ok, just double everything again!).  WouterG's comment is really more valid for arrays than for these sorts of properties/indices.

Lastly, my thought (despite my earlier erroneous suggestion that arrays be indexed using U64s) is that any integer able to be used in a computation should be signed, and any that are not (e.g. Enums) should be unsigned.

[Bart_Boshuizen]

There are some drawbacks on different datatypes for integers so this idea sounds nice. But the idea of one type for all doesn't work. In my case the conversion of this general integer type to hexadecimal string representation would be greatly affected. Will a number like 125 become 0x7D or 0x007D or 0x0000007D. Not to mention what will happen to negative numbers.

So in the end no kudo from me.

[Darren]

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.