Enum Datatypes

[JackDunaway]

Is there a compelling reason that enums cannot be a signed integer? 

 

 This would provide the very handy function of assigning them the I32 "base" datatype, eliminating coercion dots on most LV primitives.

On that note, how about supporting sparse enums (enums with non-consecutive value-string pairs)?

OK, I know rings support both features, but rings have the distinct disadvantage of only showing their numeric value in a case structure.

[tst]

I think the idea just disappeared of the radar for most people. Unless you've gone to some efforts to monitor the exchange, you simply won't be seeing it by now.

As mentioned, signed enums would also have to be sparse. Since there's already an idea for that (although it doesn't have that many votes either), there's probably no call for adding another one. You just need to steer people to these two existing ideas (but discreetly, not by posting about it in every second post or having a huge signature).

[Lucither]

OK, I know rings support both features, but rings have the distinct disadvantage of only showing their numeric value in a case structure.

---

With the above statement in mind. Wouldnt it be easier for the people at labview to alter the ring to display there text inputs in a case structure? Would this not then give you what you require?

By the way, i actually got brought to this link because i was looking for a way of getting rid of the coercion dots when using ring constants as inputs to an array index, exactly like you show above but with rings. I agree with your idea that the labview compiler should recognise that you are sending an I32 enum type to the I32 array index and convert, freeing up memory.

[Lucither]

"OK, I know rings support both features, but rings have the distinct disadvantage of only showing their numeric value in a case structure."

With the above statement in mind, wouldnt it be easier for the people at labview to give the option of displaying the ring box text in structures. Wouldnt this then give you what you are after?

By the way, i actually got routed to this discussion as i was looking for a way to get rid of the coercion dots when using a ring constant as the input to an array index, almost exactly what you showed above. I agree with your idea that the labview compiler should be able to recognise this and convert, getting rid of the coercion dots and utilising the memory better.

[Lucither]

"OK, I know rings support both features, but rings have the distinct disadvantage of only showing their numeric value in a case structure."

With the above statement in mind, wouldnt it be easier for the people at labview to give the option of displaying the ring box text in structures. Wouldnt this then give you what you are after?

By the way, i actually got routed to this discussion as i was looking for a way to get rid of the coercion dots when using a ring constant as the input to an array index, almost exactly what you showed above. I agree with your idea that the labview compiler should be able to recognise this and convert, getting rid of the coercion dots and utilising the memory better.

[Lucither]

Sorry for posting the same thing 3 times, i dont have a stutter, just didnt think it had posted correctly until i realised it was on a new page. Do'h

[tst]

You can't have the strings from a ring in a case structure, because a ring can have the strings assigned dynamically. In an enum, the strings are part of the data type and are assigned at edit time.

Also, if you're using an I32 ring, there's no conversion taking place when you wire it into an input of an array primitive. If your ring is I32 and you see a coercion, that would be because the ring is a typedef. It's converted, but there's no memory allocation. Even if there was, if allocating 4 bytes causes problems for you, you really need to rethink your architecture. 😉

[J.Harv]

Kudos.  Somewhere in the thread were 3 things I really liked:  Sparse enums (for the love of beer, just get it done already); signed enums; and variable data type representation.  Good post, thanks.