That's still not nearly enough information. How are you using regex and how are you using it to interact with this 3rd party lib? Sent from my Verizon Wireless BlackBerry -----Original Message----- From: "Carsten Witzel" Date: Wed, 19 Nov 2008 18:25:20 To: Subject: Re: [Boost-users] [Regex] subexpressions _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 415-264-8477 (w)<- use this 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: If I am asking for free stuff, I normally use for hobby/non-profit information but may use in investment forums, public and private. Please indicate any concerns if applicable. Note: hotmail is getting cumbersom, try also marchywka@yahoo.com Date: Wed, 19 Nov 2008 19:27:32 +0100 From: carsten.witzel@googlemail.com To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Regex] subexpressions 2008/11/19 That's still not nearly enough information. How are you using regex and how are you using it to interact with this 3rd party lib? OK. Step by step: 1) It's a software application which has a C/C++ API. 2) You can write small programs with this API which are then called from inside the software application. 3) In the source code, all I've done is "#include " and insert the code listed in my first posting. To repeat it again: I am not using another implementation of the Regex library. I'm using the Boost.Regex library itself from within the 3rd party software application. My question is: How can it be that this "almost" works? The example with the win32 console application works as expected. Regards, Carsten _________________________________________________________________ Windows Live Hotmail now works up to 70% faster. http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_...

2008/11/19 Roland Bock

Hi,

ok, I'll try to rephrase (and please correct me if I am wrong):

a) You have a third party application which is closed source and you cannot debug it. b) This application can be extended by software you create yourself c) You wrote such an extension and this extension behaves weird when using boost::regex d) Your extension is a DLL and not a stand-alone program

Correct?

If yes, my first guess is:

You are using dynamic linking and the 3rd party software has its own version of boost::regex linked into it. If this version is different to the one you are using at compile time, weird things are to be expected.

Thus, my first suggestion is to use static linking for your plugin.

Regards, Roland

Hi, thanks for the hint! You've got everything right except d) My extension is a *.exe, but it cannot be run indepently. 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). I can debug my plugin (as long as it's not calling functions of the main application library), but I need some hints where to look at when boost::regex is involved. Regards, Carsten

2008/11/20 Roland Bock

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

Glad to read that you're coming closer to a solution. But I am sorry, I cannot help you with the includes. Regards, Roland Carsten Witzel wrote:

2008/11/20 Roland Bock mailto:rbock@eudoxos.de>

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 mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users