2013-03-10 81 views

回答

14

因爲這就是boost::bind這樣做的原因,Boost.Bind作者寫了建議將它添加到TR1中,並將其複製到標準中。

至於爲什麼Boost.Bind這樣做,我不知道,但我會冒險猜測它可能與來自STL的1998標準中的std::bind1ststd::bind2nd匹配。在這種情況下「第一」,即「第一」是正確的(即使是從零開始的索引系統索引零的項目是第一,而不是,項)。

所以也許佔位符應是_1st_2nd_3rd_4th等,但對於非英語國家,誰也不知道在ordinal numbers不一致的後綴,它可能更容易記住,雖然_1_2

只是胡亂猜測。這個問題從來沒有發生過,所以現在我很好奇:-)

6

該公約可能由前身Boost.bind繼承。

至於爲什麼Boost庫選擇從1開始:已經是C++ 03的一部分的綁定器使用first_argument和second_argument作爲類型名稱。

C++標準庫有bind1st()bind2nd(),所以對n元函數的自然概括是「bind 3rd」,「bind 4th」等等。

這些都不是真正的原因,但提供了一個可能的解釋。

+1

我不會購買「從未聽過有人在談論第0參數」,因爲你通常不會談論數組的第0個元素。你說「1st」,但它的索引是0.但是,歷史性的論點是有道理的。標準庫具有'bind1st()'和'bind2nd()',所以對''''''ary函數的自然概括是「bind 3rd」,「bind 4th」等等。 – 2013-03-10 21:11:27

+1

我從來沒有聽說過「零st」,但我聽到「zero-th」......雖然沒有使它正確英文:) – 2013-03-10 21:13:30

+0

@AndyProwl是的,這不是真的令人信服。你能把它編輯出來嗎?我在移動,這是一個痛苦。 – pmr 2013-03-10 21:14:13

-1

boost bind庫的設計者是MSDOS批處理語法的粉絲。

在分批語法,%1是指第一個參數,%2第二,%3第三等,但因爲%不是有效的C++標識符,它們與_取而代之。

在MSDOS批處理語法中,%0指的是批處理文件的名稱。在這種情況下,_0將被綁定到您稱爲_1_2_3等的功能。其實不,不是真的。

+0

Upvoted因爲我猜很多人從來沒有把它放到你答案的最後一行......我實際上正在想類似但很嚴肅的事情,關於POSIX shell('$ 0','$ 1'等) – 2015-07-14 09:10:49

3

這個優點是std::is_placeholder的工作。結果不只是真或假,它是佔位符本身的價值。

std::is_placeholder<_1>::value == 1 
std::is_placeholder<_2>::value == 2 
std::is_placeholder<_7>::value == 7 

但任何非佔位符將評估爲0(當然這是錯誤的)。如果佔位符以_0開頭,則這不起作用。

+0

雖然這是真實的,可以很容易地通過賦予'_0'的值1和'_1'的值2來工作,所以非佔位符仍然具有值0。 – 2016-10-23 12:46:40

相關問題