On Sat, Nov 22, 2008 at 7:56 PM, John Maddock <john@johnmaddock.co.uk> wrote:

Roman Yakovenko wrote:

...

...

Using proc file system, I compared environment variables, specifically LANG is set to "en_US.UTF-8". Both executables load same Boost.Regex shared library. I am using GCC 3.3.3, on RedHat. The boost version is 1.34. Searching the web didn't help too.

Roman, can you try with an up-to-date Boost version, I have some dim recollection of fixing an issue similar to this.

This is the last entry in my possible solutions list :-). I also searched trac, for a bug similar to my, I didn't find any. Today, i know a little bit more about the bug: * it happens in "match" algorithm only, "search" algorithm works as expected * wregex, and regex ".getloc().name()" expression returns same data. * I also found out, that the functionality works fine with boost 1.32. However, the product I am working on, has been changed a lot too. My possible solutions list: * use search algorithm and check whether the found string is the whole string * use regex with ICU. We have ICU 3.4. * upgrade boost. What do you think? Thank you for help. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/

On Thu, Nov 27, 2008 at 12:15 PM, John Maddock <john@johnmaddock.co.uk> wrote:

Roman Yakovenko wrote:

...

...

...

Roman, can you try with an up-to-date Boost version, I have some dim recollection of fixing an issue similar to this.

This is the last entry in my possible solutions list :-). I also searched trac, for a bug similar to my, I didn't find any.

Today, i know a little bit more about the bug: * it happens in "match" algorithm only, "search" algorithm works as expected * wregex, and regex ".getloc().name()" expression returns same data. * I also found out, that the functionality works fine with boost 1.32. However, the product I am working on, has been changed a lot too.

My possible solutions list: * use search algorithm and check whether the found string is the whole string * use regex with ICU. We have ICU 3.4. * upgrade boost.

What do you think?

I would try with the latest Boost code *first*: just to see if it looks to fix the issue, it's a quick test and if it does fix things then you know where the problem was!

I changed the order of include headers, "boost/regex.hpp" is now the first header included, and the problem disappear. I think, there problem was caused by GCC 3.3.3, however I could be wrong. By the way, I tested the locale instance, used by wregex and regex classes, and I got the correct behavior. Thank you for help. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/

On Mon, Nov 24, 2008 at 10:05 PM, Steven Watanabe <watanabesj@gmail.com> wrote:

If you said

boost::regex r("(\s)");

then you actually mean

boost::regex r("(\\s)");

note the two backslashes--the compiler strips one of them.

Thanks for help. I am aware of this and use the second form. I investigated the problem father and found that "regex" class works, while "wregex" fails. I guess there is some issue with "locale" or something like this. I will debug this tomorrow. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/

On Sat, Nov 22, 2008 at 6:51 PM, John Maddock <john@johnmaddock.co.uk> wrote:

Roman Yakovenko wrote:

...

...

I am aware of this and use the second form. I investigated the problem father and found that "regex" class works, while "wregex" fails.

I guess there is some issue with "locale" or something like this. I will debug this tomorrow.

Hmm, regex and wregex should behave the same here... unless there is a bug in your std::locale implementation or something.

I was afraid, you would say that. Strangelly we didn't see the problem with other functionality.

Do you have a test case?

No. After 3 days, I still not able to reproduce the bug. -- Roman Yakovenko C++ Python language binding http://www.language-binding.net/