Using class type in switch statement: is it better than using typeid operator?

I saw below thing about switch statement in c++ standard $6.4.2.

Switch statement can take a condition.

The condition shall be of integral type, enumeration type, or of a class type for which a single conversion function to integral or enumeration type exists (12.3). If the condition is of class type, the condition is converted by calling that conversion function, and the result of the conversion is used in place of the original condition for the remainder of this section

I tried below code which is working fine.

class Test
{
public:
    operator int() { return 1; }
};

int main()
{
     Test obj;
     switch(obj)
     {
        case 1: cout<<"Test class object";
        break;
     }
}

Is this a better way compared to using a typeid operator to find the object type ?

In switch case way, the overhead is each class should have a unique integer id which will be returned by conversion function.

In typeid way, if we use like typeid(obj) == typeid(Test), if else chain will be lengthy when we have many class types. Code readability decreases. May be its slower as well 开发者_如何学Ccompared to switch case, as switch case may be implemented like a jump table by Compiler

So, which way is better to find the object type at runtime ?

EDIT: corrected question considering Andrey's comments.

Where did you get the idea that "string comparison has to be performed"? In order to determine if two type_info objects designate the same type, you need to compare these type_info objects directly, as in typeid(obj) == typeid(Test).

In fact, you cannot do the same things by comparing the strings returned by type_info::name() member simply because the language makes no guarantees about these strings at all. More specifically, it makes no guarantees about the uniqueness of these strings for each given type. They all can return "Hello World!" for all types. Or they can return an empty string for all types. Usually the implementations behave nicer than that, but in any case the name() member is there for some potential debugging/informational purposes. You cannot meaningfully rely on type_info::name() in the actual functionality of your code.

Also, the language standard says that type_info objects are lvalue objects with static storage duration. I'd expect these type_info object to maintain their "address identity" for each specific type (although I'm not sure the standard actually guarantees that). I.e. I'd expect that &typeid(type) == &typeid(type) is always true (i.e. every time you invoke typeid for the same type, you get the same lvalue as the result). If so, you can compare the addresses of type_info objects instead of comparing them using the == operator. You can also use the addresses to build some more complicated data structure for type matching, like an associative array. You can't use switch/case with it though. (And again, I'm not sure my assumption about stable address identity of type_info is valid). In fact it is not. As Johannes Schaub noted in the comments, the correct way to put type_infos into an ordered container is to use the type_info::before() to establish ordering.

Of course, in your specific case using a manually implemented integer identifier for the class (if you really really need to go that way) might be much more efficient. It also allows you a greater flexibility to implement your intent better. For example, typeid(Test) == typeid(const Test) will evaluate to false, which might not be what you want. However, hijacking the conversion operator to such a basic type as int for that purpose is definitely not a good idea. If you really need it, make it a named method and return something named, not a "magic constant".