Coding Tidbit

Recently, I need to capture the mouse cursor in my homebrew screen capture application, so my search sent me to StackOverflow’s Capture screen shot with mouse cursor. Out of curiosity, I ran Deleaker on it and it finds 2 HBITMAP leaks with every capture. My application captures mouse cursor 30 times per second, so the number of resource leaks are huge and can crash the application if running for more than 3 minutes.

CURSORINFO cursor = { sizeof(cursor) };
::GetCursorInfo(&cursor);
if (cursor.flags == CURSOR_SHOWING) {
    RECT rcWnd;
    ::GetWindowRect(hwnd, &rcWnd);
    ICONINFOEXW info = { sizeof(info) };
    ::GetIconInfoExW(cursor.hCursor, &info);
    const int x = cursor.ptScreenPos.x - rcWnd.left - rc.left 
                  - info.xHotspot;
    const int y = cursor.ptScreenPos.y - rcWnd.top  - rc.top 
                  - info.yHotspot;
    BITMAP bmpCursor = {0};
    ::GetObject(info.hbmColor, sizeof(bmpCursor), &bmpCursor);
    ::DrawIconEx(hdcMem, x, y, cursor.hCursor, bmpCursor.bmWidth, 
        bmpCursor.bmHeight, 0, NULL, DI_NORMAL);
}

MSDN of GetIconInfoExW specifically notes GetIconInfoEx creates bitmaps for the hbmMask and hbmColor or members of ICONINFOEX. The calling application must manage these bitmaps and delete them when they are no longer necessary.

typedef struct _ICONINFOEXW {
  DWORD   cbSize;
  BOOL    fIcon;
  DWORD   xHotspot;
  DWORD   yHotspot;
  HBITMAP hbmMask;
  HBITMAP hbmColor;
  WORD    wResID;
  WCHAR   szModName[MAX_PATH];
  WCHAR   szResName[MAX_PATH];
} ICONINFOEXW, *PICONINFOEXW;

So DeleteObject have to be called on these 2 members, as suggested by Deleaker.

DeleteObject(info.hbmMask);
DeleteObject(info.hbmColor);

Recently, I encountered program crashes because of unscoped enum as array index pattern once in the workplace and another in an open source library where I added another item in the enum. Evidently, this anti-pattern is very popular among C++ developers.

Open source code using Enum as Array Index pattern without bound check in its constructor. WinToastTemplateType is an unscoped enum. C++11 scoped enum cannot be converted to integer so it is not used for this pattern.

WinToastTemplate::WinToastTemplate(WinToastTemplateType type) : _type(type) {
    static constexpr std::size_t TextFieldsCount[] = { 1, 2, 2, 3, 1, 2, 2, 3};
    _textFields = std::vector<std::wstring>(TextFieldsCount[type], L"");
}

For obvious reasons, I cannot show my work code written by my coworker here. This below code snippet have to substitute for our discussion. This type of reckless code in pursuit of performance is not worth having in my opinion. The crash happened just because I unsuspectedly added a new item in the enum that an auto-generated code used to display its name for logging. And the generic error message is not helpful. It did not show the site of crash or the variable name that causes the crash. Just I have said in my previous blog: Put sleep() to make more money from HFT. And Lock-free vs Block-free: Don’t single-minded tracked focus solely on performance just for the sake of it…. Countless hours have been wasted to tracking down buffer overruns in C++ which is not seen in other languages that do bound checking.

enum Fruit { Apple, Orange, Banana };

const std::string& GetFruitName(Fruit fruit)
{
    static const std::vector<std::string> vec{ "Apple", "Orange" };

    return vec[fruit];
}

My proposed fix is to use vector’s at() to access the element and catch out_of_range exception and log the function name.

const std::string& GetFruitName(Fruit fruit)
{
    static const std::vector<std::string> vec{ "Apple", "Orange" };

    try
    {
        return vec.at(fruit);
    }
    catch (const std::out_of_range& e)
    {
        Log(__FUNCTION__, e.what());
        throw;
    }
}

Let me know what you think. Thanks for reading!

“Isn’t April Fools over?” the very first thought running through your mind after glancing at the title. Rest assured, this is not a trolling post to make a fool out of you. This year’s April Fool post is here, in case you missed the once-in-a-lifetime C++ joke of its kind. This article is about slowing the trading frequency of HFT to yield more profits, and the later section discusses lock-free versus block-free.

