檢查commlib
部分，發現
gcs部分乙個告警。
pet_gcs_inte***ce.cpp:212: warning: passing null to non-pointer argument 3 of 'ssize_t ace_sock_stream::send_n(const void*, size_t, int, const ace_time_value*, size_t*) const'
檢查**。報告告警的地方在。
跳過去檢查了一下
send_n
函式的過載函式，發現了問題。
ace的
send_n
有兩個過載函式，
/// try to send exactly @a len bytes from @a buf to the connection socket.
ssize_t send_n (const void *buf,
size_t len,
int flags,
const ace_time_value *timeout = 0,
size_t *bytes_transferred = 0) const;
/// try to send exactly @a len bytes from @a buf to the connected socket.
ssize_t send_n (const void *buf,
size_t len,
const ace_time_value *timeout = 0,
size_t *bytes_transferred = 0) const;
對於這個呼叫，上面兩個函式都可以匹配，所以對編譯器要麼無法正確編譯，要麼要選擇乙個。（其實無法編譯應該更好）。原來的開放者希望匹配的函式應該是
ssize_t send_n (const void *buf,size_t len, const ace_time_value *timeout = 0,size_t *bytes_transferred = 0) const
。但是由於使用了
null
，這個可愛的引數，（
#define null0
），第3
個引數被當作了
int引數。實際匹配的函式成了
ssize_t send_n (const void *buf,size_t len,int flags, const ace_time_value *timeout = 0,size_t *bytes_transferred = 0) const;。
這個**應該改為。明確這個指標的型別，避免編譯錯誤。
ace_time_value *time_wait = null;
effect c++
裡面應該有一節講過這個問題。
問題教訓和總結：
注意引數的型別和函式引數的匹配，
對於過載函式的引數要精心設計，避免出現這樣引數，
ace這兩個函式的設計就會導致這個問題，所以它的引數設計其實是失敗。 對於
null
是什麼要有清楚認識，
null
在c++
中往往就是被定義為
0,而不是
((void *)0),
所以格外要當心。
過載函式引數的轉換和匹配
為了確定最佳匹配，編譯器將實參型別到相應形參型別轉換劃分等級。轉換等級以降序排列如下 1 精確匹配。實參與形參型別相同。2 通過型別提公升實現的匹配 第 5.12.2 節 3 通過標準轉換實現的匹配 第 5.12.3 節 4 通過類型別轉換實現的匹配 第 14.9 節將介紹這類轉換 型別提公升或轉換...
函式的引數型別
按照形參位置傳入的引數被稱為位置引數。如果使用位置引數的方式來傳入引數值，則必須嚴格按照定義函式時指定的順序來傳入引數值 如果根據引數名來傳入引數值，則無須遵守定義形參的順序，這種方式被稱為關鍵字 keyword 引數。def demo a,b,x hehe print a format a pri...
scanf 函式的引數輸入型別不匹配問題
scanf 函式的引數輸入型別不匹配問題 這是我在csdn論壇上見到的問題，這個錯誤有時候會讓人莫名其妙。include main 當輸入a 回車 後，會直接跳過下面 個scanf語句，直接輸出為 123 t 原因 對於scanf d c a,c scanf語句執行時，首先試圖從緩衝區中讀入乙個 d...