turn 2 integers into a string?

I'm reading two switch states, which produce values of 01, 11, 10

I want to use the result to trigger different actions. I can't add them, (since 0+1 = 1+0) but I can compare the values of both variables

 if ( (sensorValue1 == 0) && (sensorValue2 == 1))

but it seems a good way would be to turn them into a string and use a case statement based on the value of that string?

 switch (Tot) {
    case 10:

However, the lower "Tot" line causes an error

"'Tot' was not declared in this scope"

char Tot[4];
}

void loop() {
  int sensorValue1 = digitalRead(2);
  int sensorValue2= digitalRead(3);
  String val1 =  String(sensorValue1);
  String val2 =  String(sensorValue2);
  Tot = val1 + val2;

Does this make sense? Any clues?

Does this make sense?

Absolutely not.

Creating a string from a String makes no sense.

It makes a lot more sense to "combine" the two value mathematically. For instance, 1 and 0 could become 10 by multiplying the first value by 10 and adding the second value (1,0 -> 10; 1,1 -> 11; 0,1 -> 1; 0,0 -> 0).

How about:

byte total = (sensorValue1 << 1) | (sensorValue2);
switch(total){
  case 0:  // 00
  
  case 1:  // 01
  
  case 2:  // 10
 
  case 3:  // 11
}

These need only be byte:
int sensorValue1 = digitalRead(2);
int sensorValue2= digitalRead(3);

break; is required to end each case, yes?
switch(total){
case 0: // 00
break;

CrossRoads:
break; is required to end each case, yes?
switch(total){
case 0: // 00
break;

Yes, I was assuming the OP knew what to do if I got him at least to the proper case labels.

Delta_G:
How about:

Binary expressions can also be used for comparison:

byte total = (sensorValue1 << 1) | (sensorValue2);
switch(total){
  case 0b00:
    // code here
    break;
  case 0b01:
    // code here
    break;
  case 0b10:
    // code here
    break;
  case 0b11:
    // code here
    break;
}

CrossRoads:
break; is required to end each case, yes?

break jumps to the end of the switch. (It breaks out of the switch.) If you leave out the break, execution continues into the next case.
Sometimes this is what you want, but in those cases, you should definitely leave a comment to indicate that it is on purpose.

Just as an illustration:

switch (c)
{
  case 10:
  case 13:
    if (n)
    {
      line[n] = 0;
      process(line);
      n = 0;
    }
    break;
  
  case 32:
    if (!n)
      break;
    // else no break because reasons
  case 'a' ... 'z':
    line[n++] = c;
    break;
}

So here, case 10 has no break, it falls through into case 13. Case 13 always ends. Case 32 sometimes breaks and sometimes falls through.

something as simple as this may read a bit easier to review after a few months!

  byte valueA = digitalRead(pinA);
  byte valueB = digitalRead(pinB) ? 10 : 0;
  valueA += valueB;
  switch (valueA){
    case 0:    //neither active
      //
      break;
    case 1:    // A is active
      //
      break;
    case 10:  // B is active
      //
      break;
    case 11:  // Both are active
      //
      break;
    default:
      //
      break;
  }

Thanks, I'm new to this and am simply trying what seems to make sense (like converting the values into text & concatenating them for comparison). I'll try the two (far better) solutions above.

yes, I'm up to speed on the "break", was just illustrating the point.

Many thanks!

I have to disagree with you here BulldogLowell. Bitshifting is readable just fine, it's faster and this way you can use 8 switches in one byte (or 16 in unsigned int) instead of 3 (or 5 in uint). Okay, to make it more readable you can spread it across lines and use binary notation to make it clear. (0b11 is more clear to be switch 1 and switch 2 then just plain 3)

septillion:
I have to disagree with you here BulldogLowell. Bitshifting is readable just fine, it's faster and this way you can use 8 switches in one byte (or 16 in unsigned int) instead of 3 (or 5 in uint). Okay, to make it more readable you can spread it across lines and use binary notation to make it clear. (0b11 is more clear to be switch 1 and switch 2 then just plain 3)

No problem, there are a lot of ways to Do it.

I only threw it out there as an option, that better matched what the OP set out to do.

Personally, I wouldn't use either approach, just the simple if, else sequence.

No math.