In High-Frequency Trading (HFT), orders are made as soon as possible before the ‘best’ price disappears. In the olden days, when HFT was rare, it was true. However, in today’s market, where HFT is very active, and once a market trend is detected, it is heavily reinforced by many HFT players. This is why circuit breaker was introduced in stock markets around the world in the late 2000s to stop the stock price from driving south temporarily. When a trend is unstoppable (in upward trend), the longer the wait before putting a sell order, the more significant the difference between your current holding price and the future selling price.

In Medium Frequency Trading (MFT), market data is also processed in low latency to facilitate quick trading decisions. In the long trade, the market maker can afford to wait before making a sell order, and likewise, in the short trade, wait before buy order. If the hard choice for strategy comes between long trade and short selling, always go for long trade because in the latter, the loss could be unlimited when the market moves against you (after the circuit-break period). More earnings are reported in today’s market dominated by HFT, but the average profit on each trade is lesser. Also, HFT means more payments from profit go to the transaction fees. MFT means less transaction fees.

Lock-free

In firms that are in HFT business, its developers favor lock-free data structures but the cases against lock-free are

• It is very, very hard to get right.
• It drains the laptop battery quickly and laptops are very scalding hot at 100% CPU utilization, kicking in the fan spinning at full speed, draining the battery even quicker.
• It is wasting CPU cycles that other processes could use to do valuable work. It slows down the other threads and processes.
• It is not portable to a different processor architecture such as ARM.
• It ignores the fact the CPU frequently sleeps in between milliseconds. Remember the controversial decision of Google Chrome team to run timer at one-millisecond interval?
• It is useless to spin in the user-mode thread where an OS scheduler can preempt your thread from execution anytime without you knowing. Acquire a mutex to inform OS that thread is waiting on it so that OS wakes up the thread as soon as the mutex is unlocked.

My advice? Don’t single-minded tracked focus solely on performance just for the sake of it, and you’ll find yourself missing the woods for the trees. The better alternative out there is block-free (also known as share-free). Whatever name lock-free is given, it is still essentially blocking.

Block-free

To achieve block-free, sharing should be reduced if not eliminated. Make the read-only copies of the data and if modification is unavoidable, make new objects of modified data. What if only serial access to data is permitted and no copies are allowed?

Take this simplified example of when your program has to talk to 4 servers with 2 threads on a dual-core processor? Each of the 4 servers is bound to its data structure that requires serial access in your program. When the data packets arrived and dispatched randomly, at any one time, two threads could very well be processing packets from the same server, and this situation requires a mutex lock to prevent data corruption and needless to say, performance degradation. Lock can be eliminated when the data packets from each server are always dispatched to their own assigned thread, meaning packets from the first 2 servers go to the first thread and the other 2 to the other thread.

Block-free has its challenges. It is more difficult to achieve block-free within the program constraints than to use lock-free data structures. Block-free is the far superior option to lock-free. So always block-free whenever possible!

In the biggest change to C++ syntax, -> and :: operators are to be replaced by . operator in the upcoming C++23 AF00L proposal. The rationale behind this proposal is there can be no confusion (as to which operator to use).

The :: operator is not only used in scope resolution and also as class-to-static_member. However, another way to refer to a static member is through the object instance. All these leads to subtle confusion as to what :: actually denotes.

// class with static member
struct Widget
{
    static int Count;
};

Widget o;
Widget* p = &o;

// Accessing Widget's static Count
int a = Widget::Count;
int b = o.Count;
int c = p->Count;

The :: operator is also used by scoped enum to refer to its enumerators.

// enum class
enum class Fruit
{
    Apple,
    Orange,
    Banana
};

// usage of scoped enum
Fruit::Orange

Efforts to mimick the C++11 scoped enum syntax without its safety is by enclosing unscoped enum inside a namespace or class. So :: operator actually does not tell the developer reading the enum usage about the enum type.

// namespace scoped enum 
namespace Fruit
{
    enum fruit
    {
        Apple,
        Orange,
        Banana
    }
};

// usage of namespace scoped enum
Fruit::Orange

Moreover, when an unscoped enum is a class member, its enumerators may be accessed using class member access operators . and ->. All these adds up to the confusion.

// class scoped enum 
struct Fruit
{
    enum fruit
    {
        Apple,
        Orange,
        Banana
    }
};

// usage of class scoped enum
Fruit::Orange

Fruit x;
Fruit* p = &x;

int c = x.Orange;
int d = p->Orange;

Similarly, the -> operator is not only used in pointer-to-member but also to indicate return type of lambda.

// Example of C++11 lambda with boolean return type
auto lambda = []() -> bool {...}

In C++17, the -> operator is used in type deduction guides(See code example below).

// C++17 Deduction Guides 
template<typename T> 
struct S 
{
    T val;
};

