Use of native c ++ typeid in Windows Mobile

Background

When I develop Mobile Sensors API-Native uniied APIs for Windows Mobile Sensors Unit Test, I want to print the Sensor Object class, so I need to use typeid to implement it.

Introduction

This article describes how to use the c ++ typeid operator in Windows Mobile.

Implementation

IGSensor* GSensorFactory::CreateGSensor()
{
try
{
return HTCGSensor::Create();
    }
catch(std::runtime_error& err)
    {
        printf("%s\n", err.what());
    }

try
{
return SamsungGSensor::GetInstance();
    }
catch(std::runtime_error& err)
    {
        printf("%s\n", err.what());
    }
return NULL;
}

The above is the Sensor factory class. Ideally, the program can automatically detect the device type and generate the corresponding Sensor processing class.

So I can print out the class information during the runtime during Unit Test to facilitate testing.

TEST(IGSensor, GSensorTest )
{
    IGSensor* gSensor = GSensorFactory::CreateGSensor();

    CHECK(gSensor != NULL);
    FAIL(typeid(*gSensor).name());
}

GSensor is defined as the parent class IGSensor, but GSensorFactory returns its subclass HTCGSensor or SamsungGSensor. Typeid can print the type information of the runtime object.

The following example uses wikipedia to briefly explain typeid. For the original text, see Typeid.

#include <iostream>
#include <typeinfo>  //for 'typeid' to work

class Person {
public:
// ... Person members ...
virtual ~Person() {}
};

class Employee : public Person {
// ... Employee members ...
};

int main () {
   Person person;
   Employee employee;
   Person *ptr = &employee;

   std::cout << typeid(person).name() << std::endl;   // Person (statically known at compile-time)
std::cout << typeid(employee).name() << std::endl; // Employee (statically known at compile-time)
std::cout << typeid(ptr).name() << std::endl;      // Person * (statically known at compile-time)
std::cout << typeid(*ptr).name() << std::endl;     // Employee (looked up dynamically at run-time
                                            // because it is the dereference of a pointer to a polymorphic class)
}

The typeid function is to determine the class information of a (determine) object at runtime. Its return valuetype_infoObject,type_infoConstructor, = Operator is private, so it is impossible to generate newtype_infoIs similar to typeid (person). name (), and class information is directly returned.

Although the typeid function is run-time judgment, the compiler determines when writing. For example, the first three in the preceding example are as follows:

std::cout << typeid(person).name() << std::endl;   // Person (statically known at compile-time)
std::cout << typeid(employee).name() << std::endl; // Employee (statically known at compile-time)
std::cout << typeid(ptr).name() << std::endl;      // Person * (statically known at compile-time)

These are all determined during compilation. Only the pointers of polymorphism objects can be determined at runtime. As follows:

std::cout << typeid(*ptr).name() << std::endl;     // Employee (looked up dynamically at run-time
                                            // because it is the dereference of a pointer to a polymorphic class)

 

In my program, the IGSensor pointer gSensor also uses runtime judgment. When developing Windows Mobile in Visual Studio, you must note that if you use runtime judgment, you need to modify the project compilation options. Configuration Properties-> C/C ++-> Language-> Enable Run-Time Type Info-> Yes. Otherwise, an error occurs during the running of the program.

Mobile Sensors API Project

This project is still in its infancy. Currently, samsung's gravity sensor is implemented. I host the project to Mobile Sensors API-Native uniied APIs for Windows Mobile Sensors, and I will continue to improve it, implement various sensors in this project.

Because I don't have an HTC machine on hand, if anyone is interested, I can join the project to help me Test the HTC device. Because I joined the Unit Test, the Test became very simple and only needed to execute the program, you can refer to the test output file without debugging. Of course, this Test process is a continuous iteration process, but Unit Test simplifies the sub-process.

Source code: http://mobilesensor.codeplex.com/SourceControl/ListDownloadableCommits.aspx

Environment: VS2008 + WM 6 professional SDK + Samsung Windows Mobile SDK