sf::Key::Code::Count issue

[MrDoomMaster]

Hi,

I may be completely misunderstanding something, but the sf::Key::Code::Count enumerated member doesn't seem valid. For most of the enumerations in sf::Key::Code, they've been given explicit values. Thus, the 'count' member actually gives a number over 300, when there are only about 60+ enumerations.

This seems like an error and I thought I'd bring it up.

[Lord Delvin]

its not an error, as there are unnamed keys.
In my tuned version i've set this to 0xFFFF to be able to get keys with unicode names;)

[Laurent]

Yep, this is actually just an upper bound, not the exact count of keys. It's mostly used when you want to define an array of keys.

[MrDoomMaster]

Yep, this is actually just an upper bound, not the exact count of keys. It's mostly used when you want to define an array of keys.

Yes, but it is inconsistent and misleading. I was using it to generate an array of key presses. Normally a "count" member in an enumeration is a count of all physical members in the enumeration. A prerequisite of this is that all of the enumerated members be numbered in ascending order starting from 0.

If you take a look at the other enumerations in the same file, you'll notice that the 'count' member actually does represent the physical count of enumeration members.

Now that you've explained the purpose of the Count member in Key::Code I understand that it isn't a bug. However it might be a good idea to create a detailed comment for that member. It deserves some textual explanation since, as I've pointed out, it is inconsistent.

I'm also curious why you even explicitly assign values to the enumerations. SFML is supposedly portable, so I don't think you are mapping them to Microsoft Virtual Key Codes. It also seems like SFML supports other key inputs that aren't explicitly defined in the Key::Code enumeration (I'm judging this by the implementation of the enum, it skips large ranges of numbers).

Thanks for your feedback. If you could address my few other questions I don't believe this would be an issue for me anymore.

[Laurent]

In fact, the only reason is to map characters code to their ASCII code (sf::Key::A == 'a').

As the value of 'a' and all other characters can't be known (it could be 97 with ASCII, or something else with EBCDIC), I just can't fill the gaps with other codes and need to restart from a safe upper bound for the other values of the enum, which is 256 (I guess I could use 128 as well).

[MrDoomMaster]

In fact, the only reason is to map characters code to their ASCII code (sf::Key::A == 'a').

As the value of 'a' and all other characters can't be known (it could be 97 with ASCII, or something else with EBCDIC), I just can't fill the gaps with other codes and need to restart from a safe upper bound for the other values of the enum, which is 256 (I guess I could use 128 as well).

Why not allow your key code enumerations to be automatically numbered by the compiler? Is there actually a specific reason to assign the ASCII values?

[Laurent]

It's just good to be able to directly convert to the corresponding character -- when it's a character.