Boost logo

Boost Users :

Subject: Re: [Boost-users] [Regex] subexpressions
From: Carsten Witzel (carsten.witzel_at_[hidden])
Date: 2008-11-24 04:20:59


2008/11/20 Roland Bock <rbock_at_[hidden]>

> I'll try static linking, but I guess it will not solve the problem: I'm
>> 100% sure that the main application does not use boost.regex (I've checked
>> with dependancy walker).
>>
>
> It still might be that you have two versions of boost on your system, one
> being used at compile time, the other at runtime. In my experience, many
> obscure errors result from something like that. If it is not boost, check
> all other libraries you are using in your program.
>
> Next step: Use some memory checking library (hope there is something like
> that for windows...). Memory which is corrupted by the application can also
> give extraordinary results.
>
> If this still yields no findings, gradually remove all calls to the 3rd
> party software or replace the function calls by calls to dummy functions.
> Somewhere between the current state and that initial commandline exe the
> regex behavior will return to normal. This will give you a hint where to
> look closer or what/whom to ask in more detail.
>
> Try to reproduce the problem with something you can publish. If you find no
> way to reproduce the problem without the 3rd-party software, contact the
> vendor.

Thanks for the hints!

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!

But you're right: as it's not a Boost-specific problem, I'll try to get help
from the application's vendor.

Regards,
Carsten



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net