Carsten Witzel wrote:
I've checked with Microsofts TR1 implementation, and I get the same wrong result, so the problem is not Boost, but the 3rd party application.
From an older project, I remembered that the application's libs use _HAS_ITERATOR_DEBUGGING=0 and _SECURE_SCL=0, but that wasn't enough.
If anyone had an idea which #defines and #includes are _not_ allowed for boost::regex (or std::tr1::regex), that would be great!
Anything is allowed, but... if you define something that changes the ABI of Boost.Regex or the std lib then you *must* compile Boost.Regex with the same options. _HAS_ITERATOR_DEBUGGING=0 and _SECURE_SCL=0 almost certainly come into that category.
But you're right: as it's not a Boost-specific problem, I'll try to get help from the application's vendor.
Hmm, if the msvc regex implementation produces the same result then that suggests that either: * The regular expression is somehow changed in the application. * The string being matched isn't what you think it is in the application. * There could just possibly be some issue with the locale being changed in the application - but I can't recall what the regular expression was now to know if there's anything that might be locale sensitive. HTH, John.