你為Class外訪問private物件而苦惱嘛？你為設計序列化格式而頭疼嘛？

　　　　　　　　　　　　　　　　　　　　　　　　　　　　——歡迎體驗Google Protocol Buffer

面向物件之封裝性

歷史遺留問題

面向物件中最矛盾的一個特性，就是“封裝性”。

在上古時期，大牛們無聊地設計了三種訪問域：

public、private、protected。

大多數C++初學者都是疑惑的，甚至是對於傳統C程式設計師而言。

在C規範中，沒有class（類）的概念，只有struct（結構體）的概念。

面向物件的C++中，儘管將C規範的struct移植過來了，但是這個struct是相當特殊的。

C++中的struct，和class沒有多大區別，可繼承/封裝/多型，也支援public/private/protected。

它只有一點不同，那就是預設訪問域是public，該設計僅僅是為了兼顧熟悉C規範的程式設計師。

C規範裡之所以沒有public/private/protected，因為它不是面嚮物件語言，沒有必要遵從OO的封裝性。

如果偏要讓C規範服從面向物件，那麼一切皆是public，這是C++中struct存在的意義。

程式設計規範

第壹章講到了Google程式設計師必須遵從的程式碼可讀標準，該標準主要體現在對變數的訪問上。

對於一次變數訪問行為，它是常(const)訪問，還是修改(mutable)訪問，這顯然是兩種行為。

由於變數只有一個，但訪問方式卻有兩種，於是軟體工程大師們認為，面向物件的訪問要以函式為載體。

這就產生了一種面向物件封裝性程式設計規範：

一切成員變數皆private，一切訪問方法皆public。

