A tuple performance question

Peng Yu

27 Sep 2007 27 Sep '07

3:38 p.m.

Hi, It is mentioned at http://www.boost.org/libs/tuple/doc/tuple_users_guide.html#performance that the following two ways would be different in term of performance. ////////////// void f1(int&, double&); tuple f2(); //Then, the call #1 may be slightly faster than #2 in the code below: int i; double d; ... f1(i,d); // #1 tie(i,d) = f2(); // #2 /////////////////// What about the current commonly used compiler, such as GCC? Are #1 and #2 different in GCC? Does the compiler always have some way to optimize #2 to make it as good as #1? Is it just a matter of fact whether the optimization method is implemented? Or #2 can never be made as good as #1? Thanks, Peng

Show replies by date

Miles Bader

28 Sep 28 Sep

2:33 a.m.

"Peng Yu" writes:

...

f1(i,d); // #1 tie(i,d) = f2(); // #2 ///////////////////

What about the current commonly used compiler, such as GCC? Are #1 and #2 different in GCC?

Does the compiler always have some way to optimize #2 to make it as good as #1? Is it just a matter of fact whether the optimization method is implemented?

I just tried it with gcc 4.2.1, and the tuple verison (#2) generates (slightly) better code (because in the case of #2, it only has to push one address to specify the "return location", instead of two separate addresses required by #1). -Miles -- Do not taunt Happy Fun Ball.

François Duranleau

1 Oct 1 Oct

5:16 a.m.

New subject: [parameter] Return type dependent on parameter type?

Hi! I have a function like this: template< typename Arg0 , typename Arg1 , ... > Arg1 the_function( Arg0 arg0 , Arg1 arg1 , ... ) { ... } The return type should be the same as one of its parameters, and all '...' are optional parameters. Is there a way to use BOOST_PARAMETER_FUNCTION in such a case? I didn't find anything in the documentation about it. I tried this: BOOST_PARAMETER_NAME( (arg1 , kw) arg1 ) BOOST_PARAMETER_NAME( (arg2 , kw) arg2 ) BOOST_FUNCTION_PARAMETER( (kw::arg2::_) , the_function , kw , (required (arg1 , *) (arg2 , *)) (optional ...) ) but it doesn't work. Looking at the macro's expansion, the meta function used to extract the result type seems to ignore it's template argument Args. Is it a limitation or a bug? Are there any other tricks (aside from manually handling argument packs as before)? -- Francois Duranleau

David Abrahams

9:30 p.m.

New subject: [parameter] Return type dependent on parameter type?

on Sun Sep 30 2007, François Duranleau wrote:

...

Hi!

I have a function like this:

template< typename Arg0 , typename Arg1 , ... > Arg1 the_function( Arg0 arg0 , Arg1 arg1 , ... ) { ... }

The return type should be the same as one of its parameters, and all '...' are optional parameters. Is there a way to use BOOST_PARAMETER_FUNCTION in such a case? I didn't find anything in the documentation about it. I tried this:

BOOST_PARAMETER_NAME( (arg1 , kw) arg1 ) BOOST_PARAMETER_NAME( (arg2 , kw) arg2 )

BOOST_FUNCTION_PARAMETER( (kw::arg2::_) , the_function , kw , (required (arg1 , *) (arg2 , *)) (optional ...) )

Try: BOOST_PARAMETER_NAME( (arg1 , kw) arg1 ) BOOST_PARAMETER_NAME( (arg2 , kw) arg2 ) BOOST_PARAMETER_FUNCTION( (arg1_type) , the_function , kw , (required (arg1 , *) (arg2 , *)) (optional ...) ) { return arg1; } See http://boost.org/libs/parameter/doc/html/index.html#adding-type-requirements -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

François Duranleau

2 Oct 2 Oct

6:29 p.m.

New subject: [parameter] Return type dependent on parameter type?

On Mon, 1 Oct 2007, David Abrahams wrote: [...]

...

See http://boost.org/libs/parameter/doc/html/index.html#adding-type-requirements

...

::type

I tried this simple example: //--------------------------------------------- #include #include BOOST_PARAMETER_NAME( (arg1 , kw) arg1 ) BOOST_PARAMETER_FUNCTION( (arg1_type) , the_function , kw , (required (arg1 , *)) ) { return arg1; } int main() { int i = the_function( 1 ) ; return 0 ; } //--------------------------------------------- but it won't compile either (gcc-4.0.2). Actually, if we look at the preprocessed output, it's not surprising. Here is the part of interest (formatted for readability): //--------------------------------------------- namespace kw { struct arg1 { static char const* keyword_name() { return "arg1"; } typedef boost::parameter::value_type< boost::mpl::_2, arg1, boost::parameter::void_ > _; typedef boost::parameter::value_type< boost::mpl::_2, arg1, boost::parameter::void_ > _1; }; } namespace { ::boost::parameter::keyword& arg1 = ::boost::parameter::keyword::get(); } template <class Args> struct boost_param_result_11the_function { typedef typename boost::parameter::aux::unaryfunptr_arg_type< void(*)(arg1_type) >::type type; }; template <class BoostParameterDummy> struct boost_param_params_11the_function : boost::parameter::parameters< boost::parameter::required< kw::arg1 , typename boost::parameter::aux::unwrap_predicate< void * >::type > > { }; typedef boost_param_params_11the_function<int> boost_param_parameters_11the_function; template <class Args> typename boost_param_result_11the_function< Args >::type boost_param_implthe_function(Args const& args); template< class ParameterArgumentType0> inline typename boost_param_result_11the_function< typename boost::parameter::aux::argument_pack< boost_param_parameters_11the_function , const ParameterArgumentType0 >::type the_function ( const ParameterArgumentType0& a0 , typename boost::parameter::aux::match< boost_param_parameters_11the_function, ParameterArgumentType0 >::type boost_parameter_enabler_argument = boost_param_parameters_11the_function() ) { return boost_param_implthe_function( boost_param_parameters_11the_function()( a0 ) ); } template < class ResultType , class Args , class arg1_type > ResultType boost_param_default_11the_function( ResultType(*)() , Args const& args , int , arg1_type& arg1 ) ; template <class Args> typename boost_param_result_11the_function<Args>::type boost_param_implthe_function(Args const& args) { return boost_param_default_11the_function( (typename boost_param_result_11the_function<Args>::type(*)())0 , args , 0L , boost::parameter::aux::cast::remove_const( boost::parameter::aux::cast::execute( args[ boost::parameter::keyword::get() ] ) ) ); } template < class ResultType , class Args , class arg1_type > ResultType boost_param_default_11the_function( ResultType(*)() , Args const& args , int , arg1_type& arg1 ) { return arg1; } int main() { int i = the_function( 1 ) ; return 0 ; } //--------------------------------------------- Notice where 'boost_param_result_11the_function' is defined: nowhere at that point is arg1_type defined. Same about 'boost_param_params_11the_function' if we want to make other parameters' type dependant on, e.g., arg1_type. Seems like the only place it is defined is at 'boost_param_default_11the_function'. I looked for examples in Boost.Parameter's test programs, alas, it seems there are no tests written for this feature. -- Francois Duranleau

Daniel Wallin

7:28 p.m.

New subject: [parameter] Return type dependent on parameter type?

François Duranleau wrote:

...

On Mon, 1 Oct 2007, David Abrahams wrote:

[...]

...
See http://boost.org/libs/parameter/doc/html/index.html#adding-type-requirements

I tried this simple example:

//--------------------------------------------- #include #include

BOOST_PARAMETER_NAME( (arg1 , kw) arg1 )

BOOST_PARAMETER_FUNCTION( (arg1_type) , the_function , kw , (required (arg1 , *)) ) { return arg1; }

int main() { int i = the_function( 1 ) ; return 0 ; } //---------------------------------------------

but it won't compile either (gcc-4.0.2). Actually, if we look at the preprocessed output, it's not surprising. Here is the part of interest [...]

I looked for examples in Boost.Parameter's test programs, alas, it seems there are no tests written for this feature.

Right. This is a doc error. You need extract the type from the argument pack Args: BOOST_PARAMETER_FUNCTION( (typename boost::parameter::value_type::type) , the_function , kw , (required (arg1 , *)) ) { return arg1; } Unfortunately the library has a bug that prevents this from working. This has been fixed, but not in time for 1.34. IIRC you need to apply this patch: http://svn.boost.org/trac/boost/attachment/ticket/1044/parameter.diff for this to work correctly. -- Daniel Wallin Boost Consulting www.boost-consulting.com

François Duranleau

4 Oct 4 Oct

1:03 a.m.

New subject: [parameter] Return type dependent on parameter type?

On Tue, 2 Oct 2007, Daniel Wallin wrote: [...]

...

Right. This is a doc error. You need extract the type from the argument pack Args:

BOOST_PARAMETER_FUNCTION( (typename boost::parameter::value_type::type) , the_function , kw , (required (arg1 , *)) ) { return arg1; }

Unfortunately the library has a bug that prevents this from working. This has been fixed, but not in time for 1.34. IIRC you need to apply this patch:

http://svn.boost.org/trac/boost/attachment/ticket/1044/parameter.diff

for this to work correctly.

Great! And now, is there a simpler way to do the same thing for other parameters other than doing this: BOOST_PARAMETER_FUNCTION( (some_return_type) the_function , kw , (required (arg1 , *) (arg2 , *(boost::is_same< boost::mpl::_ , kw::arg1::_ >)) ) //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ) ? -- Francois Duranleau

Daniel Wallin

7:47 a.m.

New subject: [parameter] Return type dependent on parameter type?

François Duranleau wrote:

...

Great! And now, is there a simpler way to do the same thing for other parameters other than doing this:

BOOST_PARAMETER_FUNCTION( (some_return_type) the_function , kw , (required (arg1 , *) (arg2 , *(boost::is_same< boost::mpl::_ , kw::arg1::_ >)) ) //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ )

?

No, not in general. If you are repeating something like that, you could factor it out to a metafunction class: template <class Tag> struct same_as { template struct apply : boost::is_same< T , typename boost::parameter::value_type< Args, Tag, void >::type > {}; }; BOOST_PARAMETER_FUNCTION( (some_return_type) the_function , kw , (required (arg1 , *) (arg2 , *(same_askw::arg1)) ) ) HTH, -- Daniel Wallin Boost Consulting www.boost-consulting.com

Mike Marchywka

3:20 p.m.

New subject: follow up on regex questions

Hi, Thanks for your help in the past. I would normally drop the issue at this point until I get my build environment cleaned up (" My build is messed up, I haven't read the documentation. What is wrong with YOUR library?" LOL). but I do have one more question which I believe is related to boost regex processing. If someone has a known good regex test program or can point to an obvious problem it may be helpful. Again, this code seems to work with Microsoft's greta and boost gives identical results on a longer list of SIMPLER regexes so I reasonably believe that the problem is due to handling of more complicated expression ( One caveat, to be complete, is that greta did seem to return some spurious results but they are easily filter programmatically, things like negative location, but the plausible ones that I have checked manually are right). However, on this sequence of regexes (regexi?) I get either an abort OR the program hangs later on non-sensical execution (I know, "Gee, you have a build problem and the stack is messed up?"). myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) myboost.cpp114 TATAA.*?ATAAA myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) ( progam hangs in my code or had been core dumping in boost::regex ) I think I removed all the stuff with questionable support related to assertions as discussed before. Thanks. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: Hotmail is blocking my mom's entire ISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'T assume I am ignoring you and try me on marchywka@yahoo.com if no reply here. Thanks. _________________________________________________________________ More photos; more messages; more whatever. Windows Live Hotmail - NOW with 5GB storage. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_5G_0907

John Maddock

4:37 p.m.

New subject: follow up on regex questions

Mike Marchywka wrote:

...

Hi, Thanks for your help in the past. I would normally drop the issue at this point until I get my build environment cleaned up (" My build is messed up, I haven't read the documentation. What is wrong with YOUR library?" LOL). but I do have one more question which I believe is related to boost regex processing. If someone has a known good regex test program or can point to an obvious problem it may be helpful.

You mean libs/regex/test/regress/*.cpp ? It would be a good idea to build and run this to verify the sanity of your setup at least: I still have a suspision that the binaries you are using are not compatible with your build options or regex headers, but I can't be sure.

...

Again, this code seems to work with Microsoft's greta and boost gives identical results on a longer list of SIMPLER regexes so I reasonably believe that the problem is due to handling of more complicated expression ( One caveat, to be complete, is that greta did seem to return some spurious results but they are easily filter programmatically, things like negative location, but the plausible ones that I have checked manually are right). However, on this sequence of regexes (regexi?) I get either an abort OR the program hangs later on non-sensical execution (I know, "Gee, you have a build problem and the stack is messed up?").

myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) myboost.cpp114 TATAA.*?ATAAA myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA)

( progam hangs in my code or had been core dumping in boost::regex )

What is the text you are matching against? If you can give me a concrete example I can test it here, but "it hangs" isn't very useful I'm afraid ;-) John.

Mike Marchywka

6:32 p.m.

New subject: follow up on regex questions

...

What is the text you are matching against? If you can give me a concrete example I can test it here, but "it hangs" isn't very useful I'm afraid ;-)

[ sorry if editing is awful, I kept simlifying and now believe I have a tractable test case- I didn't expect data dependence earlier. I now have a single regex that works of fails depending on a simple data change as shown below. And, again it would run with 10's of longer data strings against 1000's of SIMPLER regex;s and match exactly with diffs against greta results ] Thanks. If you have an easy way to test this, the scenario is as follows: I have a file containing multiple strings ( gene sequences, FWIW) and a set of rules ( regex's ) that describe interesting features in the string. The normal sequence is to apply the entire rule set to each string and return a vector of hits per-string. I played around with one of these files to find the simplest thing I could find to cause the error. In these traces, line 114 is the query and 115 is the sample ( no whitespace/crlf etc). Unlike my first example with the assertion support, this seems to make it through all the rules at least once This hangs ( I thought it may be a repetition problem but reliably hits on this data/regex combo first pass): $ $progpath/rules_annotater -clean -boost -doall -fastas q_fasta -debug -rules $progpath/boost_edit_rulesx > asdf myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) myboost.cpp115 in GAGATATTCACCTCTCATTGCCTTTTCCAGAGGTTGTTGAACTTAGTGGCCTGAGCATTTTA TCTGCAAAATGACTAGCAATTTTTTTTTAAGTTTCAGGCTTTTTTAATGCCCTAAATACAGTTGATCCATTACCGAGTGT GTTACATGCATAGGAATTTACTGATCTTTTCTTTTCCCCCTAGCTAGTTTTAAAGTTACTGAGCATAACGAGCTTTAAAA ATTCTTCAGAATACAAATAAATGAATAGATAAAAGACTACCTCCATTTGATAAATCATTCAAGAAAAAGAAAAAAAAACT TGAGCAAGCTAAGAAAGTCATTAACAGCCATATTTCTGATGGAACTAATGTxGATACCTACTCAAGCTAxCACTxGAATC TAATAATCTGTGAGAGAAGAAATGGGAAAAGGTATGAAAGC myboost.cpp121 looking for subexpr 0 myboost.cpp139 This DOESNOT hang ( note that it depends on removing the "X"'s): $ $progpath/rules_annotater -clean -boost -doall -fastas q_fasta -debug -rules $progpath/boost_edit_rulesx > asdf myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) myboost.cpp115 in GAGATATTCACCTCTCATTGCCTTTTCCAGAGGTTGTTGAACTTAGTGGCCTGAGCATTTTA TCTGCAAAATGACTAGCAATTTTTTTTTAAGTTTCAGGCTTTTTTAATGCCCTAAATACAGTTGATCCATTACCGAGTGT GTTACATGCATAGGAATTTACTGATCTTTTCTTTTCCCCCTAGCTAGTTTTAAAGTTACTGAGCATAACGAGCTTTAAAA ATTCTTCAGAATACAAATAAATGAATAGATAAAAGACTACCTCCATTTGATAAATCATTCAAGAAAAAGAAAAAAAAACT TGAGCAAGCTAAGAAAGTCATTAACAGCCATATTTCTGATGGAACTAATGTxGATACCTACTxCAAGCTAxCACTxGAAT CTAATAATCTGTGAGAGAAGAAATGGGAAAAGGTATGAAAGC myboost.cpp121 looking for subexpr 0 myboost.cpp139 Administrator@TESTBED01 /cygdrive/e/new/temp/canis/known/grade_R/misc_tgf $ All of these are char*, not std::string FWIW. boost::regex expression(query); boost::match_results what; boost::match_flag_type flags = boost::match_default; while(regex_search(start, end, what, expression, flags))

...

From: "John Maddock" Reply-To: boost-users@lists.boost.org To: Subject: Re: [Boost-users] follow up on regex questions Date: Thu, 4 Oct 2007 17:37:22 +0100

Mike Marchywka wrote:

...
Hi, Thanks for your help in the past. I would normally drop the issue at this point until I get my build environment cleaned up (" My build is messed up, I haven't read the documentation. What is wrong with YOUR library?" LOL). but I do have one more question which I believe is related to boost regex processing. If someone has a known good regex test program or can point to an obvious problem it may be helpful.

You mean libs/regex/test/regress/*.cpp ?

It would be a good idea to build and run this to verify the sanity of your setup at least: I still have a suspision that the binaries you are using are not compatible with your build options or regex headers, but I can't be sure.

...
Again, this code seems to work with Microsoft's greta and boost gives identical results on a longer list of SIMPLER regexes so I reasonably believe that the problem is due to handling of more complicated expression ( One caveat, to be complete, is that greta did seem to return some spurious results but they are easily filter programmatically, things like negative location, but the plausible ones that I have checked manually are right). However, on this sequence of regexes (regexi?) I get either an abort OR the program hangs later on non-sensical execution (I know, "Gee, you have a build problem and the stack is messed up?").

myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) myboost.cpp114 TATAA.*?ATAAA myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA)

( progam hangs in my code or had been core dumping in boost::regex )

What is the text you are matching against? If you can give me a concrete example I can test it here, but "it hangs" isn't very useful I'm afraid ;-)

John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

John Maddock

5 Oct 5 Oct

9:53 a.m.

New subject: follow up on regex questions

Mike Marchywka wrote:

...

This hangs ( I thought it may be a repetition problem but reliably hits on this data/regex combo first pass):

Not for me: it works just fine here, my complete test program is below, tested with cygwin g++ 3.4.4, and the version of Boost that's downloadable with cygwin: g++ -I /usr/include/boost-1_33_1 t.cpp -lboost_regex-gcc-mt t.cpp: #include #include <iostream> int main() { try{ boost::regex e("ATG(...)*?(TAG|TAA|TGA)"); const char* s = "GAGATATTCACCTCTCATTGCCTTTTCCAGAGGTTGTTGAACTTAGTGGCCTGAGCATTTTA" "TCTGCAAAATGACTAGCAATTTTTTTTTAAGTTTCAGGCTTTTTTAATGCCCTAAATACAGTTGATCCATTACCGAGTGT" "GTTACATGCATAGGAATTTACTGATCTTTTCTTTTCCCCCTAGCTAGTTTTAAAGTTACTGAGCATAACGAGCTTTAAAA" "ATTCTTCAGAATACAAATAAATGAATAGATAAAAGACTACCTCCATTTGATAAATCATTCAAGAAAAAGAAAAAAAAACT" "TGAGCAAGCTAAGAAAGTCATTAACAGCCATATTTCTGATGGAACTAATGTxGATACCTACTCAAGCTAxCACTxGAATC" "TAATAATCTGTGAGAGAAGAAATGGGAAAAGGTATGAAAGC"; boost::cregex_iterator a(s, s+strlen(s), e), b; while(a != b) { std::cout << *a << std::endl; ++a; } } catch(boost::regex_error e) { std::cout << e.what() << std::endl; } catch(std::exception e) { std::cout << e.what() << std::endl; } } So I still think that you have issues with your binary install, or build method or something. At this stage I'd recomend you rebuild the regex binaries using whatever build options you are using: the exception problem is strongly indicating that there is a binary incompatibity problem somewhere. HTH, John.

Mike Marchywka

11:13 a.m.

New subject: follow up on regex questions

...

At this stage I'd recomend you rebuild the regex binaries using whatever build options you are using: the exception problem is strongly indicating that there is a binary incompatibity problem somewhere.

Thanks. I'll give that a try as soon as practical and get back to you then. I probably should update my compiler too. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: Hotmail is blocking my mom's entire ISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'T assume I am ignoring you and try me on marchywka@yahoo.com if no reply here. Thanks.

...

From: "John Maddock" Reply-To: boost-users@lists.boost.org To: Subject: Re: [Boost-users] follow up on regex questions Date: Fri, 5 Oct 2007 10:53:10 +0100

Mike Marchywka wrote:

...
This hangs ( I thought it may be a repetition problem but reliably hits on this data/regex combo first pass):

Not for me: it works just fine here, my complete test program is below, tested with cygwin g++ 3.4.4, and the version of Boost that's downloadable with cygwin:

g++ -I /usr/include/boost-1_33_1 t.cpp -lboost_regex-gcc-mt

t.cpp:

#include #include <iostream>

int main() { try{ boost::regex e("ATG(...)*?(TAG|TAA|TGA)"); const char* s = "GAGATATTCACCTCTCATTGCCTTTTCCAGAGGTTGTTGAACTTAGTGGCCTGAGCATTTTA"

"TCTGCAAAATGACTAGCAATTTTTTTTTAAGTTTCAGGCTTTTTTAATGCCCTAAATACAGTTGATCCATTACCGAGTGT"

"GTTACATGCATAGGAATTTACTGATCTTTTCTTTTCCCCCTAGCTAGTTTTAAAGTTACTGAGCATAACGAGCTTTAAAA"

"ATTCTTCAGAATACAAATAAATGAATAGATAAAAGACTACCTCCATTTGATAAATCATTCAAGAAAAAGAAAAAAAAACT"

"TGAGCAAGCTAAGAAAGTCATTAACAGCCATATTTCTGATGGAACTAATGTxGATACCTACTCAAGCTAxCACTxGAATC" "TAATAATCTGTGAGAGAAGAAATGGGAAAAGGTATGAAAGC";

boost::cregex_iterator a(s, s+strlen(s), e), b; while(a != b) { std::cout << *a << std::endl; ++a; } } catch(boost::regex_error e) { std::cout << e.what() << std::endl; } catch(std::exception e) { std::cout << e.what() << std::endl; } }

So I still think that you have issues with your binary install, or build method or something.

At this stage I'd recomend you rebuild the regex binaries using whatever build options you are using: the exception problem is strongly indicating that there is a binary incompatibity problem somewhere.

HTH, John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today! http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGHM_OctHM...

Mike Marchywka

12:40 p.m.

New subject: follow up on regex questions

Yeah, sure enough, it was just the compiler - I upgraded and now everything I checked runs ( no mystery deaths ) and I even get a throw from the offensive assertion that I can catch properly. As cygwin setup closed with literally 10's of Dr. Watson dialog boxes I thought I had made a mistake but turned out to be easy to fix- at least I feel justified in making an upgrade a last resort :) myboost.cpp144 Error code 2 at 0 myboost.cpp145(?<=GU.*?TACTAAC.{20,40}AG|^).*?(?=GU.*?TACTAAC.{20,40}AG|$) catch ( boost::regex_error e) { es<

...

From: "John Maddock" Reply-To: boost-users@lists.boost.org To: Subject: Re: [Boost-users] follow up on regex questions Date: Fri, 5 Oct 2007 10:53:10 +0100

Mike Marchywka wrote:

...
This hangs ( I thought it may be a repetition problem but reliably hits on this data/regex combo first pass):

Not for me: it works just fine here, my complete test program is below, tested with cygwin g++ 3.4.4, and the version of Boost that's downloadable with cygwin:

g++ -I /usr/include/boost-1_33_1 t.cpp -lboost_regex-gcc-mt

t.cpp:

#include #include <iostream>

int main() { try{ boost::regex e("ATG(...)*?(TAG|TAA|TGA)"); const char* s = "GAGATATTCACCTCTCATTGCCTTTTCCAGAGGTTGTTGAACTTAGTGGCCTGAGCATTTTA"

"TCTGCAAAATGACTAGCAATTTTTTTTTAAGTTTCAGGCTTTTTTAATGCCCTAAATACAGTTGATCCATTACCGAGTGT"

"GTTACATGCATAGGAATTTACTGATCTTTTCTTTTCCCCCTAGCTAGTTTTAAAGTTACTGAGCATAACGAGCTTTAAAA"

"ATTCTTCAGAATACAAATAAATGAATAGATAAAAGACTACCTCCATTTGATAAATCATTCAAGAAAAAGAAAAAAAAACT"

"TGAGCAAGCTAAGAAAGTCATTAACAGCCATATTTCTGATGGAACTAATGTxGATACCTACTCAAGCTAxCACTxGAATC" "TAATAATCTGTGAGAGAAGAAATGGGAAAAGGTATGAAAGC";

boost::cregex_iterator a(s, s+strlen(s), e), b; while(a != b) { std::cout << *a << std::endl; ++a; } } catch(boost::regex_error e) { std::cout << e.what() << std::endl; } catch(std::exception e) { std::cout << e.what() << std::endl; } }

So I still think that you have issues with your binary install, or build method or something.

At this stage I'd recomend you rebuild the regex binaries using whatever build options you are using: the exception problem is strongly indicating that there is a binary incompatibity problem somewhere.

HTH, John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_________________________________________________________________ Get a FREE Web site and more from Microsoft Office Live Small Business! http://clk.atdmt.com/MRT/go/aub0930004958mrt/direct/01/

Mike Marchywka

4 Oct 4 Oct

7:52 p.m.

New subject: follow up on regex questions

...

What is the text you are matching against? If you can give me a concrete example I can test it here, but "it hangs" isn't very useful I'm afraid ;-)

Unless it is easy, please hold off on that last example. I think greta may be failing too but with a less overt failure mode. It isn't hanging or aborting but the piece of code exploding with boost may be dropping some data with greta. Given all the suspects, let me make sure greta code works perfectly. Thanks again.

...

From: "John Maddock" Reply-To: boost-users@lists.boost.org To: Subject: Re: [Boost-users] follow up on regex questions Date: Thu, 4 Oct 2007 17:37:22 +0100

Mike Marchywka wrote:

...
Hi, Thanks for your help in the past. I would normally drop the issue at this point until I get my build environment cleaned up (" My build is messed up, I haven't read the documentation. What is wrong with YOUR library?" LOL). but I do have one more question which I believe is related to boost regex processing. If someone has a known good regex test program or can point to an obvious problem it may be helpful.

You mean libs/regex/test/regress/*.cpp ?

It would be a good idea to build and run this to verify the sanity of your setup at least: I still have a suspision that the binaries you are using are not compatible with your build options or regex headers, but I can't be sure.

...
Again, this code seems to work with Microsoft's greta and boost gives identical results on a longer list of SIMPLER regexes so I reasonably believe that the problem is due to handling of more complicated expression ( One caveat, to be complete, is that greta did seem to return some spurious results but they are easily filter programmatically, things like negative location, but the plausible ones that I have checked manually are right). However, on this sequence of regexes (regexi?) I get either an abort OR the program hangs later on non-sensical execution (I know, "Gee, you have a build problem and the stack is messed up?").

myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA) myboost.cpp114 TATAA.*?ATAAA myboost.cpp114 (GU.*?TACTAAC.{20,40}AG|^)(.*?)(GU.*?TACTAAC.{20,40}AG) myboost.cpp114 ATG(...)*?(TAG|TAA|TGA)

( progam hangs in my code or had been core dumping in boost::regex )

What is the text you are matching against? If you can give me a concrete example I can test it here, but "it hangs" isn't very useful I'm afraid ;-)

John.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_________________________________________________________________ Spiderman 3 Spin to Win! Your chance to win $50,000 & many other great prizes! Play now! http://spiderman3.msn.com

Mike Marchywka

9:48 p.m.

New subject: follow up on regex questions(one more observation)

Thanks again for responding- I know how annoying these problems are where there are so many posisble issues. But, let me review what does appear to work. I have a list of 1300 regex "rules." I can verify that I get the same results with greta and boost in my annotation program using commands like this: ( rules_annotater is my test program that applies -xrules to -fastas input file and reports results on stdout): 319 $progpath/rules_annotater -boost -doall -fastas onn_fastas -xrules $progpath/prosite_rules > xxxx 321 $progpath/rules_annotater -clean -doall -fastas onn_fastas -xrules $progpath/prosite_rules > yyyy 322 diff xxxx yyyy The diff is clean. I have 1320 rules and the input file contains about 30 text samples, $ more $progpath/prosite_rules | wc 1319 5276 116804 and I get about 2231 hits from the above input data ( "onn_fastas" contains several input strings) $ more xxxx | wc 2231 13406 125169 However, there are very few groups, in fact, ( boost only sees the first word as none of these have white space) $ more $progpath/prosite_rules | grep "(" F[GSTV]PRL([G]|$) >rule|1074|PEPDTIDE Prosite PYROKININ F[IVFY]G[LM]M([G]|$) >rule|1077|PEPDTIDE Prosite TACHYKININ That is why I hope to figure out why the other rule set, containing only 3 rules, has consistent problems. If I thought the build was just plain bad I'd stop everything and fix that first but the only apparent problem is an inability to throw from boost. While I had been testing with different program options, I did just verify that the slight modification to the above command, $ $progpath/rules_annotater -boost -doall -fastas onn_fastas -xrules $progpa th/boost_edit_rulesx will hang when the edit rules file contains things like this: .(...)*?(.)?(H|F|G) >rule|4|Test test Thanks again. Mike Marchywka 586 Saint James Walk Marietta GA 30067-7165 404-788-1216 (C)<- leave message 989-348-4796 (P)<- emergency only marchywka@hotmail.com Note: Hotmail is blocking my mom's entire ISP claiming it is to reduce spam but probably to force users to use hotmail. Please DON'T assume I am ignoring you and try me on marchywka@yahoo.com if no reply here. Thanks. _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

6246

Age (days ago)

6254

Last active (days ago)

List overview

Download

15 comments

7 participants

participants (7)

Daniel Wallin
David Abrahams
François Duranleau
John Maddock
Mike Marchywka
Miles Bader
Peng Yu