Archive for the ‘C/C++’ Category

When both ‘true’ and ‘false’ are right

I ran into very interesting logic issue. Probably if someone asks me what case it was, then I would not be able to recall this, because it’s subtle ( but simple ).

bool vaFacebookAPI::HandleResponse(zuint32 what, zRecord *record, zRecord *current, zRecord *previous)
{
    bool isHandled = true;

    if (record == nullptr || current == nullptr) {

        // You can think of this as 'handled' or 'not handled' depending on
        // how you think. But architecturally it should be treated as 'not handled'
        return false; // ๐Ÿ‘ˆ๐Ÿผ This case 
    }

    ...
}

1. You can think that it can return ‘true’, because such case is considered and you decided not to do anything. So, It’s handled as such. So, it’s right to be ‘true’.

2. You can think it it can return ‘false’, because for that case nothing is processed and just returns. So, you can regard it as ‘not handled’. So, ‘false’ is correct.

Interesting, isn’t it?
One logic, depending on how you think it can be thought as ‘true’ and ‘false’

So, true is true, and false is also true. ๐Ÿ˜‰

Raw Key Code for Function Keys

I figure out key codes for function keys from F1 to F12 on Mac.

  • F1 : 122
  • F2 : 120
  • F3 : 99
  • F4: 118
  • F5: 96
  • F6: 97
  • F7: 98
  • F8: 100
  • F9: 101
  • F10: 109
  • F11: 103
  • F12: 111

They are not related to ASCII table at all.
Code marked as ‘solution’ or ‘answer’ here doesn’t care of them. They are all converted to a printable characters, ^P.ย So, a table created with the method in the StackOverflow can’t differentiate each of the function keys. So, if you want to differentiate them, customize value saved there using the table above.

It turned out that the database solution, 4D, also had such values for the function keys.
So, it says that the values above is not only specific to my keyboard, Logitechย  K760.

(It’s surprising that 4D is still alive.)

Way to figure out if a target memory is good to read/write?

Hmmm… IsBad*Ptr() functions are deprecated in Win32 API! Ok.. but what if you need it? Actually there is no reliable way to figure out if a pointer is valid or not. If you suffer such problem, it should be fixed at the caller side or the side where it prepared the pointer.

But.. what if you really need it even though you sufficiently considered that?
What if some external code gives you a bad pointer?

Here is a good blog post, “There is no point improving the implementation of a bad idea.”

There is a simple drop-in replacement and it’s.. reasonable.

0 as a macro for successful result?

For more than 20 years, I’ve worked on/with many libraries and frameworks.
There are many oddities. Some were understandable, while others were clearly by wrong design.

However, for recent 10 years, many of such oddities were gone in many frameworks, libraries.
But still I see some.

Most recent one is to define 0 for meaning successful result and -1 or even 1 to mean failure.
As far as I remember, I saw such definition about 20 years ago in Microsoft header file.
For the recent 10 years, many of coding style became like this :

isSuccessful = DoSomething();
if( isSuccessful ) {

}

if a macro value for meaning success is 0 ( as a return value for DoSomething() ), writing code like above will fail.
So, it should be always like :

if( isSuccessful == T_SUCCESS) {

}

However, the naming the value as ‘isSuccessul’ is not really useful.
In 80’s and 90’s people tended to declare such variable name like ‘result”.

STATUS result = DoSomething();
if( result == T_SUCCESS) {

}

So, defining a successful value as 0 doesn’t match current style and even in 90’s style it is good only partially.
Actually even in 80’s and 90’s such values were set 1 or none-0. Failures were set 0, and -1 in some libraries.
Because 0 is implicitly evaluated as false and none-0s are true, it’s common sense to define some SUCCESS as 1 or non-0, and Failure as 0.

So, whether to follow 80’s and 90’s convention or contemporary convention, it’s very odd to define 0 as SUCCESS.

I wonder what people thought when they design it such a way.

