Smartphone market in Q3 2009

Canalys Q3 2009: iPhone, RIM taking over smartphone market

По-прежнему Nokia "впереди планеты всей" (несколько ее смартфонов я видел сам на этой неделе - очень неплохо). Благодаря iPhone, Google и RIM рост ее продаж не очень уж увеличивается. HTC завоевала свое свое законное место в лидерах. Motorola, выпала из первой пятерки. Возможно, ее Droid с безплатной Google Map Navigation вернет ей позиции. Посмотрим в результатах текущего квартала.

Simulate mouse move and click

Just for fun. These code moves the mouse and click on the left button:

#define WIN32_LEAN_AND_MEAN

#include <Windows.h>


void LeftClick( )
{  
    INPUT input = { 0 };
    input.type = INPUT_MOUSE;
    input.mi.dwFlags = MOUSEEVENTF_LEFTDOWN;
    ::SendInput(1, &input, sizeof(INPUT));

    ::ZeroMemory(&input, sizeof(INPUT));
    input.type = INPUT_MOUSE;
    input.mi.dwFlags = MOUSEEVENTF_LEFTUP;
    ::SendInput(1, &input, sizeof(INPUT));
}

void MouseMove (int x, int y )
{  
    double fScreenWidth = ::GetSystemMetrics(SM_CXSCREEN) - 1; 
    double fScreenHeight  = ::GetSystemMetrics(SM_CYSCREEN) - 1; 
    double fx = x * (65535.0f / fScreenWidth);
    double fy = y * (65535.0f / fScreenHeight);
    INPUT  input = { 0 };
    input.type = INPUT_MOUSE;
    input.mi.dwFlags = MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE;
    input.mi.dx = fx;
    input.mi.dy = fy;
    ::SendInput(1, &input, sizeof(INPUT));
}

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
                   LPSTR lpCmdLine, int nShowCmd)
{
    MouseMove(500, 500);
    LeftClick();
    return 0;
}

ATL Window

From my point of view, MFC is just a wrapper for Windows API. I think, it is a heavy and slow wrapper. I cannot say that if I need to test something simple, I always create an MFC dialog-based application as it used to be few years ago. The Visual Studio wizards create a lot of code, many files, add stdafx.h that connects my code with a lot of headers and libraries, and I still need to edit something in the resources. So, whenever possible, I use just the following simple shablon:

#define WIN32_LEAN_AND_MEAN

#include <windows.h>


int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
                   LPSTR lpCmdLine, int nShowCmd)
{
    return 0;
}

It is not the Win32 console application, I can test many new for me things from the Platform SDK and do not see the annoying console window.

I have shown how to add a window to this code - Самая простая Win32 программа-шаблон для тестов. - it is more C-style, than C++. I'd say the ATL can bring a very modern C++ style into this simple test application.

For the beginning let's modify the first example from this article and add the ATL support:

#define WIN32_LEAN_AND_MEAN
#include <atlbase.h>

int WINAPI WinMain(HINSTANCE hInstance, 
            HINSTANCE hPrevInstance, 
            LPSTR lpCmdLine, int nShowCmd)
{
    return 0;
}

It's compiled successfully and works, but does nothing.
Let's add an ATL Window:

#define STRICT
#define WIN32_LEAN_AND_MEAN

#include <atlbase.h>
#include <atlwin.h>

typedef CWinTraits<WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN | WS_CLIPSIBLINGS, 
WS_EX_APPWINDOW | WS_EX_WINDOWEDGE> CMyWindowTraits;

class CMyWindow : public CWindowImpl<CMyWindow, CWindow, CMyWindowTraits>
{
public:
    DECLARE_WND_CLASS(L"My Window")

    BEGIN_MSG_MAP(CMyWindow)
        MESSAGE_HANDLER(WM_CLOSE, OnClose)
        MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
    END_MSG_MAP()

    LRESULT OnClose(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        DestroyWindow();
        return 0;
    }

