跳到主要內容

Devirtualization and TDD

Devirtualization and TDD

Devirtualization (去虛擬化)

Devirtualization 是 C++ 編譯器的一種最佳化,舉個例子:

struct foo {
  virtual ~foo() {}
  virtual int bar() = 0;
};

struct food : foo {
  int bar() final { return 2; }
};

struct fool : foo {
  int bar() override { return 3; }
};

int test(food& f) { return f.bar(); }
int test(fool& f) { return f.bar(); }

test(food& f)-O2 編譯後產生的組語是

test(food&):
        mov     eax, 2
        ret

test(fool& f) 則產生

test(fool&):
        mov     rax, QWORD PTR [rdi]
        mov     rax, QWORD PTR [rax+16]
        cmp     rax, OFFSET FLAT:fool::bar()
        jne     .L6
        mov     eax, 3
        ret
.L6:
        jmp     rax

差別在於前者用了 final 而後者使用 overridefinal 可以告訴編譯器 food::bar 不會再被衍生型別覆寫,因此不需要查找 vtable 而直接呼叫 food::bar

final 也可以用來敘明類別不會被其他類別繼承。例如:

struct foot final : foo { /* impl */ };

以上可以發現,能套用 devirtualization 的情況,只有在型別已經確定的時候,比如 test(food&) 已經確定接收的是一個 food& 型別,而不是 foo& 這個抽象型別。

Test-Driven-Development (TDD)

假設我們想為上面的 test(food&) 撰寫測試碼,就出現了兩難:我們想改寫 food::bar 的行為以進行測試,然而這樣一來就違背了 final 的語意而造成編譯錯誤;若將介面改成 test(foo&) 則失去了 devirtualization 的最佳化效果。

在目前的標準規格下,或許最簡單的補救方法是使用條件編譯

#if ENABLE_TEST
#define TESTABLE_FINAL override
#else
#define TESTABLE_FINAL final
#endif

struct food : foo {
  int bar() TESTABLE_FINAL { return 2; }
};

來讓下面的測試用程式合法

struct foodTest : food {
  int bar() override { return 9; }
}

不過 macro 降低了可讀性,條件編譯也需要重新編譯才能測試,或許哪天標準會考慮加入

struct foodTest; // forward declaration
struct food : foo {
  int bar() final_except(foodTest) { return 9; }
};

或者改用 attribute 的方式

struct foodTest; // forward declaration
struct food : foo {
  [[final_except(foodTest)]]
  int bar() { return 9; }
};

通知編譯器允許 foodTest 覆寫 food::bar


Written with StackEdit.

留言

這個網誌中的熱門文章

得利油漆色卡編碼方式

得利油漆色卡編碼方式 類似 Munsell 色彩系統 ,編碼方式為 HUE LRV/CHROMA 例如 10GY 61/449 ( 色卡 ) 編碼數值 描述 10GY hue ,色輪上從 Y(ellow) 到 G(reen) 區分為 0 ~ 99 ,數值越小越靠近 Y,越大越靠近 G 61 LRV (Light Reflectance Value) 塗料反射光源的比率,數值從 0% ~ 100% ,越高越亮,反之越暗,也可理解為明度 449 chroma 可理解為彩度,數值沒有上限,越高顏色純度 (濃度) 越高 取決於測量儀器,對應至 RGB 並不保證視覺感受相同。 參考資料: 色卡對照網站 e-paint.co.uk Written with StackEdit .

UTF8 與 Unicode 的轉換 (C++)

UTF8 與 Unicode 的轉換 (C++) 先釐清一下這兩者的性質 Unicode: 為世界上所有的文字系統制訂的標準,基本上就是給每個字(letter)一個編號 UTF-8: 為 unicode 的編號制定一個數位編碼方法 UTF-8 是一個長度介於 1~6 byte 的編碼,將 unicode 編號 (code point) 分為六個區間如下表 1 Bits First code point Last code point Bytes Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 7 U+0000 U+007F 1 0xxxxxxx 11 U+0080 U+07FF 2 110xxxxx 10xxxxxx 16 U+0800 U+FFFF 3 1110xxxx 10xxxxxx 10xxxxxx 21 U+10000 U+1FFFFF 4 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 26 U+200000 U+3FFFFFF 5 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 31 U+4000000 U+7FFFFFFF 6 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 觀察上面的表應該可以發現 除了 7 bits 的區間外,第一個 byte 開頭連續 1 的個數就是長度,例如 110XXXXX 就是 2 byte 長,而 1110xxxx 就是 3 byte 除了第一個 byte 外,之後的 byte 前兩個 bit 一定是 10 開頭,這樣的好處在於確立了編碼的 self-synchronizeing,意即當編碼為多個 byte 時,任取一個 byte 無法正常解碼。 Note 第一點中的例外 (7 bits) 是為了與 ASCII 的相容性,而第二點會影響到 code point 至 UTF-8 的轉換。 為了與 UTF-16 的相容性,在 R

C++17 新功能 try_emplace

C++17 新功能 try_emplace 回顧 emplace 大家的好朋友 Standard Template Library (STL) 容器提供如 push_back , insert 等介面,讓我們塞東西進去; C++11 之後,新增了 emplace 系列的介面,如 std::vector::emplace_back , std::map::emplace 等,差異在於 emplace 是在容器內 in-place 直接建構新元素,而不像 push_back 在傳遞參數前建構,下面用實例來說明: struct Value { // ctor1 Value ( int size ) : array ( new char [ size ] ) , size ( size ) { printf ( "ctor1: %d\n" , size ) ; } // ctor2 Value ( const Value & v ) : array ( new char [ v . size ] ) , size ( v . size ) { printf ( "ctor2: %d\n" , size ) ; memcpy ( array . get ( ) , v . array . get ( ) , size ) ; } private : std :: unique_ptr < char [ ] > array ; int size = 0 ; } ; struct Value 定義了自訂建構子 (ctor1),以指定大小 size 配置陣列,複製建構子 (ctor2) 則會配置與來源相同大小及內容的陣列,為了方便觀察加了一些 printf 。當我們如下使用 std::vector::push_back 時 std :: vector < Value > v ; v . push_back ( Value ( 2048 ) ) ; 首先 Value 會先呼叫 ctor1,傳給 push_ba