Use of string in switch case
-
I can only guess and believe you might want to do something like this:
switch (myString) { case "Blue": ... break; case "Red": ... break; ... }Trouble is, the C or C++ languages don't do that. C# does. Thus, one solution is to use C#. If you want to use C/C++, you must use nested if/else clauses to emulate the same effect, something like so:if (_tcsicmp(myString, _T("blue")) == 0) { ... } else if (_tcsicmp(myString, _T("red")) == 0) { ... ... }Doesn't look as nice, but, compared to the above fictivious switch statement, gives you control over the comparison algorithm (e.g. use _tcsicmp for case-insensitive comparison, or _tcscmp for case-sensitive comparison), etc. -
You cannot use a string in switch cases - the cases have to be constant numberic values. If the strings are not known at compile time, then you have to use if...else if...else statements. If they are known at compile time, then you can precompute hashes of the case strings, and switch on a hash of the string you want to switch on. Um, that wasn't very clear, was it?
void DoSomethingDependingOnString (LPCTSTR szSwitchable)
{
switch (ComputeHash(szSwitchable))
{
case 0x4wfe: // ComputeHash ("I am a string!")
DoFirstThing ();
break;case 0xfg13: // ComputeHash ("I am another string!") DoSecondThing (); break; default: DoDefaultThing (); break; }}
I hope that was little clearer. Iain.
-
You cannot use a string in switch cases - the cases have to be constant numberic values. If the strings are not known at compile time, then you have to use if...else if...else statements. If they are known at compile time, then you can precompute hashes of the case strings, and switch on a hash of the string you want to switch on. Um, that wasn't very clear, was it?
void DoSomethingDependingOnString (LPCTSTR szSwitchable)
{
switch (ComputeHash(szSwitchable))
{
case 0x4wfe: // ComputeHash ("I am a string!")
DoFirstThing ();
break;case 0xfg13: // ComputeHash ("I am another string!") DoSecondThing (); break; default: DoDefaultThing (); break; }}
I hope that was little clearer. Iain.
I would recommend not to use the hash approach, for at least these: i) it is hard to maintain - always think a couple of years and several generations of fellow programmers ahead. Who's going to remember how to create the keys, why and when? ii) it is doomed to fail - hash keys are not unique, so there is a chance that two different strings produce the same key.
-
I would recommend not to use the hash approach, for at least these: i) it is hard to maintain - always think a couple of years and several generations of fellow programmers ahead. Who's going to remember how to create the keys, why and when? ii) it is doomed to fail - hash keys are not unique, so there is a chance that two different strings produce the same key.
berndg wrote: ii) it is doomed to fail - hash keys are not unique, so there is a chance that two different strings produce the same key. If you have a finite set of possible strings known at the program development time, you can create a "perfect" hash function[^] that doesn't cause collisions.
-
I would recommend not to use the hash approach, for at least these: i) it is hard to maintain - always think a couple of years and several generations of fellow programmers ahead. Who's going to remember how to create the keys, why and when? ii) it is doomed to fail - hash keys are not unique, so there is a chance that two different strings produce the same key.