    LRESULT OnDestroy(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        PostQuitMessage(0);
        return 0;
    }
};

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
                   LPSTR lpCmdLine, int nShowCmd)
{
    CMyWindow wnd;
    MSG msg;

    HWND hWnd = wnd.Create(NULL, CWindow::rcDefault, L"ATL Window");
    if (hWnd == NULL)
        return 0;

    wnd.ShowWindow(nShowCmd);
    wnd.UpdateWindow();
    while (GetMessage(&msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return (int)msg.wParam;
}

This time the application window is an object of CMyWindow class. WinMain function has common things: creates the window, show it, launch the message loop.
CMyWindow class is simple too. It contains:

1. Window class definition (DECLARE_WND_CLASS).
2. Message map. (BEGIN_MSG_MAP.. END_MSG_MAP with two message handlers for WM_CLOSE and WM_DESTROY)
3. Window styles (CMyWindowTraits).

That'all:

Why I like this style?

Mainly, because I see and control each message my window receives. Nothing is hidden from me, I have to write with my hands everything I want to happen in my application. This style allows me to learn more about Win32, understand better the Windows.

Let's add one more message handler into the CMyWindow class - for example, let's handle WM_ERASEBKGND. We need to update the message map:

MESSAGE_HANDLER(WM_ERASEBKGND, OnEraseBkgnd)

and add the method that will be called on the message arriving:

LRESULT OnEraseBkgnd(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        return 1;
    }

We got a transparent window:

The window is transparent, because the background eraser is empty, but return 1 - meaning we have painted the background.

Why I like ATL?

Because I can use the templates and real Object-Oriented programming for my window classes. For example, ATL allows me to split the message map in the CMyWindow class between many classes and do not have a long and heavy window class. Let's move the backround painter to a seperate class like the following:

template <class T, COLORREF color>
class CBackground
{
    HBRUSH m_hBrush;

public:
    CBackground()
    {
        m_hBrush = CreateSolidBrush(color);
    }

    ~CBackground()
    {
        DeleteObject(m_hBrush);
    }

    BEGIN_MSG_MAP(CBackground)
        MESSAGE_HANDLER(WM_ERASEBKGND, OnEraseBkgnd)
    END_MSG_MAP()

    LRESULT OnEraseBkgnd(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        T* pT = static_cast<T*>(this);
        HDC hDC = (HDC)wParam;
        RECT rect = { 0 };
        pT->GetClientRect(&rect);
        FillRect(hDC, &rect, m_hBrush);
        return 1;
    }
};

This time I created a brush with the predefined color in the class contstructor and delete it in the destructor. Please pay attention that we do not need to check any pointer in OnEraseBkgnd method - no one of them can be NULL.

We need to modify the CMyWindow:

class CMyWindow : public CWindowImpl<CMyWindow, CWindow, CMyWindowTraits>,
    public CBackground<CMyWindow, RGB(128, 128, 128)>
{
public:

    typedef CBackground<CMyWindow, RGB(128, 128, 128)> CBackgroundEraser;
    DECLARE_WND_CLASS(L"My Window")

    BEGIN_MSG_MAP(CMyWindow)
        MESSAGE_HANDLER(WM_CLOSE, OnClose)
        MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
        CHAIN_MSG_MAP(CBackgroundEraser)
    END_MSG_MAP()

    LRESULT OnClose(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        DestroyWindow();
        return 0;
    }

    LRESULT OnDestroy(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        PostQuitMessage(0);
        return 0;
    }
};

CBackground class was added into the inheritance list. and CHAIN_MSG_MAP was added into the map (I used typedef to use a simple name in the message map macro).
And here is the application:

Now we have ATL included and so can use other cool stuff. Let's put an image onto the background of our window:

#define STRICT
#define WIN32_LEAN_AND_MEAN

#include <atlbase.h>
#include <atlwin.h>
#include <atlimage.h>

template <class T, WCHAR* lpszFileName>
class CImageBackground
{
    CImage m_Image;

public:
    CImageBackground()
    {
        m_Image.Load(lpszFileName);
    }

    BEGIN_MSG_MAP(CBackground)
        MESSAGE_HANDLER(WM_ERASEBKGND, OnEraseBkgnd)
    END_MSG_MAP()

    LRESULT OnEraseBkgnd(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        T* pT = static_cast<T*>(this);
        HDC hDC = (HDC)wParam;
        RECT rect = { 0 };
        pT->GetClientRect(&rect);
        m_Image.AlphaBlend(hDC, rect.left, rect.top,
            rect.right - rect.left, rect.bottom - rect.top,
            0, 0, m_Image.GetWidth(), m_Image.GetHeight());
        return 1;
    }
};

typedef CWinTraits<WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN | WS_CLIPSIBLINGS, 
WS_EX_APPWINDOW | WS_EX_WINDOWEDGE> CMyWindowTraits;

WCHAR s_szFile[] = L"image.jpg";

class CMyWindow : public CWindowImpl<CMyWindow, CWindow, CMyWindowTraits>,
    public CImageBackground<CMyWindow, s_szFile>
{
public:

    typedef CImageBackground<CMyWindow, s_szFile> CBackgroundEraser;
    DECLARE_WND_CLASS(L"My Window")

    BEGIN_MSG_MAP(CMyWindow)
        MESSAGE_HANDLER(WM_CLOSE, OnClose)
        MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
        CHAIN_MSG_MAP(CBackgroundEraser)
    END_MSG_MAP()

    LRESULT OnClose(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        DestroyWindow();
        return 0;
    }

    LRESULT OnDestroy(UINT nMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
    {
        PostQuitMessage(0);
        return 0;
    }
};

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, 
                   LPSTR lpCmdLine, int nShowCmd)
{
    CMyWindow wnd;
    MSG msg;

    HWND hWnd = wnd.Create(NULL, CWindow::rcDefault, L"ATL Window");
    if (hWnd == NULL)
        return 0;

    wnd.ShowWindow(nShowCmd);
    wnd.UpdateWindow();
    while (GetMessage(&msg, NULL, 0, 0) > 0)
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return (int)msg.wParam;
}

This image has the alpha and it is drawn with the AlphaBlend.

Aliasing

Here are two articles about the subject:
1. Krister Walfridsson. Aliasing, pointer casts and gcc 3.3.
2. Mike Acton. Understanding Strict Aliasing.

The main idea is simple:

Pointer casts are evil (both explicit and implicit casts), and you should think twice before adding a pointer cast to the code...

Scott Meyers says about it softer:

If you’re coming to C++ from C, Java, or C#, take note, because casting in those languages is more necessary and less dangerous than in C++. But C++ is not C. It’s not Java. It’s not C#. In this language, casting is a feature you want to approach with great respect.

Key points:
1. One pointer is said to alias another pointer when both refer to the same location or object.
2. Pointers of different types cannot point to the same address.
3. Code below:

int
    foo(float *f) {
            int i = 23;
            *f = 5.0;
            /* A float* cannot point on the same address as int*. */
            return i * 2;
    }

Compiler may optimize as:

int
    foo(float *f) {
            *f = 5.0;
            return 46;
    }

4. Many architectures requires that pointers are correctly aligned when
accessing objects bigger than a byte. So the following code may not work:

char* data;
struct foo_header *tmp, header;

tmp = data + offset;
memcpy(&header, tmp, sizeof(header));

The reason is that the behavior is undefined when you assign an unaligned value to a pointer that points to a type that need to be aligned. What happens in the example above is that compiler notices that tmp and header must be aligned, so it may use an inlined memcpy that uses instructions that assumes aligned data.
Here is fix:

char* data;
struct foo_header header;

memcpy(&header, data + offset, sizeof(header));

Double to Int

We all know how to convert a double value to integer. Google "double to int C++". You will find exactly what you usually use:

double pi = 3.14159;
 int x = int (pi);

C++ does not perform this converting from double to it automatically, because it requires the rounding off and you should be aware that you lost the fractial part of the number.

So? In a library that works with OpenGL I see this strange code:

__inline GLfixed
Fixedf(GLfloat a)
{
    GLfloat b = a;
    GLuint  d = *((GLuint*)&b) + 0x08000000;
    return (GLfixed)(*((GLfloat*)&d));
}

Why this line with *((GLuint*)&b) should be so complicated?

In order to see what's going on I wrote few lines:

int main()
{
    double x1 = 123.456;
    double x2 = 321.654;

    int y1 = (int)x1;
    int y2 = static_cast<int>(x1);
    int y3 = *(int*)&x2;
    int y4 = *reinterpret_cast<int*>(&x2);
    return 0;
}

In the debug mode I switched to the disassember:

I'm not a guru in such things, but looks like this line:

int y3 = *(int*)&x2;

seems "complicated" only in C++. In Assembler it looks trivial:

mov         eax,dword ptr [x2] 
mov         dword ptr [y3],eax

You can compare it with:

fld         qword ptr [x1] 
call        @ILT+215(__ftol2_sse) (4110DCh) 
mov         dword ptr [y1],eax

generated from usual:

int y1 = (int)x1;

But the result is absolutely different:

That's not what I need.
In Anti-Grain Geometry Library I found:

#pragma warning(push)
#pragma warning(disable : 4035) //Disable warning "no return value"
inline int iround(double v)              //-------iround
{
    int t;
    __asm fld   qword ptr [v]
    __asm fistp dword ptr [t]
    __asm mov eax, dword ptr [t]
}

inline unsigned uround(double v)         //-------uround
{
    unsigned t;
    __asm fld   qword ptr [v]
    __asm fistp dword ptr [t]
    __asm mov eax, dword ptr [t]
}
#pragma warning(pop)

So it is possible to use:

int y5 = iround(x1);

The result will be correct:

Polimorphism without virtual functions

I found an interesting place in an old article on CodeProject - WTL for MFC Programmers, Part I - ATL GUI Classes. It is 2003-2005 years, when COM technology, ATL and WTL were in fashion. This place is about the ATL-style templates. In 2003, when I first time used the ATL and WTL, I was told, that such ATL-style does not creae the virtual functions table, so the classes are smaller. And I accepted it as something given, as a rule or a coding standard. This article explains the subject in a so simple and short manner, so even I understood what's going on and why.

I will try to repeat the main idea in this post, in order to be sure that I remember it well now.

#include <iostream>
using namespace std;

template <class T>
class CBaseT
{

public:
    void SayHi()
    {
        T* pT = static_cast<T*>(this);
        pT->ClassName();
    }

    void ClassName()
    {
        cout << "This is class CBaseT" << endl;
    }
};

class CDerive1 : public CBaseT<CDerive1>
{
};

class CDerive2 : public CBaseT<CDerive2>
{
public:
    void ClassName()
    {
        cout << "This is class CDerived2" << endl;
    }
};

int main()
{
    CDerive1 one;
    CDerive2 two;

    one.SayHi();
    two.SayHi();
}

Firstly, class name CDerive1 and CDerive2 were declared and in the same line already were used for the inheritance list:

class CDerive1 : public CBaseT<CDerive1>

It is legal, because C++ standard allows to use the name immediately after the definition. This trick allowed the second thing for this code - compile-time virtual function:

void ClassName()

This function is not declared as the virtual function, but, in fact, the application screenshot shows that it behaves exactly as the virtual method.

The trick here is

T* pT = static_cast<T*>(this);

in SayHi method of the CBaseT class. It casts type CBaseT to either CDerive1 or CDerive2 depending on which specialization is being invoked. Because template code is generated at compile-time, this cast is safe, because the this object can be only CDerive1 or CDerive2 and nothing else.

If we use the templates in the usual way, we have to check the pointer, and if it is not NULL, we can call the method as it is shown here:

#include <iostream>
using namespace std;

template <class T>
class CTestT
{
public:
    void SayHi(T* pT)
    {
        if (pT != NULL)
            pT->ClassName();
    }

};

class CTest
{
public:
    void ClassName()
    {
        cout << "This is CTest" << endl;
    }
};

int main()
{
    CTest test;
    CTestT<CTest> one_more_test;
    one_more_test.SayHi(&test);
    return 0;
}

Check for NULL in the ATL-style templates simply does not exist - it is the this pointer.
The trouble will happen, if I will write:

class CDerive2 : public CBaseT<CDerive1>

So the benefits are obvious:

1. It does not require using pointers to objects.
2. It saves memory because there is no need for the virtual functions' table.
3. It's impossible to call a virtual function through a NULL pointer at run-time because of unintialized vtbl.
4. All function calls are resolved at compile-time, so they can be optimized.

If you remember the classical "Effective C++" (Scott Meyers), such use of the templates as it was shown above is a trick, it is a little bit against Scott Meyers formula:

• A template should be used to generate a collection of classes when the type of the objects does not affect the behavior of the class's functions.
• Inheritance should be used for a collection of classes when the type of the objects does affect the behavior of the class's functions.

Google Maps Navigation

WOW!
This application is availabe on the Android 2.0 phones.

Google is so kind that proposes to install this navigation on iPhone, if Apple will agree.
Motorola is going to release Droid phone and hopes that it will have Google Navigation also.

 

And you see what's going on with the Garmin and TomTom stocks?