中間還有一個protected。protected的含義在不同語言裡是不同的(C++與Java就不同）。

在C++中，甚至在Caffe中，我們更鼓勵使用protected替代private。

具體來講，protected既包含private對外部訪問的遮蔽，又包含對繼承類的開放。

Caffe中廣泛使用繼承類設計，而private成員變數是不會被繼承的。

想象一下，Layer定義了引數W，但是繼承Layer的ConvLayer居然用不了引數W，這不是反人類麼？

讓我們來考慮一下程式碼量，設變數A在C規範中，宣告與定義佔用一行，

那麼在C++規範中，宣告與定義佔一行，const訪問至少佔一行(平均3行)，mutable訪問至少佔一行(平均3行)。

這樣，為了這個裝逼的封裝性，我們的程式碼量平均要上去5倍左右。尤其是在機器學習系統中，大量資料結構的情況下，

原始碼中將會充斥著大量這類無聊的get(const訪問)函式，set(mutable訪問)函式，不得不說，是挺無奈的事。

序列化

文字資料與序列化

喜歡玩遊戲的，應該都改過類似於config.ini的檔案。

比如我手裡的《輻射4》根目錄下的Ultra.ini，就提供了編輯顯示配置的高階方式。

大部分Application Framework都提供了對INI檔案的解析(Parse)。

其實這並不是難事，學過《編譯原理》的人，應該都做過詞法分析器的實驗。

編譯器的詞法分析，論本質，它其實也是人工智慧(AI)，只不過它的智慧必須基於特定規則。

歸根結底，還是沒有超出馮諾依曼的儲存程式智慧範疇，離圖靈的無敵圖靈機還遠得很。

解析平面結構的文字是簡單的，如圖，INI檔案只由域[XXX]，和域下配置項組成。

如果是層次結構呢，比如XML？當然XML有其專門的語法樹。

XML語法相當冗繁，看起來就像是機器寫的（實際上大部分XML真是機器寫的）。

在一個機器學習系統中，顯然我們需要層次資料結構的配置。

比如Caffe中經典的層次結構：

solver{

　　net{

　　　　layer{

　　　　　　blob{

考慮一個更特殊的情況，solver配置和net配置顯然需要寫在不同檔案裡，增強遷移性。

XML解析器顯然沒有這麼高階的功能，能夠整合多個XML檔案。

這樣，XML解析器之上，起碼還需要二次程式設計，相當坑爹。

格式化資料與序列化

何為格式化資料？簡而言之，就是：

C++寫的東西，Python能用，MATLAB也能用。

目前廣泛使用的格式化資料主要有兩種，Binary(C++、Python)、HDF5(MATLAB)。

你肯定會問，ACM比賽不都是用文字格式存資料，為什麼不用文字格式做格式化資料？

答案其實很無語：文字格式的體積要比二進位制格式體積大5倍左右，讀取速度也要相應慢上幾倍。

所以，一個機器學習系統，可以從文字IN資料，但是千萬不要嘗試將資料OUT成文字格式。

文字格式除了體積問題，還存在安全性問題。文字型資料很容易被逆向破解掉。

相反，二進位制等格式易於做位運算的特點，非常適合，且基本支援二進位制序列化的API，

都對二進位制資料進行了加密（比如Qt的QDataStream)，當然安全性不是我們考慮的重點。

二進位制雖然體積小，但是需要人工設計封裝格式。這給序列化(編碼)，反序列(解碼)，帶來麻煩。

在傳統C++大型程式中，我們都能看到序列化和反序列化程式碼相當冗長。

程式設計師寫到最後，都不知道自己到底IN進了什麼資料，OUT出了什麼資料，程式碼顯得十分笨拙。

尤其是在機器學習系統中，考慮到我們需要將引數W儲存到硬碟。

首先，引數W有多少個？是什麼格式？順序是什麼？這些都要先記錄。

記錄完了之後，才能將最寶貴的引數W寫到檔案，是不是很蠢，很蠢，很蠢？

Google Protocol Buffer

不錯的工具

Protocol Buffer是由Jeff Dean領銜開發的神奇工具。

它不僅有著非常不錯的格式化資料的序列化/反序列速度，同時也支援文字格式。

更重要的是，它在自動生成序列化格式的同時，也封裝了部分變數的訪問介面。

使得Caffe的整體原始碼中，不必充斥著大量的get/set。

最後，Jeff Dean出品，速度必然是有保障的。

這位Google首席技術員，PHD專攻編譯器優化，被譽為是地球上讓程式碼跑的最快的男人。

使用方法

這玩意在牆外，在第零章提供的包裡，3rdparty\bin下protoc.exe就是在Windows下本體。

確保3rdparty\bin在環境變數中，編輯proto-make.cmd指令碼：

@echo off
set SRC_DIR=C:\PROTO
set DST_DIR=C:\PROTO
set PROTO_NAME=dragon
echo Check Source Proto Path:  %SRC_DIR%
echo Check Destination Proto Path:  %DST_DIR%
echo Check Proto Files Name :  %PROTO_NAME%.proto
echo ——————————————————————————————————
echo Protocol Buffer：Compliing for dragon.proto.....
start protoc -I=%SRC_DIR% --cpp_out=%DST_DIR% %SRC_DIR%\%PROTO_NAME%.proto
echo Protocol Buffer：Compliing complete!
pause

SRC_DIR為proto指令碼的源路徑，DST_DIR為生成路徑。

proto指令碼是操縱protoc.exe的唯一方式，Google為proto指令碼設計了一種新的語言，非常類似於C/C++。

protoc版本會根據proto指令碼生成h和cc檔案，分別是資料結構的宣告和定義，隨時可以嵌入到你的程式碼中。

protoc的命令引數摘自牆外的官網，我們通常只需要設定源目錄、目標目錄、以及proto指令碼路徑：

protoc -I=%SRC_DIR% --cpp_out=%DST_DIR% %SRC_DIR%\%PROTO_NAME%.proto

第一步

在你喜歡的源目錄下，新建dragon.proto，用文字編輯器開啟它，

定義第一個資料結構Datum：

message Datum{
    optional int32 channels=1;
    optional int32 height=2;
    optional int32 width=3;
    optional int32 label=4;
    optional bytes data=5;
    repeated float float_data=6;
    optional bool encoded=7 [default=false];
}

Datum算是最基本的儲存單元了，它其實表示的就是一張影象。

proto語言與C語言差別不是很大，結構體struct欄位換成message，

變數之前需要追加optional和repeated標記欄位。分別表示的是單變數，還是容器陣列變數。

值得一提的是，proto提供requireed欄位，但是Google程式設計師都懶得用，經常會出現奇怪bug，

所以一律用optional替代requireed。

repeated標記之後，本質是陣列，但實際實現可能是類似於STL容器，它提供了不少類似容器的操作。

[default]可以提供預設值，對於基本資料型別，不設預設值將會同C語言一樣產生類似預設值。

但我們不推薦使用proto自身提供的預設值，通常會之前接一個has_xxx()，來檢測該變數是否被設定。

人工指定的預設值，has_xxx()會返回true，而proto提供的自動預設值，則是false。

另外，對於repeated int32 or int64，使用[packed=true]似乎可以優化速度，對於float其實是無效的。

Caffe裡有些repeat float也打上了[packed=true]，其實沒什麼意義。

最後，所有資料結構變數，都需要一個唯一的id，id從1開始。

這與proto內部編碼系統有關，1~20編碼長度小，訪問速度快。隨著id值增加，後續變數訪問速度會遞減。

再看Datum本身，channels、height、width都是我們熟悉的。

data和float_data的區別在於，前者用於uint8資料，比如MNIST和cifar10/100，

它們的畫素值可以被壓縮為一個字串，而bytes型別在C++裡，恰好就是string型別。

float_data則用於儲存散裝的float值了。

最後的encoded可以被忽略，我還沒見過什麼影象需要編碼的。

Caffe需要OpenCV，主要是由於考慮到影象需要解碼，省略這一步，OpenCV可以無視掉。

第二步

我們還需要為Blob提供一個序列化容器，用於儲存訓練引數。

message BlobShape{
    repeated int64 dim=1 [packed=true];
}

message BlobProto{
    optional BlobShape shape=1;
    repeated float data=2;
    repeated float diff=3;
    repeated double double_data=4;
    repeated double double_diff=5;
}

BlobShape用於儲存Blob Shape資訊。

BlobProto才是我們需要關注的，除了shape，它由四個容器陣列組成。

大部分情況下，我們只會使用其中兩個。

因為只有Tesla系列顯示卡，才支援double運算，而GTX玩家顯示卡，只能使用float運算。

data用於儲存引數資料，diff用於儲存殘差，實際上diff基本是不會用的，記錄引數的殘差沒有多少意義。

完整程式碼