// map string literals to S<std::string>
S(const char*) -> S<std::string>;

In an effort to end all confusion in one fell swoop, -> and :: operators are going to be deprecated in favor of the universal . operator.

In addition to this new development, C++23 is going to get garbage collection to manage its memory and every C++ class inherits automatically from the base Object class!

“That’s great news! I can make use of my father’s 1995 original Java textbook to learn C++23!” – Russian college student, Sabina

Before anyone makes a serious commentary to this blog post, take a good look at the posting date!

For those who like this year’s April’s Fool post, be sure to check out 2019 and 2020 April’s Fool post:

• C++23: fullptr to replace nullptr
• C++23: Mutable string_view

Ray Tracing In A Weekend Repo

My Modernized Ray Tracing In A Weekend Repo

• 

The improvements I made to the original code:

• Convert all raw allocation to shared_ptr to prevent memory leaks.
• Replace non-reentrant rand() with a copy of C++11 random number generator in every thread using thread_local to avoid sharing and locking.
• Replace the text-based image format with stb_image saving to PNG.
• Parallelize with C++17 parallel for_each, achieving a more than 5X performance on my 6 core CPU.

CertCreateCertificateContext failure can be fixed with first exporting the certificate to DER Encoded Binary X.509 (cer file) manually.

std::vector<BYTE> vec;

PCCERT_CONTEXT pCertContext = NULL;
if (pCertContext = ::CertCreateCertificateContext(
    PKCS_7_ASN_ENCODING | X509_ASN_ENCODING, 
    vec.data(), 
    vec.size()))
{
    std::cout << "Success!\n";
}
else
{
    std::cout << "Failure!\n";
}

If one want to forgo the manual export option, CryptQueryObject can be a solution. Note: CryptQueryObject is marked deprecated by Microsoft but I still have to support older OS like WinXP, so using a newer API is out of options.

CERT_BLOB blob = {};
blob.pbData = vec.data();
blob.cbData = vec.size();

DWORD dwContentType = 0;
pCertContext = NULL;

if(::CryptQueryObject(
    CERT_QUERY_OBJECT_BLOB, 
    reinterpret_cast<LPCVOID>(&blob), 
    CERT_QUERY_CONTENT_FLAG_ALL, 
    CERT_QUERY_FORMAT_FLAG_ALL, 
    0, 
    NULL, 
    &dwContentType, 
    NULL, 
    NULL, 
    NULL, 
    reinterpret_cast<LPCVOID*>(&pCertContext)))
{
    std::cout << "Success!\n";
}
else
{
    std::cout << "Failure!\n";
}

Last but not least, remember to free the certificate context!

if(pCertContext)
    CertFreeCertificateContext(pCertContext);

This is a neat comment toggle trick. When you have two path of mutually exclusive code of execution, do this to enable the first section.

Remove the first back slash to comment out the first section and uncomment the second section.

Do not define a default clause for enum in switch statement! Say in future, if another fruit type is added to the enum, default clause shall cause the C++ compiler not to warn you that you have not handled the case for the new fruit.

enum class Fruit
{
    Apple,
    Orange
};

Fruit fruit = ...;
switch(fruit)
{
    case Fruit::Apple: ... 
        break;
    case Fruit::Orange: ... 
        break;
    default: ... // <-- Do not ever define a default clause for enum!
}

As a point of interest, first item under Bad Coding Practices is CWE-478: Missing Default Case in Switch Statement advises programmers to put default clause in their switch statement.

In private inheritance, the base class public access members are still public access in the derived class. Therefore the derived class still can call the base class functions and access its public data. But the user who instantiates the derived class, cannot access the public member of the base class, hence private inheritance.

• Public inheritance is a “is-a” relationship.
• Private inheritance is a “implemented-in-terms-of” relationship.

A useful example, is I like .NET string class and like a C++ string class with the same C# methods but I do not want to reimplement from scratch, so I derived from std::wstring with private inheritance to make use of its functionality, so that user of my string class cannot access the base class’s std::wstring functions to avoid the confusion and I also do not want the user to be exposed to underlying std::wstring details.

class MyString : private std::wstring
{
};

There is an excellent blog about this topic: C++ Tutorial: Private Inheritance.

If you want your executable’s signature to be still valid after certificate validity period, you have to digitally sign it with a timestamp from one of the timestamp websites with /tr switch before its expiry. In my case, I choose timestamp.digicert.com. This command is for Windows only.

signtool.exe sign /tr http://timestamp.digicert.com /f Cert.pfx /p password /n "Your Name" /d "Your Description" YourApp.exe