A way to get out of the squirrel treadwheel

I was trying to figure out how to create ID2D1Bitmap1 instance which is to be mapped to memory region. But I found out that MSDN documentation put me in self-repeating cycle ( so, I call it squirrel treadwheel. ). In on document it says, the options can’t be used for bitmap instance created with ID2D1DeviceContext, while on the other page, the device context is to be used to create ID2D1Bitmap.

I posted this to MSDN page, ID2D1Bitmap1::Map page.


 

“These flags will be not be able to be used on bitmaps created by the ID2D1DeviceContext”

However on this “ID2D1Bitmap1 interface” page, it says :

Creating ID2D1Bitmap Objects

Use one of these methods to create an ID2D1Bitmap object.

ID2D1DeviceContext::CreateBitmap
ID2D1DeviceContext::CreateBitmapFromWicBitmap

It’s a squirrel’s wheelmill. Don’t you think so?
( this flags can’t be created by ID2D1DeviceContext => on other page, ID2D1Bitmap1 is created using those device context.)

Moreover, throughout Direct2D/DirectWrite and related technology pages, it’s not clear whether methods/functions returns using a parent class pointer ( like ID2D1Bitmap *) can actually return one for its child class instance like ID2D1Bitmap1. By trial and error, I found out that it’s strictly for the stated class. It’s better to be documented. ( Especially you guys are aware of that C++ has supported late binding.)

Secondly, for this issue on how to create ID2D1Bitmap1 with D2D1_MAP_OPTIONS_READ, and thus D2D1_BITMAP_OPTIONS_CANNOT_DRAW | D2D1_BITMAP_OPTIONS_CPU_READ specified in creating an instance of ID2D1Bitmap1, I found some answer here.

The post marked as “Answers”, he created an instance of ID2D1Bitmap1 using CreateBitmap() method of ID2D1DeviceContenxt. It’s opposite to what is mentioned on this page. ( for your convenience, I put it on the top. This document clearly said “These flags will not be able to be used on bitmaps created by ID2D1DeviceContext.” ) You can see that the ID2D1Bitmap1 is created using the device context’s CreateBitmap() method, and it has CPU_READ and CANNOT_DRAW option, and when Map() is called, D2D1_MAP_OPTIONS_READ is specified.

I will test this. But because people marked it as an “Answer”, I sort of believe that it works.

ID2D1*RenderTarget & Device/Device Context

Rendering with Direct2D on Windows 8

On Windows 7 and earlier, you use a ID2D1HwndRenderTarget or another render target interface to render to a window or surface. Starting with Windows 8, we do not recommend rendering by using methods that rely on interfaces like ID2D1HwndRenderTarget because they won’t work with Windows Store apps. You can use a device context to render to an Hwnd if you want to make a desktop app and still take advantage of the device context’s additional features. However, the device context is required to render content in a Windows Store apps with Direct2D.

  • ย Windows 7 and earlier : ID2D1*RenderTarget are expected to be used to render drawing primitives/text etc.
  • Windows 8+ : Device context are expected to be used, because those ID2D1*RenderTargets don’t work for Windows Store apps.

Question 1: Why are classes/interfaces for drawing affected by Windows Store? Technically Windows Store is for selling S/W. They may require some, but is there any valid reason to prevent some drawing classes/interfaces from being used?

Question 2: If it’s that critical, shouldn’t there be any warning message on ID2D1*RenderTarget MSDN pages, at least on their 1st page?

Question 3: So, if you are not going to sell your S/W on Windows store infrastructure, you don’t have those restrictions, right? (Anyway Windows store doesn’t look to draw people’s attention as much as Apple’s app store. So, it will not serve as “People, you don’t know where to find your Windows app, come here!” role.

 

Font rendering : GDI vs. DirectWrite from Mozilla

This blog post shows the difference of GDI vs. DirectWrite font rendering visually.
Great to read…

%d bloggers like this: