只要留意一下大專案的原始碼，你會發現，幾乎無一例外的包括乙個
log模組。它的功能很直觀：記錄一些程式執行時資訊，多數情況是用來輔助
debug
的。大專案都有一套的
log的函式，在它的基礎上開發，呼叫它提供的
log函式就行了，比如
linux
核心、apache
等。也有開源
log函式庫，可以直接拿過用。這裡，我們並不鼓勵重新發明輪子，但在少數情況下，確實不得不編寫自己的
log函式。下面是對以前的經驗的總結，和大家交流一下。 1.
按重要程度過濾
loglog
是有代價的，它不但要占用空間，還要占用執行時間。我們不希望在
release
版本中有太多的
log資訊，那會浪費使用者的資源。通常的做法是，把
log資訊按重要程度分成不同的種類，在不同的情況下，列印不同種類的資訊。錯誤的種類，一般分為嚴重錯誤、錯誤、警告、除錯等幾個級別。 2.
按模組過濾
log。對於大的專案的，可能由數十個甚至上百個模組組成。完成乙個複雜的任務，需要在不同模組間切換好幾次，得到的
log資訊比較龐雜。多數情況下，我們的注意力，都放在幾個容易出錯的焦點模組上，
log資訊太雜，要找出焦點模組中的
log會比較累，輸出無用的
log也會增加系統的開銷。這時，我們可以按模組過濾，只留下所關注模組的
log。可以設定乙個過濾掩碼
(mask)
，這個模組占用一位，置
1的模組表示打
log開關。 3.
log的格式。
log的格式最好能夠統一起來，讓人感覺比較舒服，檢視時也有個好的心情。同時最好能與偵錯程式配合起來，比如，在
vc中，若按檔名（行號）
: 資訊
的格式輸出，雙擊該資訊，
vc自動跳到列印該
log的**位置。 4.
log的內容。
log的內容並不無固定規則，一般來說，
log提供下列資訊，對除錯會有一些幫助：
a)模組名。
b)列印該
log的位置，如檔名、行號、函式名等。
c)列印該
log的時間。
d)對由多個模組組成的專案，若這些模組又並不同步發布時，版本不匹配會引發一些問題，這就有必要列印出各模組的
build
時間或者版本資訊。 5.
能重定向
log的內容。常見的做法是把
log資訊列印到螢幕上，這也不盡然，特別對於非
pc平台的情況，有的輸出到串列埠，有的儲存到檔案，有的輸出到
socket
，輸出的目標多種多樣。所以，在設計乙個通用的
log函式庫時，最好考慮到這些需求，抽象出一套輸出介面是較為理想的做法。 6.
動態配置
log。若每次配置
log的規則，都要重新編譯程式，這常常是不能接受的。在設計時要考慮提供動態配置功能。動態配置的方法有多種，可以通過命令列引數，可以通過環境變數，可以通過配置檔案，也可以提供乙個設定介面，這要根據具體的情況而定。配置的內容常常包括：過濾級別、模組掩碼、輸出格式和輸出目標等。 7.
常用的巨集。在
c語言中，有幾個巨集，可能對於編寫
log函式庫有用處： a)
__file__
當前檔名。
b)__line__
當前行號。
c)__func__
當前函式，好像新標準才支援。
d)__date__
編譯日期。
e)__time__
編譯時間。 8.
引數可變。一般來說，
log函式的引數都是可以變化的，這很容易實現，
c語言支援引數個數可變的函式。有時，為了方便，會定義一些巨集包裝一下
log函式，可往往不太走運，因為
c語言新標準裡才支援引數可變的巨集，目前常用的
gcc版本都支援，而
vc這個冤大頭卻不支援。若非要使用變參巨集，一定要考慮可以移植性問題。
靜態函式庫與動態函式庫的設計
函式庫存放位置 linux應用程式使用的主要函式均放在 lib和 usr lib目錄下，其中採用 so.命名的是動態函式庫，而以 a方式命名的是靜態函式庫。靜態函式庫的特點 程式所要用到的庫函式 在鏈結時全部被copy到程式中。導致的問題 如果有多個程序在記憶體中同時執行，並且使用了相同的函式庫，那...
tf 函式庫與np 函式庫的轉換
前言 在對演算法模型進行部署的時候，往往需要做一些工作。以xilinx開發板部署tf框架模型為例，首先需要對訓練好的ckpt模型進行freeze得到.pb模型，之後，對其進行量化 編譯生成elf檔案，然後在板卡上通過main.cc函式呼叫pb模型的輸入 輸出節點對網路模型進行計算，注意這裡的計算分為...
Jstl的函式庫
函式描述 fn contains string,substring 如果引數string中包含引數substring，返回true fn containsignorecase string,substring 如果引數string中包含引數substring 忽略大小寫 返回true fn ends...