為什么不同的GCC 4.9.2安裝會為此正則表達式匹配提供不同的結果？

Question

我在ideone和Coliru上發布了以下代碼：

#include <iostream>
#include <regex>
#include <string>

int main() 
{
    std::string example{"   <match1>  <match2>    <match3>"};
    std::regex re{"<([^>]+)>"};
    std::regex_token_iterator<std::string::iterator> it{example.begin(), example.end(), re, 1};
    decltype(it) end{};
    while (it != end) std::cout << *it++ << std::endl;
    return 0;
}

兩個站點都使用GCC 4.9.2。 我不知道ideone使用什么編譯參數，但Coliru中沒有什么不尋常之處。

Coliru沒有給我match1結果：

Coliru

# g++ -v 2>&1 | grep version; \
# g++ -std=c++14 -O2 -Wall -pedantic -pthread main.cpp && ./a.out
gcc version 4.9.2 (GCC) 
match2
match3

ideone（順便提一下，使用libc ++ ， Coliru的鏗鏘聲3.5.0 ）

match1
match2
match3

我的代碼是否有未定義的行為或什么？ 什么可能導致這個？

Answer 1

這是libstdc ++的regex_token_iterator拷貝構造函數中的一個錯誤，由postincrement運算符調用。 該錯誤已於2014年12月修復; 從那時起發布的gcc 4.9和5.x版本將有修復。 錯誤的本質是迭代器的副本將副本的目標別名化，從而導致觀察到的行為。

解決方法是使用preincrement - 從微觀優化的角度來看這也是可取的，因為regex_token_iterator是一個相當重的類：

for (; it != end; ++it) std::cout << *it << std::endl;

Answer 2

代碼有效。

唯一合理的解釋是標准庫版本不同; 雖然大多數情況下標准庫實現隨編譯器一起提供，但它們可以通過Linux軟件包管理器獨立升級。

在這個例子中，這似乎是去年年底修復的libstdc ++錯誤：

• Coliru有__GLIBCXX__ == 20141030
• ideone有__GLIBCXX__ == 20141220

我可以找到Bugzilla上最可能匹配的是bug 63497但是，老實說，我不相信Bugzilla會完全覆蓋這個特定的bug。 約瑟夫曼斯菲爾德 發現 ， 在這種特定情況下 ， 這些特定症狀至少是由修復后增量觸發的 。